Kötü kod projeyi yavaşlatır, ama gereksiz karmaşıklık projeyi öldürür. Başlangıçta "akıllıca" görünen mimari kararların nasıl birer teknik borç tuzağına dönüştüğünü ve "Lazy Ant" felsefesiyle bu tuzaklardan nasıl kaçınacağımızı inceleyelim.
Yazılım dünyasında bir efsane dolaşır: Bir sistem ne kadar karmaşıksa, onu yazan mühendis o kadar zekidir. Bu kocaman bir yalandır. Yazılım projelerinde karşılaştığımız en büyük düşman çoğu zaman hatalı kod (bug) değildir; o kodun etrafına örülen gereksiz karmaşıklıktır.
Biz buna Over-Engineering diyoruz. Yani, henüz var olmayan bir problemi, gelecekte olması muhtemel bir senaryo için, bugünden aşırı karmaşık bir mimariyle çözmeye çalışmak.
Over-engineering projeye bir anda girmez; sessizce sızar:
🐜 Gereksiz Soyutlama Katmanları: Sadece bir API çağrısı yapacak bir fonksiyon için 5 farklı interface ve provider tanımlamak.
🐜 "Gelecekte Lazım Olur" Sendromu: "Belki bir gün veritabanını değiştiririz" diyerek basit bir SQL sorgusunu 10 katmanlı bir abstraction arkasına saklamak.
🐜 Aşırı Konfigürasyon: İki değişkenle çözülecek iş için devasa bir JSON konfigürasyon sistemi kurmak.
Bir kullanıcının aktif olup olmadığını kontrol etmek istediğinizi düşünelim.
Lazy Ant Yaklaşımı (Sade):
JavaScript
Over-Engineered Yaklaşım (Tehlikeli): Bunun için bir UserStatusStateMachine oluşturmak, StatusFactory ile durumları üretmek ve BaseUserAbstractEntity sınıfından türetmek... Sonuç aynı, ama maliyet 100 kat daha fazla.
Her "akıllıca" katman, ekibe yeni bir zihinsel yük (mental overhead) yükler. Yeni gelen bir geliştirici dosyayı açtığında şu soruların altında ezilir:
Bu yapı neden var?
Bu soyutlama neyi çözüyor?
Değişiklik yapmak için kaç dosyayı güncellemem gerek?
Sorular arttıkça, geliştirme hızı düşer. Ekip, özellik geliştirmek yerine mimariyi ayakta tutmaya çalışırken yorulur.
Basit sistemler dayanıklıdır çünkü tahmin edilebilirdir. Bir karınca kolonisi gibi; her birim ne yapacağını bilir, karmaşık hiyerarşiler yoktur, sadece işlevsellik vardır.
🐜 Hızlı Onboarding: Yeni geliştirici ilk gününde kod yazabilir.
🐜 Kolay Debugging: Hatanın nerede olduğu bellidir, 10 katman aşağı inmeniz gerekmez.
🐜 Sürdürülebilirlik: 6 ay sonra koda baktığınızda "Ben burada ne yapmışım?" demezsiniz.
Yeni bir mimari katman eklemeden veya "havalı" bir kütüphane dahil etmeden önce şu soruyu sorun:
"Bu, şu an elimde olan gerçek ve somut bir problemi mi çözüyor?"
Cevabınız "Hayır, ama ileride..." ile başlıyorsa, durun. Sadeleştirin.
İyi mühendislik, karmaşık sistemler kurabilme yeteneği değil; karmaşıklığı yok edebilme becerisidir. En iyi çözüm, ilk bakışta en etkileyici görünen değil, en az açıklama gerektirendir. Az kod, az dert.
