KISS in mobiele ontwikkeling — wat is het, het principe van eenvoud en hoe je het toepast

Wat is KISS?

KISS (Keep It Simple, Stupid) — het ontwerpprincipe dat minimalisatie van systeemcomplexiteit vereist. Geformuleerd in de Amerikaanse marine in de jaren 1960 door ingenieur Kelly Johnson (Lockheed SR-71 Blackbird). Johnson eiste dat het vliegtuig door een monteur in het veld gerepareerd kon worden zonder speciaal gereedschap — dat is de essentie van KISS.

In softwareontwikkeling betekent KISS: de oplossing moet zo eenvoudig mogelijk zijn, maar niet eenvoudiger (het tweede deel van de zin wordt toegeschreven aan Albert Einstein). Eenvoud — is geen synoniem voor primitiviteit; een eenvoudige oplossing voert de taak uit met minimale redundantie.

Onderzoek van Google Research (2022) toonde aan: de gemiddelde tijd om in een project te komen voor een nieuwe ontwikkelaar is 3 weken in projecten met KISS-naleving tegenover 10 weken in projecten met overmatige architectuur. Eenvoudige code — een investering in de aanpassingssnelheid van nieuwe teamleden.

Pas KISS toe als filter: voordat je een nieuwe abstractie toevoegt, vraag jezelf af “loseat dit een probleem op dat vandaag is ontstaan of een probleem dat over een jaar kan ontstaan?” Als het tweede — doe het niet.

KISS en het scheermes van Occam

Het scheermes van Occam (14e eeuw) — filosofisch principe: “entiteiten moeten niet zonder noodzaak worden vermenigvuldigd”. In programmering betekent dit: kies uit twee oplossingen die even goed aan de eisen voldoen, degene met minder entiteiten (klassen, modules, afhankelijkheden). KISS — praktische implementatie van het scheermes van Occam in code.

Het verschil is dat het scheermes van Occam een algemeen cognitieprincipe is, terwijl KISS een concrete ingenieurs praktijk is met meetbaar resultaat: vermindering van cyclomatische complexiteit, vermindering van het aantal coderegels, verkorting van code review-tijd. Metrieken maken objectieve beoordeling van KISS-naleving mogelijk.

Volg de metriek: code wordt als “voldoende eenvoudig” beschouwd als een nieuwe ontwikkelaar het fragment binnen een minuut begrijpt zonder commentaar. Als er meer nodig is — vereenvoudig.

Waarom is eenvoud kritisch in mobiele ontwikkeling?

Mobiele ontwikkeling heeft drie kenmerken die KISS bijzonder belangrijk maken: beperkte apparaatbronnen (geheugen, processor), frequente platformupdates (iOS jaarlijks, Android — per kwartaal) en de noodzaak van snelle functielevering via CI/CD. Complexe code kan dit tempo niet aan.

Analyse van Apple WWDC 2023: “Embrace Swift Generics” toonde aan: een gemiddeld iOS-project bevat 40–60% “dode code” — abstracties geschreven voor de toekomst die nooit worden gebruikt. Deze code vergroot niet alleen de binaire grootte, maar vertraagt ook de compilatie en bemoeilijkt navigatie. KISS voorkomt dit: schrijf alleen wat nu nodig is.

Volgens Android Developer Relations Report (2024) hebben projecten met een lage code-tot-testverhouding (minder dan 1:0.8) 67% meer productiebugs. Complexe code is moeilijker te testen — dit is een directe bedreiging voor de kwaliteit. Eenvoud — een noodzakelijke voorwaarde voor hoge testdekking.

Meet de complexiteit van je code via metrieken: cyclomatische complexiteit (Cyclomatic Complexity) — houd elke methode onder 10, idealiter tot 5. Gebruik Detekt (Android) of SwiftLint (iOS) voor automatische controle.

KISS vs overengineering: praktische voorbeelden

Overmatige architectuur: te veel lagen

Typische overengineering — het creëren van een abstracte factory van repositories in een project met één gegevensbron. In plaats van een eenvoudige Repository-klasse bouwt de ontwikkelaar een keten: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — voor een hypothetische API-wijziging naar GraphQL.

Volgens JetBrains Developer Survey (2023) gaf 43% van de Android-ontwikkelaars toe dat ze minstens één keer een architectuurlaag hebben verwijderd tijdens refactoring omdat deze niet werd gebruikt. KISS zegt: maak een abstractie wanneer de tweede implementatie verschijnt, niet in afwachting.

Begin met een concrete implementatie zonder interface. Wanneer de tweede gegevensbron verschijnt — extraheer de interface via refactoring (de IDE doet dit automatisch). Dit is sneller dan de interface van tevoren schrijven.

Overmatig gecompliceerde dependency injection-grafen

DI-frameworks (Dagger, Hilt, Swinject) — krachtige tools, maar ze lokken vaak complicatie uit. Ontwikkelaars maken een aparte module voor elke entiteit, zelfs als deze op één plek wordt gebruikt. KISS-alternatief: handmatige injectie via constructor voor eenvoudige gevallen.

// Overengineering: module voor één repository
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: handmatige injectie, als er maar één repository is
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

Handmatige injectie in de constructor — het eenvoudigste DI-patroon. Het vereist geen codegeneratie, annotaties of modules. Schakel over naar een DI-framework pas wanneer het project 5+ schermen bereikt en handmatige injectie moeilijk te onderhouden wordt.

Hoe pas je KISS toe in Android en iOS?

KISS in Android: eenvoudige ViewModel en LiveData

Android ViewModel — een veelvoorkomende bron van overmatige complexiteit. Ontwikkelaars voegen StateFlow, combine, flatMapLatest en transformatieketens toe waar een eenvoudige MutableLiveData met postValue voldoende is. KISS beveelt aan: begin met de eenvoudigste oplossing (LiveData), compliceer alleen voor een specifieke taak (status resetten, debounce).

// KISS: eenvoudige ViewModel zonder reactieve ketens
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)
        }
    }
}

In dit voorbeeld gebruikt ViewModel een coroutine voor asynchrone aanvraag, LiveData voor het publiceren van het resultaat. Geen StateFlow, geen combine — alleen wat echt nodig is. Voeg StateFlow toe wanneer een unidirectionele gegevensstroom (UDF) met expliciete status vereist is.

KISS in iOS: eenvoudige structuren in plaats van klassen

In iOS manifesteert het KISS-principe zich door de voorkeur voor structuren (struct) boven klassen (class) voor gegevensmodellen. Structuren zijn waardetypen, vereisen geen geheugenbeheer via ARC, zijn standaard onveranderlijk. Klassen zijn alleen gerechtvaardigd bij vereiste identiteit (twee verwijzingen naar hetzelfde object) of overerving.

// KISS: struct in plaats van class voor model
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class met handmatige init en deinit
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

De structuur User krijgt automatisch memberwise init, ondersteuning voor Equatable en Hashable (op alle velden), onveranderlijkheid en veiligheid in multi-threaded omgeving. Een klasse vereist handmatige init, implementatie van NSObject en is vatbaar voor race conditions via gedeelde status.

Eenvoud in de netwerklaag

De netwerklaag — nog een gebied waar KISS vaak wordt geschonden. Ontwikkelaars voegen een Interceptor-keten van 5+ elementen, serialisatie via abstracte factories en mappers voor elk endpoint toe. KISS-oplossing: één URLSession met configuratie en één decoding via Codable/JSON.

Volgens de aanbevelingen van Apple: URLSession Programming Guide (2023) dekt een eenvoudige netwerklaag op URLSession met Codable 95% van de mobiele app-scenario's. Complexe Interceptor-ketens zijn alleen nodig voor specifieke gevallen: tokenverversing, logging, encryptie.

Begin met een eenvoudige netwerklaag op URLSession + Codable. Voeg Interceptor toe op basis van werkelijke behoefte, niet voor de zekerheid. Dit verkort de code van de netwerklaag met 2–3 keer.

Veelgemaakte fouten bij het volgen van KISS

Verwarring tussen eenvoud en primitiviteit

Eenvoud — is niet hetzelfde als primitiviteit. Een eenvoudige oplossing is beknopt, begrijpelijk en lost de taak op zonder overbodigheden. Primitief — negeert best practices en gezonde architectuur. Het verschil is dat een eenvoudige oplossing gemakkelijk uit te breiden is, maar een primitieve — niet.

Voorbeeld: het gebruik van Activity als enige entiteit voor alle schermen — dat is primitiviteit, geen eenvoud. Eenvoud — het gebruik van Navigation Component met verschillende Fragment voor verschillende schermen, maar zonder onnodige abstracties. KISS rechtvaardigt slechte architectuur niet.

Controleer jezelf: kan je code veranderen bij het toevoegen van een nieuwe functie? Zo ja — de eenvoud is juist. Als voor elke functie alles herschreven moet worden — is dit primitiviteit, refactor dringend.

Negeren van patronen in naam van KISS

Patronen (MVVM, MVI, Coordinator) — zijn geen complicatie, maar structurering. KISS verbiedt het gebruik van bewezen architectuurpatronen niet. Overmatig gebruik ervan is verboden: drie patronen waar één voldoende zou zijn. De gulden middenweg — één architectuurpatroon per project en niet meer dan 2–3 ondersteunende (DI, Navigation).

Volgens State of Mobile Architecture Report (2024) hebben projecten die precies één architectuurpatroon gebruiken 34% minder bugs in het eerste ontwikkeljaar dan “frankenstein”-projecten met een combinatie van 3+ patronen. Kies MVVM of MVI voor een mobiel project — en houd het op alle schermen aan.

Meng MVVM en MVI niet in één project. Als het team MVVM heeft gekozen — moet het hele project MVVM volgen. Uitzondering — aparte functiemodules met hun eigen architectuuroplossing, maar dit moet een bewuste keuze zijn.