KISS v mobilním vývoji — co to je, princip jednoduchosti a jak ho aplikovat

Co je KISS?

KISS (Keep It Simple, Stupid) — princip návrhu vyžadující minimalizaci složitosti systému. Byl formulován v americkém námořnictvu v 60. letech 20. století inženýrem Kelly Johnsonem (Lockheed SR-71 Blackbird). Johnson požadoval, aby letadlo mohl opravit mechanik v polních podmínkách bez speciálního nářadí — to je podstata KISS.

Ve vývoji softwaru KISS znamená: řešení by mělo být tak jednoduché, jak je to možné, ale ne jednodušší (druhá část věty je připisována Albertu Einsteinovi). Jednoduchost — není synonymem primitivnosti; jednoduché řešení provádí úkol s minimální redundancí.

Výzkum Google Research (2022) ukázal: průměrná doba vstupu do projektu pro nového vývojáře je 3 týdny v projektech dodržujících KISS oproti 10 týdnům v projektech s nadměrnou architekturou. Jednoduchý kód — investice do rychlosti adaptace nových členů týmu.

Aplikujte KISS jako filtr: před přidáním nové abstrakce se zeptejte sami sebe „řeší to problém, který vznikl dnes, nebo problém, který může nastat za rok?” Pokud to druhé — nedělejte to.

KISS a Occamova břitva

Occamova břitva (14. století) — filozofický princip: „nemnožit entity bez nutnosti”. V programování to znamená: ze dvou řešení stejně vyhovujících požadavkům vyberte to s méně entitami (třídami, moduly, závislostmi). KISS — praktická implementace Occamovy břitvy v kódu.

Rozdíl je v tom, že Occamova břitva je obecný princip poznání, zatímco KISS je konkrétní inženýrská praxe s měřitelným výsledkem: snížení cyklomatické složitosti, snížení počtu řádků kódu, zkrácení doby code review. Metriky umožňují objektivní hodnocení dodržování KISS.

Řiďte se metrikou: kód je považován za „dostatečně jednoduchý”, pokud nový vývojář pochopí fragment do jedné minuty bez komentářů. Pokud je potřeba více — zjednodušte.

Proč je jednoduchost v mobilním vývoji kritická?

Mobilní vývoj má tři vlastnosti, které činí KISS obzvláště důležitým: omezené zdroje zařízení (paměť, procesor), časté aktualizace platforem (iOS ročně, Android — čtvrtletně) a potřeba rychlého doručování funkcí přes CI/CD. Složitý kód toto tempo nevydrží.

Analýza Apple WWDC 2023: „Embrace Swift Generics” ukázala: průměrný iOS projekt obsahuje 40–60 % „mrtvého kódu” — abstrakcí napsaných pro budoucnost, které se nikdy nepoužijí. Tento kód nejen zvětšuje velikost binárního souboru, ale také zpomaluje kompilaci a ztěžuje navigaci. KISS tomu předchází: pište jen to, co je potřeba teď.

Podle Android Developer Relations Report (2024) mají projekty s nízkým poměrem kódu k testům (méně než 1:0.8) o 67 % více produkčních chyb. Složitý kód se hůře testuje — to je přímá hrozba pro kvalitu. Jednoduchost — nezbytná podmínka pro vysoké pokrytí testy.

Měřte složitost svého kódu pomocí metrik: cyklomatická složitost (Cyclomatic Complexity) — udržujte každou metodu pod 10, ideálně do 5. Použijte Detekt (Android) nebo SwiftLint (iOS) pro automatickou kontrolu.

KISS vs overengineering: praktické příklady

Nadměrná architektura: příliš mnoho vrstev

Typický overengineering — vytvoření abstraktní továrny repozitářů v projektu s jedním zdrojem dat. Místo jednoduché třídy Repository vývojář staví řetězec: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — kvůli hypotetické změně API na GraphQL.

Podle průzkumu JetBrains Developer Survey (2023) přiznalo 43 % vývojářů pro Android, že alespoň jednou při refaktorování vyhodili architektonickou vrstvu, protože se nepoužívala. KISS říká: vytvářejte abstrakci, když se objeví druhá implementace, ne v očekávání.

Začněte s konkrétní implementací bez rozhraní. Když se objeví druhý zdroj dat — extrahujte rozhraní pomocí refaktorování (IDE to udělá automaticky). Je to rychlejší než psát rozhraní předem.

Příliš komplikované grafy vkládání závislostí

DI frameworky (Dagger, Hilt, Swinject) — mocné nástroje, ale často vyvolávají komplikování. Vývojáři vytvářejí samostatný modul pro každou entitu, i když se používá na jednom místě. KISS alternativa: ruční vkládání přes konstruktor pro jednoduché případy.

// Overengineering: modul pro jeden repozitář
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: ruční vkládání, pokud je repozitář jeden
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

Ruční vkládání v konstruktoru — nejjednodušší DI vzor. Nevyžaduje generování kódu, anotace ani moduly. Přepněte na DI framework až když projekt dosáhne 5+ obrazovek a ruční vkládání se stane obtížně udržovatelným.

Jak aplikovat KISS v Androidu a iOS?

KISS v Androidu: jednoduché ViewModel a LiveData

Android ViewModel — častý zdroj nadměrné složitosti. Vývojáři přidávají StateFlow, combine, flatMapLatest a transformační řetězce tam, kde stačí jednoduchý MutableLiveData s postValue. KISS doporučuje: začněte s nejjednodušším řešením (LiveData), komplikujte jen pro konkrétní úkol (resetování stavu, debounce).

// KISS: jednoduchý ViewModel bez reaktivních řetězců
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)
        }
    }
}

V tomto příkladu ViewModel používá coroutine pro asynchronní požadavek, LiveData pro publikování výsledku. Žádný StateFlow, žádný combine — jen to, co je skutečně potřeba. Přidejte StateFlow když je vyžadován jednosměrný tok dat (UDF) s explicitním stavem.

KISS v iOS: jednoduché struktury místo tříd

V iOS se princip KISS projevuje preferencí struktur (struct) před třídami (class) pro datové modely. Struktury jsou hodnotové typy, nevyžadují správu paměti přes ARC, jsou standardně neměnné. Třídy jsou odůvodněné pouze při potřebě identity (dva odkazy na stejný objekt) nebo dědičnosti.

// KISS: struct místo class pro model
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class s ručním init a deinit
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

Struktura User automaticky získává memberwise init, podporu Equatable a Hashable (na všech polích), neměnnost a bezpečnost v vícevláknovém prostředí. Třída vyžaduje ruční init, implementaci NSObject a je náchylná k race conditions prostřednictvím sdíleného stavu.

Jednoduchost v síťové vrstvě

Síťová vrstva — další oblast, kde je KISS často porušován. Vývojáři přidávají řetězec Interceptorů s 5+ prvky, serializaci přes abstraktní továrny a mappery pro každý endpoint. KISS řešení: jeden URLSession s konfigurací a jedno dekódování přes Codable/JSON.

Podle doporučení Apple: URLSession Programming Guide (2023) pokrývá jednoduchá síťová vrstva na URLSession s Codable 95 % scénářů mobilní aplikace. Složité řetězce Interceptorů jsou potřeba jen pro specifické případy: obnovení tokenů, logování, šifrování.

Začněte s jednoduchou síťovou vrstvou na URLSession + Codable. Přidávejte Interceptor podle skutečné potřeby, ne do zásoby. To zkracuje kód síťové vrstvy 2–3krát.

Typické chyby při dodržování KISS

Záměna jednoduchosti a primitivnosti

Jednoduchost — není totéž co primitivnost. Jednoduché řešení je výstižné, srozumitelné a řeší úkol bez nadbytečnosti. Primitivní — ignoruje osvědčené postupy a zdravou architekturu. Rozdíl je v tom, že jednoduché řešení lze snadno rozšířit, zatímco primitivní — ne.

Příklad: použití Activity jako jediné entity pro všechny obrazovky — to je primitivnost, ne jednoduchost. Jednoduchost — použití Navigation Component s různými Fragmenty pro různé obrazovky, ale bez zbytečných abstrakcí. KISS neospravedlňuje špatnou architekturu.

Zkontrolujte se: může se váš kód změnit při přidání nové funkce? Pokud ano — jednoduchost je správná. Pokud pro každou funkci musíte vše přepsat — to je primitivnost, neodkladně refaktorujte.

Ignorování vzorů ve jménu KISS

Vzory (MVVM, MVI, Coordinator) — nejsou komplikování, ale strukturování. KISS nezakazuje používání osvědčených architektonických vzorů. Zakazuje se jejich nadměrné používání: tři vzory tam, kde by stačil jeden. Zlatá střední cesta — jeden architektonický vzor na projekt a ne více než 2–3 pomocné (DI, Navigation).

Podle State of Mobile Architecture Report (2024) mají projekty používající přesně jeden architektonický vzor o 34 % méně chyb v prvním roce vývoje než „frankensteinovské” projekty s kombinací 3+ vzorů. Vyberte MVVM nebo MVI pro mobilní projekt — a držte se ho na všech obrazovkách.

Nemíchejte MVVM a MVI v jednom projektu. Pokud tým zvolil MVVM — celý projekt by měl následovat MVVM. Výjimka — samostatné moduly funkcí s vlastním architektonickým řešením, ale to by měla být vědomá volba.