Yazılım Neden Hatalı Olduğunu Söyleyemez? Mimari Tasarımın Görünmez Maliyeti Yazılım

Yazılım Neden Hatalı Olduğunu Söyleyemez? Mimari Tasarımın Görünmez Maliyeti

Yazılım mimarisi tartışmaları, köprülerin aksine alternatifin hiç inşa edilmediği bir sorunla karşı karşıya: yanlış yapı doğru çalışabilir, maliyet gö

Yazılım mimarisi tartışmalarının diğer mühendislik disiplinlerinden farklı bir sorunu vardır: alternatif hiç inşa edilmemiştir. Bir köprü çöktüğünde, başarısızlık fiziksel, atfedilebilir ve çökmeyen diğer köprülere karşı ölçülebilirdir. Buna neden olan mühendislik kararları izole edilebilir, izlenebilir ve düzeltilebilir — sadece teoride değil, bir sonraki köprüde de, çünkü malzemenin kendisi hiçbir profesyonel görüşün üstesinden gelemeyeceği geri bildirim üretir. Çelik bükülür. Beton çatlar. Fizik, mimarın neye inandığını umursamaz.

Yazılım böyle bir geri bildirim üretmez. Yanlış soyutlamalar etrafında inşa edilmiş bir sistem, doğru olanlar etrafında inşa edilmiş bir sistem kadar kolayca derlenir, çalışır, yayınlanır ve testleri geçer. Yanlış hizalanmış bir domain modelinden kaynaklanan bir hata, dışarıdan bir yazım hatasından kaynaklanan bir hatayla aynı görünür. Yapısı iş mantığının gerektirdiğinden daha zor olduğu için olması gerekenden üç kat daha uzun süren bir özellik, sadece zor olan bir özellikten onu ayırt edecek hiçbir yapay ürün üretmez. Maliyet gerçektir. Neden görünmezdir.

Bu, yanılmazlık sorunudur ve 'her şeyi ölçemeyiz'den daha derine iner. Bir sistem değiştirmenin pahalı hale geldiğinde, teşhis neredeyse her zaman yanlış değişkene yönelir: alan karmaşıktır, gereksinimler değişmiştir, önceki ekip dikkatsizdir. Neredeyse hiçbir zaman: yapı yanlıştı ve yapı yanlıştı çünkü kimse diğer versiyonunu inşa edip karşılaştırmadı. O versiyon yok, asla olmayacak ve sektördeki her mimari tartışma onun yokluğunda yapılıyor. Bu tamamen felsefi bir sorun olurdu, eğer yapılacak bir şey olmasaydı. Yapılacak bir şey var — ancak yazılım kalitesi için standart metriğin, 'çalışıyor mu'nun tamamen yanlış şeyi ölçtüğünü kabul etmeyi gerektiriyor.

Çalışma, şaşırtıcı derecede uzun bir süre neredeyse her türlü temel yapıyla uyumludur. Bir sistem, backlog'undaki her işlevsel isteği karşılarken, temel karmaşıklığı — işin gerçek kuralları ve ilişkileri — hizmet metotlarına dağılmış, katmanlar arasında çoğaltılmış, üç yerde farklı şekilde kodlanmış olabilir. Bunların hiçbiri bir başarısızlık olarak görünmez. Ta ki yeni bir gereksinim aynı anda bu üç yere de ulaşana ve küçük bir değişiklik, kuralın kaç versiyonunun var olduğunu ve hangilerinin yetkili olduğunu araştırmaya dönüşene kadar. Bu noktada neden teşhis edilemez. Yapı büyüktür. Kural iki yıllık sprint incelemeleri boyunca birikmiştir. Orijinal üç versiyonu yazan geliştiriciler gitmiştir. Soruna neden olan yapı, kurumsal karmaşıklığa, değişen gereksinimlere, birikmiş teknik borca atfedilecektir — 'çalışıyor'un 'iyi yapılandırılmış'ın yerine geçmesine izin verme kararı dışında her şeye.

Paylaş: