Tarihsel olarak yetiştirilen yazılım için adlandırılmış bir anti modeli var mı? [kapalı]

Çok sayıda geliştiricinin sisteme yeni özellikler eklediği, ancak hiç kimsenin genel mimariye göz kulak olmadığına ya da yeniden yapılanma işlemlerinin yapılmamasına neden olan, tarihsel olarak geliştirilmiş bir yazılım sistemini tanımlayan bir kalıp var mı?

Bunun, yönetim / müşteri sürekli yeni bir özellik istediğinde ve hiç kimsenin bir şeyleri küçümsemediğini, ancak diğer geliştiricilerin daha önce yaptıklarını eklediğini düşünüyorum.

Bunun bir nedeni, geliştiricinin sadece yazılım sistemi ile boğulmuş ve şu anda nasıl çalıştığını gerçekten anlamamış olabilir ve ardından kodunu en sonunda ekler / yapıştırır (kodu yeniden düzenlemek ve değiştirmek yerine).

Bu yüzden zamanla sistemi korumak gittikçe zorlaşıyor.

(Bu tür bir anti-patern için, hiç bir programlama insanına daha net bir şekilde açıklık getirecek resimlerin olup olmadığını merak ediyorum - genel tasarımı düşünmeden daha fazla özellik ekleyerek inşa edilmiş bir araba gibi. geriye doğru giderken römorklar ve sonra bir mühendis sadece arabanın ön kısmına bir çekme çubuğu kaynaklıyor. İş bitti. Fakat artık baca artık açılmıyor.)

Sen atıfta teknik borcu .

Hepimiz zaman içinde geliştirdiğimiz ürünlerde teknik borç tahakkuk ediyoruz; yeniden yapılanma, bu teknik borcu azaltmanın en yaygın ve etkili yollarından biridir, ancak birçok şirket teknik borcunu hiçbir zaman ödememektedir. Bu şirketler yazılımlarını yolun aşağısında oldukça dengesiz yıllar bulma eğilimindedir ve teknik borç o kadar korkunç hale gelir ki artımlı olarak ödeyemezsiniz, çünkü bu şekilde ödeme yapmak çok uzun sürecektir.

Teknik borcun terimi var, çünkü aynı borç davranışlarını takip ediyor. Borcu alıyorsunuz ve harcama yapmaya devam ettiğiniz (özellikler yaratan) ve bu borcu ödeyemediğiniz sürece, sadece büyüyecek. Borç gibi, çok büyüdüğünde, tamamen yeniden yazma gibi tehlikeli görevlerle tamamen dökmek isteyebileceğiniz noktalara ulaşırsınız. Ayrıca, gerçek borç gibi, belli bir noktaya tahakkuk ettiği için, harcama yapma kabiliyetinizi tamamen engeller.

Sadece karışımda başka bir terim atmak için uyum , bir sistemin, hat seviyesine göre mikro veya sistem seviyesine kadar makroya ne kadar uyduğunu ifade eder. Oldukça uyumlu bir sistem tüm parçalarının birbirine çok iyi uymasını sağlayacak ve bir mühendisin hepsini yazmış gibi görünecek. Yukarıda sadece kodlarını sonuna kadar yapıştıran birine referansınız, o sistemin uyumunu ihlal ediyor olabilir.

Teknik Borç Yönetme

Teknik borcu yönetmenin birçok yolu vardır, ancak gerçek borç gibi en iyi yaklaşım sık sık ödeme yapmaktır. Ne yazık ki, gerçek borç gibi, kısa bir süre için daha fazla tahakkuk etmek daha iyi bir fikirdir; örneğin, bir özellik için piyasaya sürülme zamanınız gelirinizi iki katına çıkarabilir veya üçe katlayabilir. İşin zor yanı, bu rekabet önceliklerini tartıştırmak ve aynı zamanda verilen özelliğe göre yatırım getirisinin ne zaman buna değmeyeceğini ve ne zaman olacağını belirlemek.

Bu yüzden bazen borcu kısa bir süre için tahakkuk ettirmeye değer, ancak nadiren durum böyledir ve tüm borçlarda olduğu gibi, dönem ne kadar kısa olursa o kadar iyi olur. Sonuçta , teknik borç tahakkuk ettikten sonra (tercihen hızlıca ), bunu ödemek zorundasınız, bunlar genel yaklaşımlardır:

• üstlenmeden
  • Bu, yalnızca uygulama sırasında veya sonrasında tamamıyla yanlış yerleştirildiği anlaşılan kod bitlerini almanıza ve bunları doğru yerlerine koymalarına (veya yine de daha doğru olanlarına ) izin verir.
• Yeniden yazmak
  • Bu bir iflas gibi. Kayrakları temizler, ama hiçbir şeyle başlamazsınız ve aynı hataları veya daha da büyüklerini yapma fırsatınız vardır. Teknik borçlara yüksek riskli yüksek ödül yaklaşımı, ancak bazen tek seçeneğiniz bu. Bu çok nadiren olsa da çoğu kişinin size söyleyeceği gibi.
• Mimariye Genel Bakış
  • Bu daha aktif bir teknik borç geri ödeme yaklaşımıdır. Bu, daha az teknik borç tahakkuk ettirmesini sağlamak için proje planları ve programlarından bağımsız olarak bir uygulamayı durdurmak için teknik detaylar üzerinde yetkiye sahip birisine yaptırılarak yapılır .
• Kod Donma
  • Değişiklik kodunun dondurulması borcunuzun yükselmediği veya düşmediği yerlerde nefes almanıza izin verebilir. Bu, yaklaşımınızdaki en yüksek YG'ye sahip olma umuduyla teknik borcu azaltma yaklaşımınızı planlamanıza zaman kazandırır.
• modularization
  • Bu, sadece bir seviye 2 yaklaşımı gibidir, ancak zaten modüler bir sisteme sahip olmak için Mimariye Genel Bakış'ı kullandığınızda ya da birine doğru hareket etmek için Refactoring'i kullandığınızda geçerlidir. Modüler bir sisteminiz olduğunda, sistemin bütün parçaları için borcunuzu izole bir şekilde ödeyebilirsiniz. Bu, kısmi yeniden yazma, kısmi yeniden düzenleme ve teknik borç tahakkuk oranını en aza indirgemenize izin verir , çünkü izolasyon, sistemin etrafa yayılmasının aksine, sadece özelliklerin girdiği alanlarda borcu tutar.
• Otomatik Testler
  • Otomatik testler teknik borcunuzu yönetmenize yardımcı olabilir, çünkü sistemdeki sorunlu noktaları belirlemenize yardımcı olabilirler, umarım bu bölgelerdeki borçlar çok büyüyünce, ancak yine de mühendisleri bu tehlikeli bölgelerden haberdar etmelerine rağmen daha önce farkına varmamış olabilirsiniz. Dahası, otomatik testler yaptıktan sonra, çok fazla kırılma endişesi duymadan işleri daha serbestçe yeniden düzenleyebilirsiniz. Geliştiricilerin bir şeyleri kırmayacağı için değil , işleri ne zaman kırdıklarını öğrenecekleri için , borçlu sistemlerde manuel testlere güvenmek, sorunları bulmak için zayıf bir geçmişe sahip olma eğilimindedir.

Açıklamanız Foote ve Yoder Büyük Çamur Balosuna uyar :

Son birkaç yılda, bir takım yazarlar ... üst düzey yazılım mimarilerini karakterize eden modeller sunmuşlardır ... İdeal bir dünyada, her sistem bir ya da daha fazla bu gibi üst düzey kalıpların bir örneği olacaktır. Ancak, bu öyle değil. Aslında pratikte hakim mimari henüz tartışılacak etti: BÜYÜK KÜRESEL Çamur .

BÜYÜK BİR KÜRESEL BİR ÇAMUR, gelişigüzel yapılandırılmış, yayılmış, özensiz, koli bandı ve balyalama teli, spagetti kodu ormanı. Hepimiz onları gördük. Bu sistemler düzensiz büyümenin ve tekrarlanan, uygun onarımların kusursuz belirtilerini göstermektedir. Bilgi, sistemin neredeyse tüm unsurları arasında, genellikle neredeyse tüm önemli bilgilerin küresel ya da çoğaltıldığı noktaya kadar, ortak bir şekilde paylaşılır. Sistemin genel yapısı hiçbir zaman iyi tanımlanmamış olabilir. Öyleyse, tanınmayacak kadar aşınmış olabilir. Mimari duyarlılığa sahip programcılar bu bataklıkları ortadan kaldırdı. Sadece mimarlık hakkında endişelenmeyenler ve belki de bu başarısız paftalardaki delikleri yamalama günlük işlerinin ataleti ile rahat olanlar, bu tür sistemler üzerinde çalışmaktan memnunlar ...

Neden bir sistem BÜYÜK BİR TOPLANTISI ÇOK OLUYOR? Bazen, büyük, çirkin sistemler THROWAWAY KODU'ndan ortaya çıkar . THROWAWAY KODU, yalnızca bir kez kullanılması ve sonra atılması amaçlanan hızlı ve kirli bir koddur. Bununla birlikte, bu tür bir kod, gündelik yapıya ve kötü ya da olmayan dokümantasyona rağmen, genellikle kendi başına bir yaşam sürmektedir. Çalışıyor, peki neden düzeltelim? İlgili bir sorun ortaya çıktığında, çözmenin en hızlı yolu, temelden uygun bir genel program tasarlamak yerine, bu çalışma kodunu çabucak değiştirmek olabilir. Zamanla, basit bir fırlatma programı BÜYÜK BİR KÜRESELDİR.

İyi tanımlanmış mimarilere sahip sistemler bile yapısal erozyona eğilimlidir. Başarılı bir sistemin çektiği değişen gereksinimlerin acımasız saldırısı, yavaş yavaş yapısını baltalayabilir. PIECEMEAL GROWTH , sistemin elemanlarının kontrolsüz bir şekilde yayılmasına izin verdiği için, bir zamanlar düzenli olan sistemler aşırı büyür .

Eğer böyle bir yayılma azalmadan devam ederse, sistemin yapısı terk edilmek zorunda kalacak kadar kötü bir şekilde tehlikeye girebilir. Çürüyen bir mahallede olduğu gibi, aşağı doğru bir spiral oluşuyor. Sistemin zorlaşması ve anlaşılması zorlaştığından, bakım daha pahalı ve daha zor hale gelir. İyi programcılar orada çalışmayı reddediyorlar. Yatırımcılar sermayelerini geri çekiyorlar. Ve yine de, mahallelerde olduğu gibi, bu tür bir düşüşün önüne geçmenin ve hatta geri çevirmenin yolları var. Evrendeki herhangi bir şeyde olduğu gibi, entropik kuvvetlere karşı koymak bir enerji yatırımını gerektirir. Yazılımın soyulması istisna değildir. Yazılımdaki entropiyi durdurmanın yolu onu yeniden yaklaştırmaktır. Yeniden yapılanmaya devam etmek konusundaki sürekli bir taahhüt, bir sistemin BÜYÜK BİR KÜRESELDEN çökmesine engel olabilir ...

• ... Çamurun en etkili düşmanlarından biri güneş ışığı. Kıvrımlı kodun incelenen oka tabi tutulması, yeniden düzenleme, onarım ve rehabilitasyon için sahneyi oluşturabilir. Kod incelemeleri , kodu gün ışığına çıkarmak için kullanabileceğiniz bir mekanizmadır.