Büyük monolitik uygulama tehlikeleri

Birkaç yıldır üzerinde çalıştığım büyük proje, ürün yazılımının kalbi olan gelişmiş bir cihazın kontrol (ve her şey) uygulamasıdır.

Cihaz oldukça gelişmiş, bellekten söyleyebileceğimden daha farklı işlevselliklere sahip ve bunların% 98'i bu büyük yürütülebilir dosya tarafından işleniyor. Bir yandan, program oldukça bakımlı, içeride iyi modülerleştirilmiş, düzgün bir şekilde belgelenmiş, işlevselliklerin dizinler ve dosyalar tarafından makul bir şekilde ayrılması vb.

Ama sonuçta, tüm bunlar uzak veritabanı iletişimi, dokunmatik ekran kullanımı, bir düzine çeşitli iletişim protokolünü, ölçümleri, çeşitli kontrol algoritmalarını, video yakalamayı, güneşin doğuş saatini ve paskalya tarihini (ciddiyetle ve çok ciddi amaçlar için gereklidir!) ... Genel olarak, çok ince bir şekilde ilişkili olan şeyler, genellikle sadece uzak modüller arasında damlayan bazı verilerle ilişkilidir.

Birbirleriyle iletişim kuran birkaç ayrı çalıştırılabilir, örneğin, soketler üzerinde, daha spesifik bir amaçla, belki gerektiği gibi yüklenebilir / boşaltılabilir, vb. Bu şekilde yapılmasının özel bir nedeni yok.

Bir yandan işe yarıyor ve iyi çalışıyor. Proje, çoklu ikili dosyalar oluşturmadan daha basittir. Yuva veya paylaşılan bellek yerine konuşmak yerine bir yöntemi çağırabileceğiniz veya bir değişkeni okuyabildiğinizde iç yapı da daha kolaydır.

Ama diğer yandan, bu şeyin büyüklüğü, ölçeği beni korkutuyor, Titanik'i pilot gibi hissettiriyor. Her zaman modülerleştirilmem öğretildi ve her şeyi tek bir dev dosyaya toplamak yanlış geliyor. Bildiğim bir sorun, bir (hatta önemsiz) modül ağır bir çökme tüm çöküyor - ama kod kalitesi bu gerçekten sürümlerinde gerçekleşmez garanti eder. Aksi takdirde, dahili ayırma ve defansif programlama, dahili modüllerin yarısı bir nedenden ötürü normal şekilde başarısız olsa bile, bunun çoğunlukla doğru şekilde çalışmasını sağlar.

Başka hangi tehlikeleri gözden kaçırdım? Bu neden beni korkutuyor? Bu sadece akıl dışı bilinmeyen korkusu mu? Bu şekilde ciddi büyük projeler yapmak kabul edilmiş bir uygulama mı? Ya korkularımı sakinleştir ya da sürüm 2.0'ı birden çok daha küçük ikili dosyaya dönüştürmek için iyi bir neden ver.

Sonunda küçük yorum dışında (ikincisi, CPU denetliyor) şirketimi tarif ediyor olabilirsiniz. Evet, Paskalya'ya da ihtiyacımız var.

Biraz daha ilerideyiz. Büyük yürütülebilir dosyayı ayırdık ve standart bitler için standart bileşenler kullanmaya çalıştık. Tam olarak umduğunuz büyük gelişme değil. Aslında, performans daha sert donanımlarda bile büyük bir acı haline geliyor. Ve bakım maliyetleri, dar arayüzler üzerinden verileri serileştirmek ve senkronize etmek için tonlarca kod olduğu için gerçekten düşmedi.

Aldığım ders? Tek bir çalıştırılabilir dosyaya sahip olmak, küçük sistemler için kanıtlanmış bir çözümdür ve bunları yönetme konusunda onlarca yıllık deneyime sahibiz. Tüm araçlarımız bunu doğal olarak desteklemektedir. Modülerlik tek bir yürütülebilir dosyada da yapılabilir ve diğer nedenlerden dolayı modülerlikten ödün vermeniz gerektiğinde kesmek küçük kalır.

Cihaz oldukça gelişmiş, bellekten söyleyebileceğimden daha farklı işlevselliklere sahip ve bunların% 98'i bu büyük yürütülebilir dosya tarafından işleniyor. Bir yandan, program oldukça bakımlı, içeride iyi modülerleştirilmiş, düzgün bir şekilde belgelenmiş, işlevselliklerin dizinler ve dosyalar tarafından makul bir şekilde ayrılması vb.

Bunu kendin söyledin - oldukça sürdürülebilir, iyi modülerleştirilmiş ...

Kanımca ve yönetimin çoğu bu konuda benimle aynı fikirde olacak, hiçbir zaman değişiklik uğruna değişiklik yapılmamalıdır. Bu programda (açıklamanız), en son programlama eğilimlerini (diğer cevaplarda belirtilmiştir) takip etmemesi dışında yanlış bir şey yoktur.

Evet, daha büyük bir program ... daha önce de var. Aynı zamanda iyi belgelenmiştir, bu yüzden tek yapmanız gereken iç organizasyonunu incelemek ve içindeki mantığı göreceksiniz. Senden önceki tüm yazarların yetersiz olduğundan şüpheliyim. Yani, biraz keşfedin, öğrenin ... bundan sonra, yeniden yazmak için sağlam bir neden ortaya çıkana kadar koruyun. Yöneticiniz iyi bir maliyet / etki oranına sahip olduğunuz için size minnettar olacaktır.

Başka hangi tehlikeleri gözden kaçırdım? Bu neden beni korkutuyor? Bu sadece akıl dışı bilinmeyen korkusu mu? Bu şekilde ciddi büyük projeler yapmak kabul edilmiş bir uygulama mı? Ya korkularımı sakinleştir ya da sürüm 2.0'ı birden çok daha küçük ikili dosyaya dönüştürmek için iyi bir neden ver.

Büyük olduğu için sizi korkutuyor - ama yine de, hiç kimse bir hafta içinde hepsini ezbere öğrenmenizi beklemiyor. Bu yüzden, onu asana kadar parça parça, parça parça çalışın. Sonunda, muhtemelen olduğu gibi iyi organize edildiğini ve nasıl organize edildiğini öğreneceksiniz.

Yeniden yazsaydınız, aynı başarıyı elde edersiniz, ancak aynı zamanda kodun önceki organizasyonuna alışkın olanlar için harap ederdiniz. Bu şekilde, sadece "adapte etmek" zorundasınız.

Her şeyin birim testlere sarıldığını söyleseydin daha iyi hissederdim. Bunu yapmazsanız, uygulamayı yeniden aramayı düşünmeden önce bir test paketi oluşturmanız gerekir.

Bir test takımına sahip olmak, uygulama hakkındaki anlayışınızı geliştirecek ve uygulamadaki bir değişikliğin bir şeyi bozduğunu size söyleyecektir.

Kod, düşük kuplaj ve yüksek kohezyon ile iyi modüle edilmişse, etkili bir şekilde bölünür. İletişim yükü, bir işlem içinde birden çok işlemde olduğundan daha düşük olmalıdır.

Gömülü sistemler için, bir işleminiz, oluşturacağınız tüm işlemleri çalıştırmak için bir O / S uygulama ihtiyacını ortadan kaldırabilir. Ayrıca tüm süreçlerin çalışıp çalışmadığını kontrol etmek ve mümkünse yeniden başlatmak için bir sistem uygulamanız gerekir. Mümkün olmasaydı, buna göre tepki vermelisin.

Kodu ayrı çalıştırılabilir dosyalara bölmek, modüller arasında tüm istemci / sunucu kodunu uygulamanız gerektiği için kaynak kodun toplam boyutunu da artıracaktır. Bu kodu işlemek için daha fazla test vakasına ve sunucu işleminin orada olmadığı durumlara da ihtiyacınız olacaktır. Büyük projeler büyüktür, burada yapıldığı gibi gereksiz karmaşıklıkları ortadan kaldırarak, onları olabildiğince küçük tutmaya yardımcı olur.

Testler burada bir çeşit kırmızı ringa balığıdır, çünkü problemler testle veya testsiz olarak orada olacaktır. Her iki tasarım seçimiyle de iyi testler kesinlikle teşvik edilmelidir. Monolitik kodla testlerin daha basit olmasını bekliyorum.

Monolitik bir yürütülebilir dosya ile gerektiğinde bir çarpışmayı zorlamak daha kolaydır.

Eğer böylesine büyük bir yekpare uygulama üzerinde çalışacak olsaydım, beni korkutacak şeyler kapsülleme eksikliği, düşük uyum, yüksek bağlanma ve bunların nasıl test edileceğidir. Büyük monolitler genellikle uygun mimariyi terk etme ve inişe büyük bir çamur topuna başlama davetidir .

Bu gerçekleştiğinde, testler kabus haline gelir ve eskime yolundasınız.

Ancak, kodunuz iyi yapılandırılmış ve iyi korunmuşsa ve yüksek uyum, düşük bağlantı ve uygun kapsülleme ilkelerine uyulursa, bunu daha küçük birimlere yeniden yansıtmak için çok az neden görüyorum.

Yine de yerinde iyi testler yapmak istiyorsunuz.

İdeal olarak, cevap evettir. Birden fazla ikili dosyaya sahip olmak onu daha kararlı hale getirme potansiyeline sahiptir ....

... ancak, monolitik kod tabanındaki kodun iyi yazılmış ve modülerleştirildiğinden de bahsettiniz, bu da büyük bir karışıklık, sadece büyük bir kod tabanı ile uğraşmamanız anlamına gelir ...

Genel olarak, geçerli sözün "Mükemmelin iyinin düşmanı olmasına izin verme" olduğunu söyleyebilirim. Monolitik bir kod tabanının kötü olduğunu söylerken doğru olduğunuzu hissederken, bunun için endişelenmeye çabalamaya değmediğini hissediyorum.

Kendi ikili dosyalarına yeni kod parçaları ekleyerek ilerlemek mantıklı olacaktır, ancak geri dönüp yeniden düzenleme muhtemelen zaman ayırmaya değmez.

Tek bir işlem kullanıyorsanız, alt modülünüzden birindeki vahşi bir işaretçinin kritik bir bellek parçasını bozması (ve her şeyin çökmesi) ihtimali vardır.

Farklı işlemler kullanıyorsanız, en azından aynı yığın veya çağrı yığınını kullanmıyorsunuzdur ve tek bir alt işlemi yeniden başlatmak daha kolay olabilir.

Yuva veya paylaşılan bellek yerine konuşmak yerine bir yöntemi çağırabileceğiniz veya bir değişkeni okuyabildiğinizde iç yapı da daha kolaydır.

Her şeyi birden çok işlemde yeniden düzenlemek, tasarımı temizlemenizi ve her modülün diğer modüllerin dahili yöntemlerini kullanmaya başlamasını önler.

Muhtemelen yıldırıcı bir görev olduğu söyleniyor.

Yapmaya başlayabileceğiniz şey, her yeni modülün yalıtılmış bir süreç olması gerektiğidir.

Projenin bir seferde birden fazla bakılamayacağı büyük bir alana girdiğimde, tüm büyük bölümleri ve birbirine nasıl uyacaklarını gösteren duvara asmak için bir grafik oluşturuyorum. Sonra çalışırken odaklandığım modüle başvurabilir ve bütüne nasıl uyduğunu görsel olarak hatırlatabilirim.

Birden fazla, bağlantısı kesilmiş ikili dosyalar için bir yapı ve sürüm oluşturma sisteminin korunmasının karmaşıklıkları ve tehlikelerinin, böylesine büyük ve yekpare bir projeyle rahatsızlığınızdan çok daha ağır basması olasıdır.