Bir yazılım projesinde karmaşıklık çoğu zaman zekânın kostümü gibi görünür. On iki katmanlı soyutlamalar, her sınıf için ayrı bir arayüz, küçük bir işlem için devasa bir tasarım deseni koleksiyonu… Bunlar ilk bakışta etkileyicidir. Fakat bilişimde etkileyici olmak ile iyi olmak aynı şey değildir. Zarafet ilkesi, çözümün gösterdiği kas gücünden çok, problemi ne kadar doğrudan, anlaşılır ve güvenilir biçimde çözdüğüne bakar. İyi kod, geliştiricinin ne kadar çok şey bildiğini değil; neyi gereksiz yere kullanmadığını da gösterir.
Zarafet: Az Kod Değil, Az Gereksiz Karar
Zarif bir çözüm mutlaka en kısa çözüm değildir. Tek satıra sıkıştırılmış, yalnızca yazarı tarafından çözülebilen bir ifade zarif sayılmaz; o, çoğu zaman şifrelenmiş bir egodur. Zarafet; okunabilirlik, doğru soyutlama, öngörülebilir davranış ve düşük bilişsel yükün birleşimidir. Bir fonksiyonun ne yaptığını anlamak için zihinde beş farklı dosya, üç tasarım deseni ve geçmişte alınmış iki mimari karar taşımak gerekiyorsa, orada bir sorun vardır. Kod bilgisayara değil, gelecekte onu değiştirecek insana da hizmet eder.
Örneğin bir listedeki tekrar eden öğeleri kaldırmak için özel bir sınıf hiyerarşisi, olay dinleyicileri ve yapılandırılabilir stratejiler kurmak mümkündür. Ama ihtiyaç yalnızca benzersiz öğeler elde etmekse, uygun bir veri yapısı kullanmak çoğu kez yeterlidir. Buradaki mesele tembellik değildir; problemin gerçek sınırını görme disiplinidir. Henüz ortaya çıkmamış ihtiyaçlar için mimari inşa etmek, yağmur ihtimaline karşı apartmanın çatısına deniz feneri dikmeye benzer.
Karmaşıklığın Gizli Faturası
Her ek katman bir maliyet üretir: Daha fazla test senaryosu, daha fazla hata olasılığı, daha uzun hata ayıklama süresi ve daha zor onboarding süreci. Bir sistemin karmaşıklığı yalnızca satır sayısıyla ölçülmez. Bağımlılıkların yönü, durumların sayısı, bileşenler arasındaki görünmez anlaşmalar ve istisnaların birikimi de bu faturaya dahildir. Özellikle dağıtık sistemlerde küçük bir gereksiz soyutlama, ağ gecikmesi, tutarsız veri veya başarısız yeniden deneme gibi gerçek dünya sorunlarıyla birleştiğinde büyük bir belirsizliğe dönüşebilir.
Bu yüzden iyi mühendislik, önce en basit doğru çözümü kurar; sonra ölçer; ancak kanıt varsa karmaşıklaştırır. Performans darboğazı gerçekten nerede? Güvenlik gereksinimi hangi sınırı zorunlu kılıyor? Sistemin hangi parçası değişken? Bu sorular yanıtlanmadan yapılan optimizasyon ve genelleştirme, çoğu zaman teknik borcun kibar adıdır. Donald Knuth’un erken optimizasyon uyarısı hâlâ canlıdır: Ölçmeden hızlandırmaya çalışmak, haritasız biçimde kestirme aramaktır.
Basitlik Bir Başlangıç Değil, Sürekli Bir Seçimdir
Zarafet ilkesi, her şeyi tek dosyaya koymak veya mimariyi reddetmek anlamına gelmez. Büyük sistemler modüllere, açık sınırlara ve dikkatli soyutlamalara ihtiyaç duyar. Ancak iyi soyutlama, karmaşıklığı saklamak için değil, onu yönetmek için vardır. Bir modülün içi karmaşık olabilir; dışarıdan ise mümkün olduğunca yalın bir sözleşme sunmalıdır. Kullanıcının ya da başka bir geliştiricinin anlaması gereken ayrıntı sayısı azaldıkça sistem daha sağlam hale gelir.
Sonuçta bilişimde zarafet, estetik bir süs değil, operasyonel bir erdemdir. Daha basit çözüm daha kolay test edilir, daha rahat anlatılır, daha güvenli değiştirilir ve arızalandığında daha çabuk onarılır. En iyi çözüm, en çok parçaya sahip olan değildir; doğru sayıda parçayla doğru işi yapan çözümdür. Kod yazarken sorulacak en değerli soru şudur: Bu karmaşıklık gerçekten problemi mi çözüyor, yoksa yalnızca problem çözüyor gibi mi görünüyor?