KISS ve YAGNI: Ne zaman sade kalmalı?

Sade kod yazmak ile gelecekte gerekebilecek bir özelliği şimdiden yapmamak yakın görünür, fakat aynı karar değildir. KISS bugünkü gereksinimi karşılayan çözümün karmaşıklığıyla; YAGNI henüz gerekmeyen yetenekleri ekleyip eklememekle ilgilidir.

İki farklı karar

KISS: Gerekli davranışı daha az hareketli parçayla açıkça anlatabiliyor ve doğru uygulayabiliyor muyum?
YAGNI: Şu an kimsenin kullanmadığı bir yeteneği, ileride gerekebilir diye mi ekliyorum?

Bu soruları birbirine karıştırmak, mevcut gereksinimi eksik uygulamaya veya geleceğe dair her fikri koda dönüştürmeye yol açar.

CSV dışa aktarma örneği

Bir API’de kullanıcıların mevcut raporu CSV olarak indirmesi gerekiyor. İstenen alanlar ve yetki kuralı belli. Henüz PDF, Excel veya üçüncü taraf dışa aktarma eklentisi istenmedi.

Bugünkü iş, doğru veriyi yetkili kullanıcıya geçerli bir CSV dosyası olarak sunmaktır. Bunun için dosya adını, kaçış kurallarını, hata durumlarını ve gereken sınamaları ele almak gerekir. Aynı anda genel bir “her biçimi destekleyen eklenti motoru” kurmak bugünkü işi tamamlamak için gerekli değildir.

KISS — Bugünkü çözüm

KISS’i bu örneğe uygularsak açık bir rapor sorgusu, küçük bir CSV yazıcısı ve anlaşılır bir endpoint akışı seçeriz. Aynı işi yapmak için gereksiz katmanlar, genel amaçlı fabrikalar ve konfigürasyon seçenekleri eklemeyiz.

En kısa kod her zaman en sade çözüm değildir. Tek satıra sıkıştırılmış, hata durumları belirsiz bir dışa aktarma işlevi; birkaç açık adımdan daha zor anlaşılır ve değiştirilir.

YAGNI — Varsayılan gelecek

YAGNI’yi bu örneğe uygularsak PDF/Excel çıktısını ve dışarıdan yüklenebilen biçim eklentilerini gerçek bir ihtiyaç oluşana kadar eklemeyiz. Gereksinim geldiğinde mevcut CSV akışını gözden geçirip ortak davranış gerçekten oluşmuşsa soyutlarız.

YAGNI, kodun sağlığını koruyan yeniden düzenlemeleri veya bugün gerekli olan testleri yasaklamaz. Değiştirmesi kolay bir kod tabanı, özelliği ihtiyaç doğduğunda eklemeyi mümkün kılar.

Sadelik neleri kapsamaz?

Bu iki yaklaşım; yetkilendirmeyi, veri doğruluğunu, hata işlemeyi veya erişilebilirliği “sonra bakarız” diyerek atlamak için gerekçe değildir. Bunlar mevcut özelliğin doğru çalışmasının parçasıysa şimdi ele alınmalıdır.

Benzer şekilde, soyutlama her zaman gereksiz değildir. Birden çok gerçek kullanım aynı davranışı paylaşıyorsa onu tek yerde toplamak karmaşıklığı azaltabilir. Karar, hayal edilen kullanım sayısına değil mevcut gereksinim ve bakım maliyetine dayanmalıdır.

Karar soruları

Bu yeteneği bugün kullanan gerçek bir senaryo var mı?
Mevcut çözüm gereksinimi doğru ve anlaşılır biçimde karşılıyor mu?
Eklediğim parça bugünün işini mi kolaylaştırıyor, varsayılan bir geleceği mi hazırlıyor?
Gereksinim değişirse kodu güvenle değiştirebilir miyim?