Troep-code en rotzooi in mobiele projecten — kenmerken en refactoring

Wat is troep-code in ontwikkeling

Troep-code (ook spaghetti code, rotzooi, big ball of mud) — is een metafoor voor een codebase die zijn structuur heeft verloren en in een wirwar van afhankelijkheden is veranderd. In zulke code breekt elke verandering op de ene plek iets anders, en het toevoegen van nieuwe functionaliteit wordt een riskante onderneming.

In mobiele ontwikkeling is troep-code bijzonder kritisch: een app gebouwd op "rotzooi" begint trager te worden, crasht op oudere apparaten en komt moeilijk door code review. Een iOS-project zonder architectuur kan App Review niet doorstaan vanwege instabiliteit.

Volgens Stripe besteden ontwikkelaars tot 42% van hun werktijd aan het lezen en begrijpen van bestaande code. In projecten met troep-code overschrijdt dit cijfer de 60%, wat de ontwikkeling uiterst inefficiënt maakt.

Oorsprong van de termen

Spaghetti code — de oudste term, ontstaan in de jaren 1970. Het beschrijft code met chaotische controle-overgangen, die aan elkaar hangende spaghetti doet denken.

Big ball of mud (grote modderbal) — een term geïntroduceerd door Brian Foot en Joseph Yoder in 1997 om systemen zonder duidelijke architectuur te beschrijven die chaotisch "groeien".

Waarom troep-code gevaarlijk is voor het bedrijf

Troep-code vertraagt het uitbrengen van nieuwe functies op de markt. Het team besteedt tijd niet aan het creëren van waarde, maar aan pogingen om te begrijpen hoe de bestaande code werkt en niets te breken.

Volgens McKinsey geven bedrijven met lage codekwaliteit 20-40% meer uit aan productonderhoud, en de snelheid van het uitbrengen van nieuwe functies is 2-3 keer lager in vergelijking met bedrijven met hoge codekwaliteit.

Kenmerken van troep-code en hoe het te herkennen

Herkennen van troep-code kan aan de hand van een reeks objectieve kenmerken, waarvan sommige automatisch worden gemeten. Hoe meer kenmerken overeenkomen — hoe ernstiger het probleem.

In de industrie worden codekwaliteitsmetriken zoals Halstead Complexity, Maintainability Index en Technical Debt Ratio gebruikt. Kennis van deze metriken helpt bij het objectief beoordelen van de staat van de codebase.

Copy-paste (code duplicatie)

Het meest voorkomende kenmerk van troep-code — herhalende codeblokken. In plaats van een gemeenschappelijke functie te extraheren, kopiëren ontwikkelaars code van de ene naar de andere plek met minimale wijzigingen.

Een normaal niveau van duplicatie wordt beschouwd als tot 5%. Als duplicatie boven de 15% uitkomt — is dat een serieus signaal. Tools zoals Simian en PMD Copy Paste Detector helpen bij het automatisch detecteren van copy-paste.

Lange methoden en klassen

Een methode langer dan 100 regels — een duidelijk kenmerk van troep-code. Zo'n methode doet meestal te veel en schendt het principe van enkele verantwoordelijkheid (Single Responsibility).

Klassen met meer dan 1000 regels code zijn ook problematisch. Ze bevatten niet-gerelateerde functionaliteit, wat testen, begrijpen en wijzigen van code bemoeilijkt.

Hoge cyclomatische complexiteit

Cyclomatische complexiteit volgens McCabe (Cyclomatic Complexity) — een metriek die het aantal onafhankelijke paden in code aangeeft. Een waarde boven 15 wordt als problematisch beschouwd.

Methoden met complexiteit boven 30 — "rampgebied". Ze bevatten te veel vertakkingen, kunnen niet worden getest of begrepen zonder diepgaande analyse.

Oorzaken van troep-code

Troep-code ontstaat niet "vanzelf" — het is altijd het resultaat van specifieke processen en beslissingen in het team. Inzicht in de oorzaken helpt voorkomen dat het in de toekomst ontstaat.

Volgens JetBrains Developer Ecosystem 2024 geeft 67% van de ontwikkelaars toe dat ze slechtere code schrijven dan ze zouden kunnen vanwege tijdgebrek. Dit is de belangrijkste oorzaak van het opbouwen van technische schuld.

Haast en deadlines

De meest voorkomende oorzaak — krap gestelde deadlines. Het team schrijft code "zoals het uitkomt", alleen om de deadline te halen. Refactoring, tests en code review worden "voor later" uitgesteld.

Het probleem is dat "later" nooit komt — in de volgende sprint verschijnen nieuwe deadlines en stapelt de technische schuld zich op als een sneeuwbal.

Gebrek aan code review

Zonder code review schrijft elke ontwikkelaar in zijn eigen stijl, gebruikt zijn eigen patronen en laat zijn eigen "valkuilen" achter. Na verloop van tijd verliest de codebase zijn uniformiteit.

Teams die verplichte code review toepassen voor elke pull request hebben volgens SmartBear 2024 60% minder defecten in productie.

Zwakke architectuur vanaf het begin

Als een project zonder duidelijke architectuur begint, is troep-code onvermijdelijk. De eerste "snelle oplossingen" leggen een fundament waarop later moeilijk iets kwalitatiefs te bouwen is.

In mobiele ontwikkeling moet de keuze van architectuur (MVC, MVP, MVVM, Clean Architecture) een bewuste beslissing zijn die wordt genomen voordat met schrijven wordt begonnen, niet het resultaat van evolutie.

Methoden om troep-code te bestrijden

Bestrijding van troep-code vereist een systematische aanpak en discipline van het hele team. Er is niet één tool of praktijk die het probleem oplost — er is een combinatie van maatregelen nodig.

Het belangrijkste principe — troep-code niet toestaan in de schrijffase, in plaats van het later te repareren. Preventie is altijd goedkoper dan refactoring van bestaande "rotzooi".

Coderingsstandaarden

Uniforme codestijl — de basis voor het voorkomen van troep-code. Coderingsstandaarden (Code Style) moeten worden gedocumenteerd en automatisch worden gecontroleerd door linters.

Voor iOS wordt SwiftLint gebruikt, voor Android — Ktlint en Detekt. Het configureren van regels in een configuratiebestand maakt het mogelijk om pull requests die standaarden schenden automatisch af te wijzen.

Regelmatige refactoring

Refactoring — is niet het repareren van bugs, maar het verbeteren van de codestructuur zonder het gedrag te veranderen. Het moet een regelmatig onderdeel van het ontwikkelproces zijn, geen apart project.

Het wordt aanbevolen om 20% van de tijd van elke sprint te besteden aan refactoring en het aflossen van technische schuld. Dit voorkomt ophoping van "rotzooi" en behoudt de snelheid van het team op de lange termijn.

Verplichte code review

Elke pull request moet worden gereviewd door ten minste één ontwikkelaar. Code review detecteert niet alleen bugs, maar ook schendingen van architectuur, stijl en potentiële bronnen van troep-code.

Een goede praktijk — een checklist voor code review die controle op copy-paste, methodelengte, cyclomatische complexiteit en testdekking omvat. Zonder checklist missen reviewers tot 50% van de problemen.

Tools voor het opschonen van de codebase

Moderne codeanalysetools maken het mogelijk om troep-code automatisch te detecteren, technische schuld te meten en kwaliteit te bewaken. Integratie van deze tools in de CI/CD-pijplijn zorgt voor continue monitoring.

Het wordt aanbevolen om ten minste één statische analyser en één tool voor het meten van metrieken te gebruiken. Aanvullend kan een platform voor het aggregeren van codekwaliteitsgegevens worden aangesloten.

Statische analysers

• SonarQube — toonaangevend platform voor codekwaliteitsanalyse, ondersteunt 30+ talen en geeft metrieken zoals Technical Debt Ratio
• ESLint — de standaard voor JavaScript en TypeScript, configureerbaar via configuratiebestanden en geïntegreerd in IDE
• SwiftLint — verplichte tool voor iOS-projecten, controleert naleving van de Swift Style Guide

Volgens SonarSource verminderen teams die statische analyse gebruiken het aantal bugs in productie met 30% al in het eerste kwartaal na implementatie.

Tools voor meten van metrieken

CodeClimate en Codacy — platforms die codekwaliteitsmetrieken aggregeren, dynamiek volgen en "hotspots" tonen — bestanden met de hoogste technische schuld.

Voor Android-projecten biedt Detekt meer dan 100 ingebouwde analyseregels, waaronder controles op cyclomatische complexiteit, methodelengte en codeduplicatie.