Mobil geliştirmede KISS — nedir, basitlik ilkesi ve nasıl uygulanır

KISS Nedir?

KISS (Keep It Simple, Stupid), sistem karmaşıklığını en aza indirmeyi gerektiren bir tasarım ilkesidir. 1960'larda ABD Donanması'nda mühendis Kelly Johnson (Lockheed SR-71 Blackbird) tarafından formüle edilmiştir. Johnson, uçağın özel aletler olmadan sahadaki bir teknisyen tarafından tamir edilebilir olmasında ısrar etti — KISS'in özü budur.

Yazılım geliştirmede KISS şu anlama gelir: bir çözüm mümkün olduğunca basit olmalı, ancak daha basit olmamalıdır (cümlenin ikinci kısmı Albert Einstein'a atfedilir). Basitlik ilkelliğin eşanlamlısı değildir; basit bir çözüm, görevi minimum fazlalıkla yerine getirir.

Google Research (2022) çalışması, KISS'i izleyen projelerde yeni bir geliştirici için ortalama uyum süresinin 3 hafta olduğunu, aşırı mimariye sahip projelerde ise 10 hafta olduğunu gösterdi. Basit kod, yeni ekip üyelerinin uyum hızına yapılan bir yatırımdır.

KISS'i bir filtre olarak kullanın: yeni bir soyutlama eklemeden önce kendinize şunu sorun “Bu, bugün var olan bir sorunu mu çözüyor, yoksa bir yıl içinde ortaya çıkabilecek bir sorunu mu?” İkincisiyse — yapmayın.

KISS ve Occam'ın Usturası

Occam'ın Usturası (14. yüzyıl) felsefi bir ilkedir: “varlıklar gereksiz yere çoğaltılmamalıdır.” Programlamada bu şu anlama gelir: gereksinimleri eşit derecede karşılayan iki çözümden, daha az varlığa (sınıf, modül, bağımlılık) sahip olanı seçin. KISS, Occam'ın Usturası'nın kod içindeki pratik uygulamasıdır.

Fark şudur ki Occam'ın Usturası genel bir bilgi ilkesiyken, KISS ölçülebilir sonuçları olan belirli bir mühendislik pratiğidir: azaltılmış döngüsel karmaşıklık, daha az kod satırı, daha kısa kod inceleme süresi. Metrikler, KISS'e uyumu objektif olarak değerlendirmeyi sağlar.

Bu metriği izleyin: yeni bir geliştirici, yorum olmadan bir dakika içinde kod parçasını anlıyorsa kod “yeterince basit” kabul edilir. Daha fazla zaman gerekiyorsa — basitleştirin.

Mobil Geliştirmede Basitlik Neden Kritiktir?

Mobil geliştirme, KISS'i özellikle önemli kılan üç özelliğe sahiptir: sınırlı cihaz kaynakları (bellek, işlemci), sık platform güncellemeleri (iOS yıllık, Android üç aylık) ve CI/CD aracılığıyla hızlı özellik teslimi ihtiyacı. Karmaşık kod bu tempoya ayak uyduramaz.

Apple WWDC 2023: “Embrace Swift Generics” analizi, ortalama iOS projesinin %40–60 oranında “ölü kod” içerdiğini gösterdi — “gelecek için” yazılmış ancak hiç kullanılmayan soyutlamalar. Bu kod yalnızca ikili dosya boyutunu artırmakla kalmaz, aynı zamanda derlemeyi yavaşlatır ve gezinmeyi karmaşıklaştırır. KISS bunu önler: yalnızca şimdi ihtiyaç duyulanı yazın.

Android Developer Relations Report (2024)'e göre, düşük kod-test oranına (1:0.8'in altında) sahip projelerde %67 daha fazla üretim hatası bulunur. Karmaşık kodun test edilmesi daha zordur — bu kalite için doğrudan bir tehdittir. Basitlik, yüksek test kapsamı için bir ön koşuldur.

Metrikler aracılığıyla kodunuzun karmaşıklığını ölçün: döngüsel karmaşıklık — her yöntemi 10'un altında tutun, ideal olarak 5'in altında. Otomatik kontrol için Detekt (Android) veya SwiftLint (iOS) kullanın.

KISS ve Overengineering: Pratik Örnekler

Aşırı Mimari: Çok Fazla Katman

Tipik overengineering, tek bir veri kaynağına sahip bir projede soyut depo fabrikası oluşturmaktır. Basit bir Repository sınıfı yerine, geliştirici bir zincir oluşturur: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — API'yi GraphQL'e değiştirme varsayımsal olasılığı için.

JetBrains Developer Survey (2023)'e göre, Android geliştiricilerinin %43'ü yeniden düzenleme sırasında bir mimari katmanı kaldırdığını itiraf etti çünkü hiç kullanılmamıştı. KISS şunu söyler: soyutlamayı ikinci bir uygulama seçeneği ortaya çıktığında oluşturun, önceden tahmin ederek değil.

Arayüzsüz somut bir uygulamayla başlayın. İkinci bir veri kaynağı ortaya çıktığında — yeniden düzenleme yoluyla arayüzü çıkarın (IDE bunu otomatik olarak yapacaktır). Bu, önceden bir arayüz yazmaktan daha hızlıdır.

Aşırı Karmaşık Bağımlılık Enjeksiyonu Grafları

DI çerçeveleri (Dagger, Hilt, Swinject) güçlü araçlardır, ancak genellikle karmaşıklığı tetiklerler. Geliştiriciler, yalnızca bir yerde kullanılsa bile her varlık için ayrı bir modül oluşturur. KISS alternatifi: basit durumlar için yapıcı üzerinden manuel enjeksiyon.

// Overengineering: tek bir depo için modül
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: tek depo varsa manuel enjeksiyon
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

Yapıcıda manuel enjeksiyon en basit DI modelidir. Kod üretimi, ek açıklama veya modül gerektirmez. Proje 5+ ekrana ulaşıp manuel enjeksiyonun bakımı zorlaştığında geçiş yapın.

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

Android'de KISS: Basit ViewModel ve LiveData

Android ViewModel, aşırı karmaşıklığın sık görülen bir kaynağıdır. Geliştiriciler, basit bir MutableLiveData ve postValue'nun yeterli olduğu yerlere StateFlow, combine, flatMapLatest ve dönüşüm zincirleri ekler. KISS şunu önerir: en basit çözümle (LiveData) başlayın, yalnızca belirli bir ihtiyaç için (durum sıfırlama, debounce) karmaşıklaştırın.

// KISS: reaktif zincirler olmadan basit ViewModel
class ProfileViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name

    fun loadUser(id: String) {
        viewModelScope.launch {
            _name.postValue(repo.getUser(id).name)
        }
    }
}

Bu örnekte ViewModel, eşzamansız istek için bir coroutine kullanır, sonucu yayınlamak için LiveData kullanır. StateFlow yok, combine yok — yalnızca gerçekten ihtiyaç duyulan şey. Açık durumla tek yönlü veri akışı (UDF) gerektiğinde StateFlow ekleyin.

iOS'ta KISS: Sınıflar Yerine Basit Yapılar

iOS'ta KISS ilkesi, veri modelleri için sınıflar (class) yerine yapıların (struct) tercih edilmesiyle kendini gösterir. Yapılar değer türüdür, ARC aracılığıyla bellek yönetimi gerektirmez ve varsayılan olarak değiştirilemez. Sınıflar yalnızca kimlik (aynı nesneye iki referans) veya kalıtım gerektiğinde haklı çıkarılabilir.

// KISS: model için class yerine struct
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: manuel init ve deinit ile class
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

User yapısı otomatik olarak memberwise init, Equatable ve Hashable uyumluluğu (tüm alanlarla), değişmezlik ve çoklu iş parçacıklı ortamda güvenlik kazanır. Bir sınıf, manuel init, NSObject uygulaması gerektirir ve paylaşılan durum aracılığıyla yarış koşullarına açıktır.

Ağ Katmanında Basitlik

Ağ katmanı, KISS'in sıklıkla ihlal edildiği başka bir alandır. Geliştiriciler 5+ öğeli Interceptor zinciri, soyut fabrikalar aracılığıyla serileştirme ve her uç nokta için eşleyiciler ekler. KISS çözümü: yapılandırmayla bir URLSession ve Codable/JSON aracılığıyla tek bir kod çözme.

Apple URLSession Programlama Kılavuzu (2023)'e göre, URLSession ve Codable ile basit bir ağ katmanı, mobil uygulama senaryolarının %95'ini kapsar. Karmaşık Interceptor zincirleri yalnızca belirli durumlar için gereklidir: token yenileme, günlük kaydı, şifreleme.

URLSession + Codable tabanlı basit bir ağ katmanıyla başlayın. “İhtiyaç halinde” değil, gerçek ihtiyaçlar ortaya çıktığında Interceptor'lar ekleyin. Bu, ağ katmanı kodunu 2–3 kat azaltır.

KISS'i İzlerken Yapılan Tipik Hatalar

Basitlik ve İlkelliği Karıştırmak

Basitlik ilkellikle aynı şey değildir. Basit bir çözüm, görevi fazlalık olmadan çözen öz ve net bir çözümdür. İlkel bir çözüm, en iyi uygulamaları ve sağlam mimariyi görmezden gelir. Fark, basit bir çözümün genişletilmesinin kolay olması, ilkel bir çözümün ise olmamasıdır.

Örnek: tüm ekranlar için tek varlık olarak Activity kullanmak ilkelliktir, basitlik değil. Basitlik, farklı ekranlar için farklı Fragment'larla Navigation Component kullanmaktır, ancak gereksiz soyutlamalar olmadan. KISS kötü mimariyi haklı çıkarmaz.

Kendinizi kontrol edin: yeni bir özellik eklerken kodunuz değişebilir mi? Evetse — basitlik doğrudur. Her özellik her şeyi yeniden yazmayı gerektiriyorsa — bu ilkelliktir, hemen yeniden düzenleyin.

KISS Adına Kalıpları Görmezden Gelme

Kalıplar (MVVM, MVI, Coordinator) karmaşıklık değil, yapılandırmadır. KISS, kanıtlanmış mimari kalıpların kullanımını yasaklamaz. Aşırı kullanımlarını yasaklar: birinin yeterli olduğu yerde üç kalıp kullanmak. Altın orta, proje başına bir mimari kalıp ve en fazla 2–3 yardımcı kalıptır (DI, Navigation).

State of Mobile Architecture Report (2024)'e göre, tam olarak bir mimari kalıp kullanan projeler, 3+ kalıbı birleştiren “Frankenstein” projelerine göre geliştirmenin ilk yılında %34 daha az hataya sahiptir. Mobil bir proje için MVVM veya MVI seçin — ve tüm ekranlarda buna bağlı kalın.

Aynı projede MVVM ve MVI'yı karıştırmayın. Ekip MVVM'yi seçtiyse — tüm proje MVVM'yi izlemelidir. İstisnalar, kendi mimari kararına sahip bireysel özellik modülleridir, ancak bu bilinçli bir seçim olmalıdır.