Waarom 'Clean Code' van cruciaal belang is bij Scrum

Joost

Geschreven door Joost Saanen op 24-11-2016
5 minuten leestijd

Een van de grootste voordelen van Agile Scrum is dat er na elke sprint een werkend stukje software wordt opgeleverd. Wat ‘Clean Code’ hier mee te doen heeft en dat dit ontzettend belangrijk is ga ik je zo uitleggen.

Even in het kort hoe Scrum in zijn werk gaat: user stories worden verzameld in subprojecten die we sprints noemen. Vóór zo’n sprint wordt bepaald wat de user stories zijn met de hoogste prioriteit en dus welke de meeste value hebben. De user stories worden tijdens de sprint opgepakt en geïmplementeerd. En, als alles goed gaat hebben we uiteindelijk een tevreden product owner.

Zoals je wel kan verwachten gaat dit alles niet altijd goed. Om tot een tevreden klant te komen vergt wat oefening. We schreven eerder al eens een blogpost over 5 veelgemaakte fouten binnen een Agile project.

Ok, even een stapje terug.

Omdat het uiteindelijke softwareproduct wordt gebouwd en opgeleverd in iteraties, subprojecten of sprints is het des te belangrijker dat de gebouwde functionaliteiten naadloos op elkaar aansluiten. Om dit voor elkaar te krijgen is het belangrijk dat een developer heldere en mooie broncode schrijft. Dit wordt ook wel clean code genoemd.

Maar hoe doe je dit?

Test Driven Development en Clean Code

Zoals gezegd groeit bij Scrum je software bij iedere sprint. Om de verschillende onderdelen goed samen te laten werken, is het belangrijk om deze zo simpel mogelijk te houden. Zo worden complexe onderdelen opgedeeld in kleinere user stories. Op deze manier houdt één user story de focus op één functionaliteit of taak.

Bij het clean code principle is dit net zo: Wanneer een stukje code is verweven in verschillende functionaliteiten, dan is het veel lastiger om op een later moment wijzigingen aan te brengen. De kans dat functionaliteit (die misschien in eerste instantie geen verband lijkt te hebben met de functionaliteit waar de code voor is aangepast) breekt, is namelijk groot.

Wanneer je een stukje code zo bouwt dat het maar één taak uitvoert wordt er ook wel gesproken over het single responsibility principle. En de meest effectieve manier om je aan deze manier van ontwikkelen te houden is door te programmeren middels de Test-Driven Development (TDD) methodiek.

Met TDD, schrijft een developer eerst een testscenario voordat deze begint met het schrijven van de broncode. Het testscenario is gericht op één specifieke taak en dat is waar de developer zich mee bezighoudt. Niets anders. De developer start pas met de implementatie van een nieuwe taak wanneer de vorige is afgerond. Ook hiermee helpt Scrum. De test geeft als resultaat rood (fout) of groen (goed). Het is een afgebakend stuk functionaliteit. Bijvoorbeeld: de broncode die nodig is voor het omrekenen van een rekeningnummer naar een IBAN nummer.

Het resultaat van TDD is niet alleen broncode die meer vertrouwen geeft wanneer er later iets moet worden aangepast. Het isoleren van deze taak zorgt er ook nog eens voor dat er beter samengewerkt kan worden tussen de andere taken. Je kunt het zien als legoblokken waarmee een huisje wordt gebouwd. Elke blok representeert een taak. Een blok is makkelijk inwisselbaar zonder dat dit invloed heeft op andere blokken. Dit biedt veel meer flexibiliteit dan een huis dat uit één grote blok bestaat — ga aan dat laatste huis maar eens een aanpassing doorvoeren.

De TDD-methodiek kan misschien de indruk geven dat deze manier van ontwikkelen meer tijd kost dan normaal. Door sommigen (vaak personen die het begrip TDD niet zo goed begrijpen) wordt er wel eens gezegd dat het geldverspilling is. Niets is minder waar. TDD levert je naast betere kwaliteit uiteindelijk ook besparing in geld op. We schreven er al eens een blogpost over. Bij Kabisa spreken we uit ervaringen en hebben we al talloze projecten juist door deze TDD-aanpak met succes afgerond.

Scrum en TDD

Ja, je kan een developer precies vertellen wat je wilt en soms lijkt het dat een developer je volledig heeft begrepen. Toch kan het zijn dat de gebouwde feature niet precies doet wat je had gehoopt. Dit kan meerdere oorzaken hebben. Misschien was de communicatie toch niet goed of was de functionaliteit té complex? Het voordeel van scrum is dat het proces je dwingt om grote complexe stukken op te delen in kleinere – betere beheersbare – onderdelen. Als klant of product owner krijg je zo de kans tijdig bij te sturen, wanneer je merkt dat het toch niet helemaal de goede richting op gaat. Op het einde van de sprint kun je deze feedback teruggeven aan de developer en op deze manier ben je (vaak) nog op tijd.

Wanneer er gewerkt wordt middels dit single-responsible principle, hoeft er niet zoveel broncode te worden weggegooid. Deze individuele onderdelen kunnen vaak nog gewoon worden (her)gebruikt bij het bouwen van de nieuwe functionaliteit. Bijvoorbeeld: het IBAN-nummer is nog wel nodig maar het veld waar het moet worden ingevoerd moet op een andere plek komen in het formulier.

Er is een mooie analogie tussen verschillende iteraties (sprints) in scrum-projecten en Test-Driven Development. Naast het opdelen van complexe taken, zijn ze allebei gericht op kleine specifieke taken die vrijwel direct worden geverifieerd of getest. Bij programmeren is het TDD, bij scrum is het de product owner aan het einde van de sprint die zorgt voor directe feedback. TDD en Scrum is een ideale combinatie.

En nog iets. Laten we stoppen met het volgende:

Het op voorhand opstellen van lange lijsten met requirements, ingewikkelde modellen en technische designs. Je wilt niet dat developers zich voor maanden opsluiten en met een product naar buiten komen wat het nét niet helemaal is. Of helemaal niet.

In veel gevallen werkt deze methodiek niet!

Statistieken wijzen uit dat nog minder dan ⅓ van dergelijke software-trajecten slaagt. Niet voor niets dat methodieken als Scrum — die vragen om meer focus, iteraties, samenwerking tussen business en techniek — zo ontzettend populair zijn.

Waarom? Omdat dat wel werkt :-)

Kabisa kan helpen met het toepassen van Scrum binnen projecten. Daarnaast werken wij altijd volgens de TDD-methodiek. Onze developers weten niet beter. Neem gerust contact met ons op wanneer je vragen hebt of hulp nodig hebt.

Joost

Joost Saanen

Gepassioneerde all-rounder met brede interesses; van serverbeheer en cloudhosting tot (UI)design en (web)development. Hardloopt en schrijft het liefst tegelijk.