Yazılım projelerini zorlaştıran şey çoğu zaman problemin kendisi değil, ona eklenen gereksiz karmaşıklıktır. DRY, KISS ve YAGNI; onlarca yıldır geliştiricilere aynı şeyi hatırlatan üç kısa ilkedir: sade kal, tekrar etme, bugün ihtiyacın olmayanı yapma.
DRY: Kendini tekrar etme
"Don't Repeat Yourself" ilkesi, her bilginin sistemde tek ve yetkili bir yerde bulunması gerektiğini söyler. KDV oranı on farklı dosyada yazıyorsa, oran değiştiğinde birini unutmanız kaçınılmazdır.
// Tekrar: her yerde 0.20
var kdv = tutar * 0.20m;
// Tek kaynak
var kdv = tutar * VergiAyarlari.KdvOrani;DRY'ın yanlış uygulanması
DRY, bilgi tekrarı ile ilgilidir; görünüş benzerliği ile değil. Bugün benzer görünen iki kod parçası farklı nedenlerle değişecekse onları zorla birleştirmek, ileride ikisini birden bozan bir soyutlama doğurur. "Yanlış soyutlama, tekrardan daha pahalıdır" sözü bu yüzden sık alıntılanır. Pratik kural: aynı şeyi üçüncü kez yazarken soyutlamayı düşünün.
KISS: Basit tut
"Keep It Simple" ilkesi, çalışan en basit çözümü tercih etmeyi önerir. Basit kod daha az hata içerir, daha kolay test edilir ve başkası tarafından daha hızlı anlaşılır.
Karmaşıklığın tipik kaynakları:
- Küçük bir uygulama için gereğinden fazla katman ve desen
- Tek kullanıcılı bir program için dağıtık mimari (monolit mi mikroservis mi)
- Okunabilirlikten ödün veren "zekice" tek satırlık kodlar
YAGNI: Ona ihtiyacın olmayacak
"You Aren't Gonna Need It" ilkesi, gelecekte belki gerekir diye bugün özellik veya altyapı eklemeyi reddeder. "İleride çok dil desteği gerekebilir", "belki farklı veritabanına geçeriz" gibi varsayımlar çoğu zaman gerçekleşmez; ama yazılan kodun bakım maliyeti her gün ödenir.
YAGNI, kötü tasarım yapmak demek değildir. Kodu değiştirmeye açık tutarsınız ama değişikliği önceden yapmazsınız. Bu yaklaşım, MVP mantığıyla da örtüşür: önce gerçekten ihtiyaç duyulanı teslim et, sonra veriye göre büyü.
Üç ilkenin dengesi
| İlke | Sorulacak soru |
|---|---|
| DRY | Bu bilgi değişirse kaç yeri güncellemem gerekir? |
| KISS | Daha basit ve aynı işi gören bir çözüm var mı? |
| YAGNI | Bu özellik bugün gerçek bir ihtiyaca mı karşılık geliyor? |
Bu sorular code review sırasında da işe yarar. Bkz. code review rehberi.
Sık sorulan sorular
YAGNI, ölçeklenebilirliği düşünmemek mi demek?
Hayır. Bilinen ve yakın ihtiyaçlar tasarımda dikkate alınır; YAGNI yalnızca spekülatif ihtiyaçlara karşı uyarır.
Bu ilkeler sadece yazılımcılar için mi?
Proje kapsamını belirlerken de geçerlidir. Gereksiz özellikler bütçeyi ve süreyi büyütür. Bkz. kapsam kayması.
Sonuç
DRY tekrarı, KISS karmaşıklığı, YAGNI ise gereksiz işi önler. Üçünü dengeli uygulamak, daha az kodla daha çok değer üretmenin yoludur.
