Code Smell in mobiele ontwikkeling: essentie, soorten en principes van verhelpen

Wat is Code Smell

Code Smell (codegeur) — is een metafoor voor symptomen in de broncode die met grote waarschijnlijkheid wijzen op diepere problemen. De term zelf heeft geen formele definitie — het is een heuristiek gebaseerd op de ervaring van ontwikkelaars. Martin Fowler en Kent Beck hebben in 1999 voor het eerst 22 geuren gesystematiseerd in het boek „Refactoring“, en de meeste zijn na decennia nog steeds relevant.

Het is belangrijk het verschil te begrijpen tussen Code Smell en een bug. Een geur is geen fout: de code compileert, werkt en geeft het juiste resultaat. Het probleem is dat dergelijke code moeilijk te lezen, wijzigen en testen is. Na verloop van tijd stijgen de kosten van elke wijziging en neemt het vertrouwen in de juistheid van refactoring af. Statische analyse tools (SonarQube, Detekt, SwiftLint) detecteren automatisch veel geuren.

Het heuristische karakter van Code Smell betekent dat niet elke lange methode moet worden opgesplitst en niet elke grote klasse refactoring vereist. De beslissing wordt genomen door de ontwikkelaar, die de context beoordeelt: frequentie van wijzigingen, kritiekheid van de module, ontwikkelingsplannen. Ervaren ingenieurs ruiken de geur intuïtief — code „ruikt onaangenaam“, hoewel formeel alle regels worden nageleefd.

Belangrijkste soorten Code Smell

Fowler onderscheidde 22 geuren die in verschillende categorieën vallen. Voor mobiele ontwikkeling zijn de meest relevante structurele geuren, objectgeoriënteerde ontwerpgeuren en specifieke problemen gerelateerd aan platformbeperkingen. Laten we elke groep bekijken met voorbeelden uit de praktijk.

Structurele geuren

Long Method (lange methode) — de meest voorkomende geur in mobiele applicaties. Een scherm met een registratieformulier bevat vaak een enkele setupUI-methode van 200+ regels die alle Views creëert, constraints instelt, zich abonneert op gebeurtenissen en fouten afhandelt. Oplossing: opsplitsen in methoden per logisch blok — configureEmailField, configurePasswordField, setupConstraints, bindViewModel.

Large Class (grote klasse) — Activity of ViewController die verantwoordelijk is voor zowel weergave, navigatie, bedrijfslogica als netwerkcommunicatie. Een dergelijke klasse schendt het Single Responsibility Principle en bevat tientallen velden en methoden. In Android is dit vaak een Fragment van 1000+ regels dat de logica van verschillende schermen bevat. Oplossing: presenter/ViewModel scheiden, netwerkwerk naar repository verplaatsen, navigatie naar coordinator.

Duplicate Code (code duplicatie) — het kopiëren van dezelfde blokken in verschillende delen van de applicatie. Typisch voorbeeld: twee schermen die een productkaart tonen — in de catalogus en in favorieten. Als de weergavelogica is gekopieerd, zal het corrigeren van een fout op de ene plaats het niet op de andere verhelpen. Oplossing: gemeenschappelijke logica verplaatsen naar een herbruikbare component of extensie.

Objectgeoriënteerde ontwerpgeuren

Feature Envy (afgunst op een andere klasse) — de methode van een klasse maakt intensief gebruik van gegevens van een andere klasse. In Android uit zich dit wanneer ViewModel rechtstreeks de velden van het User-model benadert in plaats van een methode van het model aan te roepen. Signaal: als de methode kan worden verplaatst naar de klasse waarvan het gegevens gebruikt — verplaats hem dan. Switch Statements (conditieketens) — constructie switch of if-else keten die het type object controleert. In plaats daarvan moet polymorfisme of het strategy patroon worden gebruikt.

Data Class — een klasse die alleen gegevens opslaat maar geen gedrag bevat. Data class (in Kotlin) of structuren (in Swift) zijn op zichzelf geen geur. Het probleem ontstaat wanneer de bedrijfslogica die met deze gegevens werkt, verspreid is over de hele codebase in plaats van te worden ingekapseld. Refused Bequest — een overerfer gebruikt de meeste methoden van de ouder niet en overschrijft ze met lege implemenaties. Teken van onjuiste overerving: vervang overerving door compositie.

Geuren in mobiele ontwikkeling

God Activity / God Fragment — Activity of Fragment die alles weet: over levenscyclus, gegevens, navigatie, machtigingen, DI. Dit is de duurste klasse om te onderhouden in de applicatie. Oplossing: architectuurpatronen MVVM, MVI of Clean Architecture verdelen de verantwoordelijkheid. Giant ViewController — analoog voor iOS, waar UIViewController alle logica van het scherm bevat en vaak 500 regels overschrijdt.

Hardcoded Resources — strings, kleuren, afmetingen, API-URL's direct in de code ingebed. In Android schendt dit het gebruik van het R-bronnensysteem, in iOS — NSLocalizedString en Asset Catalog. Correctie: verplaats alle strings naar strings.xml of Localizable.strings, URL's naar configuratiebestand, afmetingen naar dimens. Leaking Context — het bewaren van een verwijzing naar Activity of ViewController langer dan de component zelf leeft. Leidt tot geheugenlekken en crashes. Oplossing: zwakke verwijzingen, Jetpack Lifecycle, RxSwift DisposeBag.

Hoe Code Smell te vinden

Code review — de meest betrouwbare manier om geuren te ontdekken. Het menselijk oog ziet onnatuurlijke constructies die automatische analyzers missen. De effectiviteit van code review neemt toe wanneer het team een checklist van typische geuren gebruikt. Het wordt aanbevolen om niet meer dan 200–400 regels code per sessie te controleren — na deze drempel neemt de aandacht af en beginnen geuren te ontsnappen.

Statische analyse automatiseert het zoeken naar structurele geuren. Voor Android zijn de standaard tools Detekt (Kotlin) en Android Lint, voor iOS — SwiftLint en SonarQube. Deze tools vinden lange methoden, grote klassen, codeduplicatie en vele andere problemen. Het is belangrijk de regels per project in te stellen — standaardconfiguraties zijn vaak te streng of laten juist kritieke geuren onopgemerkt.

Codemetrieken geven objectieve criteria: Cyclomatic Complexity (drempel >10 vereist aandacht), Lines of Code per Method (drempel >30), Depth of Inheritance (>3 — reden tot nadenken). Tools zoals CodeMetrics (Xcode) en Gradle Metrics Plugin bouwen grafieken van metricveranderingen in de tijd. Als de complexiteit van een methode is gestegen van 5 naar 15 na de laatste commit — is dit een signaal voor refactoring.

// Voorbeeld: methode met Cyclomatic complexiteit = 7 (boven drempel 5)
fun processOrder(order: Order) {
    if (order.status == Status.NEW) { /* 10 regels */ }
    else if (order.status == Status.PAID) { /* 15 regels */ }
    else if (order.status == Status.SHIPPED) { /* 20 regels */ }
    else if (order.status == Status.DELIVERED) { /* 8 regels */ }
    else if (order.status == Status.CANCELLED) { /* 5 regels */ }
    else { throw IllegalStateException() }
}

// Correctie: polymorfisme in plaats van switch
interface OrderHandler {
    fun handle(order: Order)
}

Automatisch zoeken naar geuren vervangt code review niet: statische analyzers vinden alleen structurele problemen, maar detecteren geen semantische geuren (Feature Envy, Inappropriate Intimacy). De combinatie van automatische tools en menselijke controle geeft het beste resultaat. Configureer de CI/CD-pijplijn zo dat de build faalt bij overschrijding van drempels voor complexiteit of methodelengte.

Hoe Code Smell te verhelpen

Refactoring — de belangrijkste methode om codegeuren te elimineren. Fowler beschrijft tientallen refactoringtechnieken, die elk toepasbaar zijn op een specifieke geur. Extract Method — voor lange methoden, Extract Class — voor grote klassen, Move Method — voor Feature Envy. Het is belangrijk refactoring in kleine stappen uit te voeren, waarbij de code na elke wijziging werkend blijft.

Tests vóór refactoring — een verplichte voorwaarde. Als code niet gedekt is door unittesten, verandert refactoring in herschrijven met onbekend resultaat. Voor legacy-code zonder tests gebruik je Characterisation Tests — schrijf tests die het huidige gedrag vastleggen, refactor vervolgens. Testen geeft de zekerheid dat de bedrijfslogica na refactoring niet is beschadigd.

Stapsgewijze aanpak — de sleutel tot succesvol verhelpen van geuren in mobiele ontwikkeling. Probeer niet God Activity in zijn geheel te herschrijven. Scheid eerst de navigatielaag, dan de gegevenslaag, vervolgens de weergavelogica. Begeleid elke stap met een commit en het draaien van tests. Gebruik feature toggle om refactoring in te schakelen voor een deel van de gebruikers en terug te draaien bij problemen.

• Extract Method — splits de lange methode op in meerdere korte met begrijpelijke namen
• Extract Class — scheid een gerelateerde groep velden en methoden af in een aparte klasse
• Replace Conditional with Polymorphism — vervang switch door een klassehierarchie
• Introduce Parameter Object — combineer een groep parameters in een object
• Replace Inheritance with Delegation — vervang extends door compositie

IDE-tools automatiseren veel refactoringtechnieken. Android Studio en IntelliJ IDEA bieden ingebouwde refactorings: Extract Method, Extract Interface, Pull Members Up, Encapsulate Fields. Xcode (vanaf versie 14) heeft de ondersteuning voor refactoring in Swift verbeterd. Het gebruik van automatische refactorings vermindert het risico op fouten in vergelijking met handmatig kopiëren van code.

Code Smell in mobiele ontwikkeling

Mobiele ontwikkeling voegt eigen specifieke geuren toe gerelateerd aan platformbeperkingen. In Android zijn dit Context-lekken, niet-gesloten Cursor, onjuist gebruik van Lifecycle. In iOS — retain cycle via closures, onjuist werken met Auto Layout, gigantische ViewControllers. Deze geuren verslechteren niet alleen de onderhoudbaarheid, maar beïnvloeden ook direct de prestaties en stabiliteit van de applicatie.

Callback Hell — een kenmerkende geur voor code die met asynchrone operaties werkt. Geneste callbacks (callback inside callback) maken de code onleesbaar en moeilijk te debuggen. Oplossing: coroutines (Kotlin), async/await (Swift 5.5+), RxJava/RxSwift of Combine. Volgens Google I/O 2023 verminderen projecten die zijn overgestapt van callback-stijl naar coroutines het aantal bugs met 30% en versnellen ze het toevoegen van nieuwe functies.

Platform Coupling — vaste koppeling van bedrijfslogica aan platformcomponenten. Het testen van dergelijke logica vereist het starten van een emulator, wat de feedbacklus vertraagt. Correctie: Clean Architecture verdeelt de code in lagen Domain (schone Kotlin/Swift zonder platformafhankelijkheden) en Data/UI (met platformafhankelijkheden). Bedrijfslogica wordt getest op de JVM zonder emulator.