Yazılımda 'Çalışıyor' Neden Yanlış Bir Kalite Ölçütü

Bu yazı, yazılım mühendisliğinin diğer mühendislik dallarından ayrılan temel bir sorununa odaklanıyor: fiziksel geri bildirimin yokluğu. Bir köprü çökerse hata somut ve izlenebilirdir; ama yanlış soyutlamalar üzerine kurulmuş bir yazılım sistemi de en az doğru kurulmuş biri kadar derlenir, çalışır ve testleri geçer. Bu yüzden mimari hatalar genellikle asla teşhis edilmez; sorumluluk yanlışlıkla karmaşık domain'e, değişen gereksinimlere ya da önceki ekibin dikkatsizliğine yüklenir.

Yazı, 'çalışıyor mu' sorusunun endüstri genelinde kalite ölçütü haline gelmesinin bu görünmezliği körüklediğini savunuyor. Bir sistem her fonksiyonel gereksinimi karşılarken bile iş kurallarının üç farklı katmana dağılmış, tekrarlanmış ve tutarsız şekilde kodlanmış olması mümkündür — bu, yeni bir gereksinim tüm bu kopyalara aynı anda dokunana kadar hiçbir hata belirtisi vermez. Çözüm önerisi, dikkati sistemin davranışından altındaki mekaniğe kaydırmak: kavramlar arası ilişkiler, sorumlulukların doğru yerde tutulması ve kuralların tek, bulunabilir bir yerde yaşaması.

Kütüphane ödünç verme örneği üzerinden yazar, bir 'ödünç alma' olayının kitabın bir özelliği değil, kendi yaşam döngüsüne sahip ayrı bir kavram olması gerektiğini gösteriyor; bu ayrımı yanlış modellemek, davranışsal olarak fark edilmeyen ama yapısal olarak yanlış bir sistem üretir. Fred Brooks'un esansiyel ve tesadüfi karmaşıklık ayrımına referansla, sorunun aracın veya çerçevenin seçimi değil, problemin doğasının doğru temsil edilip edilmediği olduğu vurgulanıyor.

Mühendisler için bu, kod incelemelerinde ve mimari kararlarda 'çalışıyor mu' testinin ötesine geçilmesi gerektiği anlamına geliyor: asıl soru, iş mantığının mekaniklerinin doğru yerde, tekilleştirilmiş ve anlaşılır şekilde temsil edilip edilmediği olmalı.