< terug naar nieuws
dinsdag 12 maart 2019

Clean coding/clean architecture, wat houdt dat nou eigenlijk in?

Dat was de vraag waar Uncle Bob (Robert C. Martin) twee dagen lang over heeft uitgeweid tijdens de gratis toegankelijke meetup gesponsord door de Rabobank waar ik (Wiebe Zweers) naar toe mocht. 

Dus, waarom 'clean code'?

Ervaring leert dat de ontwikkeling van de meeste softwareprojecten in het begin heel snel gaan, maar dat dit steeds langzamer gaat naar mate er langer aan gewerkt wordt.

Vaak zijn de eerste commerciële successen dan al gewonnen met het product en wordt er vanuit sales of het management aangestuurd op meer features. Die nieuwe features zijn vaak erg urgent want ze zijn al beloofd aan die ene nieuwe grote klant.

Na een tijdje wordt er gesignaleerd dat de vaart uit het ontwikkelproces is en er wordt gezocht naar een oplossing. Meer mensen is vaak het antwoord, immers als een ontwikkelaar een feature per week oplevert dan zullen twee ontwikkelaars er toch zeker twee opleveren in dezelfde tijd.

Toch blijkt dit niet zo te werken, vanwege de tijdsdruk en de positieve reacties op het snelle opleveren van de eerste paar versies zijn er wat bochten afgesneden. Er is van tevoren niet echt nagedacht over een degelijke architectuur, bepaalde stukken code blijken niet te werken of intens verweven te zijn met andere stukken van de code. (De vakterm hiervoor is spaghetticode.) Het schrijven van tests is consequent overgeslagen, enige vorm van documentatie ontbreekt.

Het is daardoor al snel onduidelijk wat er gebeurt als er iets in die stukken code wordt veranderd. Ontwikkelaars raken het overzicht kwijt en kunnen niet langer inschatten wat een wijziging teweeg zal brengen, kleine wijzigingen bestaan niet meer. Ontwikkelaars zijn inmiddels bang om "legacy" aan te raken en gaan eromheen werken waardoor de chaos alleen maar groter wordt. Wat eerst een dag duurde om te maken duurt nu weken.

Nu het patroon wat zich bij softwareontwikkeling voordoet duidelijk is kan er worden ingezoomd op oorzaken en oplossingen. Dit is precies wat Uncle Bob gedaan heeft over twee dagen, met onderwerpen variërend van de namen van variabelen tot test driven development (TDD), domain driven design en Agile. De belangrijkste take-away: "The only way to go fast, is to go well".

Well, wat is dat dan?

"Well" betekent in de wereld van programmeurs; leesbaar, overdraagbaar, simpel en elegant. Daarnaast betekent het weloverwogen, bewezen werkend (getest) en onderhoudsvriendelijk.

Dit wil natuurlijk elke ontwikkelaar wanneer er aan een nieuwe applicatie wordt begonnen. Het blijkt echter dat het makkelijk is om werkende code te schrijven die een computer snapt, maar dat het veel lastiger is om code te schrijven die een toekomstige ontwikkelaar in een oogopslag snapt.

Een van de manieren om te voorkomen dat software complex wordt is door na te denken over de architectuur van een applicatie, het moet overduidelijk zijn wat een applicatie moet doen. Wat er dan vaak gebeurt is dat er een framework en een stack worden gekozen en dat de software vooral praat over verbindingen met een database of framework specifieke dingen.

Een goede architectuur betekent niet een tot in de puntjes uitgedacht systeem, maar schreeuwt intentie. Het moet niet zo zijn dat een boekhoudsysteem in eerste instantie lijkt op een drupal of wordpress installatie, het moet schreeuwen dat het een boekhoudsysteem is net als dat de bouwplannen voor een theater direct herkenbaar zijn als zodanig.

Het belangrijkste doel van software architectuur is om de levenscyclus van het systeem zo optimaal mogelijk te ondersteunen. Een goede architectuur maakt een systeem begrijpelijk, onderhoudsvriendelijk en makkelijk uit te rollen. Uiteindelijk is het doel om de kosten over de levensduur van het project te minimaliseren en de productiviteit te maximaliseren.

Leuk, maar hoe doen we dat?

Onder andere door terminologie en structuren in de software zoveel mogelijk aan te laten sluiten bij de terminologie en onderverdeling van afdelingen van het bedrijf in kwestie creëer je software waarin de intentie duidelijk naar voren komt. Het is direct duidelijk voor eenieder die het bedrijf kent wat er bedoeld wordt met een factuur of een inkooporder en daarnaast valt het direct op als de koffiedame ineens de salesmanager vertelt wat hij/zij moet doen. Deze manier van werken heet Domain Driven Design (DDD), meer hierover vind je in het gelijknamige boek van Eric Evans.

Een andere belangrijke manier is om testgedreven te programmeren, je schrijft pas een stuk code als er een test is geschreven die faalt vanwege het ontbreken ervan. Deze manier van werken wordt gezien als tijdrovend maar zeer effectief om een constante snelheid te waarborgen omdat de kwaliteit van code automatisch veel hoger ligt als deze altijd volledig is afgedekt door testen.

Naast bovenstaande werkwijzen is het belangrijk om een systeem te ontwikkelen wat je in staat stelt om keuzes zo lang mogelijk uit te stellen. Als vanaf het begin wordt gesproken over concepten in plaats van implementaties blijkt vaak dat dingen als een database zover weg worden geabstraheerd dat de relationele database net zo goed een tekstbestand had kunnen zijn.

Hiervoor kun je beginnen met een (als een ui) gelaagde architectuur waarin je stelt dat de buitengelegen lagen alleen maar naar binnen toe afhankelijkheden mogen hebben en nooit andersom. Dit stelt je in staat om de buitengelegen lagen te vervangen zonder de binnen gelegen lagen aan te raken. Lees voor een goed voorbeeld hiervan eens meer over hexagonale architectuur.

Tot slot

Het belangrijkste doel van dit alles is om de levenscyclus van een systeem zo optimaal mogelijk te ondersteunen, de kosten over de levensduur van het project te minimaliseren en de productiviteit van ontwikkelaars te maximaliseren. Een goede architectuur maakt een systeem begrijpelijk, onderhoudsvriendelijk en makkelijk uit te rollen. Het aanhouden van best practices omtrent het clean houden van code zorgt dat dit ook zo blijft.

< terug naar nieuws