Uygulama Geliştirmede YAGNI: Nedir, Prensibin Özü ve Pratik Faydası

YAGNI Nedir?

YAGNI (You Aren't Gonna Need It) — “Buna ihtiyacın olmayacak” anlamına gelen bir aşırı programlama (XP) ilkesidir. Kural şöyledir: mevcut kullanıcı hikayeleri tarafından gerekmeyen işlevselliği asla uygulamayın. Bir özellik bugün gerekli değilse — “yedek olsun” diye bile yapmayın.

Terim, XP metodolojisinin ortak yazarlarından biri olan Ron Jeffries (Kent Beck ile birlikte) tarafından oluşturulmuştur. Jeffries şöyle demiştir: “Çalışan en basit şeyi uygulayın ve gerekli olana kadar hiçbir şey eklemeyin.” YAGNI planlama yasağı değil, erken uygulama yasağıdır.

Standish Group CHAOS Report (2023)'e göre, ortalama bir yazılım ürünündeki özelliklerin %64'ü nadiren veya hiç kullanılmaz. Bir mobil uygulamaya uyarlarsak — yazılan kodun yarısından fazlası kullanıcıya değer getirmez. YAGNI bu kaynak israfını önler.

YAGNI'yi katı bir filtre olarak uygulayın: her özellik “Şu anda hangi belirli kullanıcı sorununu çözüyor?” sorusuna cevap vermelidir. Cevap yoksa — özellik gerekli değildir.

YAGNI ile Tembellik ve Kestirme Yollar Arasındaki Fark

YAGNI kaliteli mimariyi reddetmek değildir. YAGNI gereksiz kod yazmayı yasaklar, ancak doğru kod yazmayı yasaklamaz. Mevcut bir özellik temiz bir soyutlama katmanına ihtiyaç duyuyorsa — oluşturun. Katman gerekli değilse — oluşturmayın. Temel fark: YAGNI işlevsellikle ilgilidir, kaliteyle değil.

Geliştiriciler genellikle YAGNI'yi kasıtlı teknik borç birikimiyle karıştırır (teknik borç her zaman bir uzlaşmadır, YAGNI bir verimlilik ilkesidir). Fark, teknik borcun kabul edilip belgelenmesi, YAGNI ihlalinin ise sadece fazladan iş olmasıdır.

Kendinize sorun: “Bu soyutlamayı şimdi oluşturmazsam, gerektiğinde yeniden düzenleme ne kadar sürer?” Yeniden düzenleme süresi şimdiki yazma süresinden daha kısaysa — erteleyin.

YAGNI Mobil Projeler İçin Neden Kritiktir?

Mobil geliştirme üç nedenden dolayı YAGNI ihlallerine karşı özellikle hassastır: APK/IPA boyutu doğrudan kurulum dönüşüm oranını etkiler, mobil projelerin derleme süresi kod hacmiyle doğrusal olarak artar ve her ek özellik hata noktaları ekler. YAGNI tembellikle değil, odaklanmayla ilgilidir.

Google Play Console Data (2023) araştırması şunu gösterdi: APK boyutundaki her 10 MB, kurulum olasılığını %1,2 azaltır. Kullanılmayan kod sadece depodaki çöp değildir — doğrudan finansal kayıptır. “Belki sonra ekleriz” işlevselliği için ekstra kütüphaneler, APK şişkinliğinin en yaygın kaynağıdır.

Gradle Build Performance Report (2024)'e göre, bir Android projesindeki her ek modül, tam derleme süresini 3–7 saniye artırır. “Yedek olsun” diye 5 modül eklerseniz — derleme süresi artışı derleme başına 15–35 saniye olacaktır. Bir yılda, 5 geliştiriciden oluşan bir ekip, derlemeyi beklerken 200 işgücü saatine kadar kaybeder.

CI'da ikili dosya boyutunu izleyin: bir uyarı sınırı belirleyin (örneğin, commit başına +500 KB). Yeni bir özellik olmadan boyut arttıysa — bu, kod incelemesinde tartışılması gereken bir YAGNI ihlalidir.

YAGNI ve Gold-Plating: Pratik Örnekler

Gold-plating: Erken Animasyon

Gold-plating — ürünü “iyileştirme” girişimiyle gereksinimlerin ötesinde işlevsellik eklemektir. Tipik bir örnek: tasarım basit bir geçiş (fade) belirtmesine rağmen, geliştiricinin ekranlar arasında karmaşık bir geçiş animasyonu eklemesi. Animasyon 2 gün sürer, kullanıcı fark etmez ve farklı cihazlardaki hatalar projeyi yıllarca takip eder.

UX Collective Annual Report (2023)'e göre, kullanıcıların %78'i bir uygulamayı animasyonlarla değil, hız ve kararlılıkla değerlendirir. YAGNI şöyle der: animasyon gereksinimlerde belirtilmemişse — uygulamayın. Tasarımcı, bir UX sorununu çözmek için gerçekten gerektiğinde animasyonu ekleyecektir.

Sadece taslaklarda olanı uygulayın. Tasarımcı bir animasyon çizmemişse — var olmamalıdır. Taslaktan herhangi bir sapma YAGNI ihlalidir.

20 Dile Erken Yerelleştirme

Startup'ların yaygın bir hatası: “Gelecekteki uluslararası pazara giriş için” hemen 20+ dil desteği oluşturmak. YAGNI şunları önerir: sadece mevcut pazarın dilinde yerelleştirin. Her yeni dil eklemek, çevirmen zamanı, dize kesilmesi testleri ve RTL düzen hata ayıklaması gerektirir.

Deloitte Digital Globalization Survey (2022)'e göre, mobil uygulamaların %60'ı ilk pazarlarından asla çıkmaz. Durumunuz buysa — çok dilli desteğe harcanan kaynaklar boşa gitmiştir. YAGNI yaklaşımı: İngilizce (temel) + hedef pazarın dili. Diğerleri — bir bölgeye fiilen girdiğinizde.

Önceliklendirme için YAGNI'yi kullanın: bir özellik önümüzdeki iki çeyreğin yol haritasında değilse — başlamayın. Yol haritası belgelenmeli ve ürün yöneticisi tarafından onaylanmalıdır.

Android ve iOS'ta YAGNI Nasıl Uygulanır?

Android'te YAGNI: Gereksiz Kütüphaneler Eklemeyin

Android projeleri kütüphane enflasyonundan muzdariptir. Geliştiriciler, iş mantığının ilk satırını yazmadan önce bile Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore ekler. YAGNI şunları önerir: kütüphaneleri önleyici olarak değil, gerçek ihtiyaca göre ekleyin.

// YAGNI ihlali: kütüphanelerin önleyici dahil edilmesi
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Ve uygulama sadece "Hello World" gösteriyor

Kütüphaneler kendi karmaşıklıkları olan bağımlılıklardır. Her biri sürüm güncellemeleri, yıkıcı değişikliklerde geçiş gerektirir ve APK boyutunu artırır. Ekleyin bir kütüphaneyi, o kütüphanenin çözdüğü belirli bir görev ortaya çıktığında. OkHttp (minimum HTTP istemcisi) ile başlayın, REST istemcisine ihtiyacınız olduğunda Retrofit ekleyin ve bu şekilde devam edin.

iOS'ta YAGNI: SwiftUI'yi Zorlamayın

SwiftUI güçlü bir framework'tür, ancak benimsenmesi gerçek ihtiyaçlar tarafından yönlendirilmelidir. Bir proje iOS 14+ ile başlıyorsa ve özel UI bileşen gereksinimleri minimumsa — SwiftUI iyi bir seçimdir. Bir proje iOS 13'ü desteklemek zorundaysa veya karmaşık özel hareketler gerektiriyorsa — UIKit doğru çözüm olarak kalır. YAGNI, “moda olduğu için” SwiftUI'ye geçiş yapmaya karşıdır.

// YAGNI: SwiftUI'den gerçek fayda olmadıkça UIKit kullanın
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profil"
    }
}

// SwiftUI gerekirse — UIHostingController üzerinden entegre edin
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) analizi şunları önerir: net bir iş nedeni olmadan (örneğin, tasarımcı için Canlı Önizleme ihtiyacı) mevcut UIKit ekranlarını SwiftUI'ye taşımayın. Çalışan kodu yeniden yazmak doğrudan bir YAGNI ihlalidir. SwiftUI — yeni ekranlar için, UIKit — mevcut olanlar için.

YAGNI'yi İzlerken Tipik Hatalar

YAGNI, Kötü Mimari İçin Bahane Olarak

En tehlikeli hata, kötü mimari için bahane olarak YAGNI'yi kullanmaktır. “Depo katmanı oluşturmayacağız çünkü YAGNI — sorguyu doğrudan ViewModel'de yazacağız.” Bu YAGNI değil, teknik borç biriktirmektir. YAGNI gereksiz işlevselliği yasaklar, mimari bütünlüğü değil.

Mimari, sürdürülebilirliğe yapılan bir yatırımdır. 3'ten fazla ekran yazıyorsanız — temel bir mimari katman (MVVM, depo) zaten haklıdır. 1 ekran ise — daha basit bir yaklaşımı tercih edebilirsiniz. Anahtar: mevcut özellikler için gereken mimari minimumu belirleyin ve daha fazlasını eklemeyin.

Kararları “mimari” ve “işlevsel” olarak ayırın. Mimari kararlar (katmanlar, navigasyon, DI) YAGNI kapsamına girmez — sürdürülebilirlik için gereklidirler. İşlevsel kararlar (özellikler, ekran görüntüleri, animasyonlar) — kapsama girer.

API'lerle Çalışırken YAGNI'yi Körü Körüne İzlemek

Diğer bir uç — gelecekteki API sözleşmelerini görmezden gelmek. Bir geliştirici, backend'den 5 alanlı bir JSON alır ve “YAGNI'ye göre diğerleri gerekli değil” diyerek sadece 3'ünü ayrıştırır. Sorun: bir alan eklendiğinde, yanıt değiştiyse backend ayrıştırmayı bozabilir. Çözüm, tüm yanıt alanlarını eşlemektir, şimdi hepsi kullanılmasa bile.

Meta API Design Guidelines (2023)'e göre, istemci, sunucu tarafından döndürülen tüm alanları ayrıştırmalı, kullanılmayanları yok saymalı, ancak tüm yapıyı atmamalıdır. YAGNI burada başka bir şeyle ilgilidir: “Backend onları döndürür diye” henüz belirtimde olmayan alanların işlenmesini eklemeyin.

Yanıt yapısının tamamını ayrıştırın (sunucunun şu anda döndürdüğü tüm alanlar). Mevcut API belirtiminde olmayan alanların işlenmesini eklemeyin. Bu, YAGNI ile değişime karşı dayanıklılık arasında bir dengedir.