Ontwikkelingscycli: wat drijft het development?

Home / Blog / Expert column / Ontwikkelingscycli: wat drijft het development?

Waar moet ik beginnen? Het is een vraag die iedereen zichzelf wel eens stelt wanneer hij aan iets groots begint. En het is dus ook een vraag die veel software ontwikkelaars zichzelf stellen als ze beginnen aan een nieuwe opdracht.

Maar wat is het juiste antwoord? Een goed idee is om eens te kijken naar verschillende ontwikkelmethoden, die uitgaan van het startpunt van de ontwikkelcyclus. Over het algemeen hebben deze ontwikkelmethoden een naam in hetzelfde patroon: ****-driven development, met op de plaats van de sterren, het uitgangspunt bij het ontwerpen en ontwikkelen van de software. In deze column bespreek ik de meest populaire ****-driven-development methoden en hun sterke en zwakke kanten.

Test-Driven Development

Test-Driven Development (ook wel TDD genoemd) is misschien wel de meest bekende ontwikkelmethode die bestaat. Deze methode wordt vaak aangehaald als kwaliteit in het geding is. Het idee achter Test-Driven Development is heel makkelijk. Bij een applicatie geschreven met Test-Driven Development draait alles om testen. De methode beschrijft namelijk het schrijven van tests als allereerste stap van programmeren. Dit houdt in dat je eerst een stuk code test, en daarna pas de code schrijft die getest wordt. Als alle tests succesvol draaien, is het programmeren van een onderdeel klaar.

Dit klinkt als een heel onnatuurlijke volgorde, eerst een test maken, en daarna de code schrijven, maar deze volgorde biedt wel enkele duidelijke voordelen. Ten eerste weet je zeker dat alle onderdelen van de code goed getest zijn, want er wordt eerst getest, en daarna geprogrammeerd, waardoor testen nooit vergeten kan worden. Daarnaast heeft de code, uitgaande van object georiënteerd programmeren, een hele duidelijke API. Dit komt omdat eerst de API verzonnen is (op een manier die logisch is vanuit het gebruiken), en daarna pas de implementatie. Als laatste geeft het je als programmeur ook een heel duidelijke richting in je ontwikkelproces. Het doel is om te zorgen dat alle tests draaien. Het aantal tests die draaien, tegenover het totaal aantal tests, is je voortgang.

Hoewel men het er over het algemeen over eens is dat TDD heel goede code oplevert, wordt het niet heel vaak toegepast. Dit komt vooral omdat het heel veel oefening en skills vraagt om voor het daadwerkelijke programmeren alle tests te kunnen schrijven.

Model-Driven Development

Model-Driven Development (MDD) is niet zo zeer bekend als beschreven development cyclus, maar wordt wel veel toegepast. Ontwikkelaars die zeggen dat ze geen methodiek gebruiken, gebruiken eigenlijk vaak Model-Driven Development zonder dat ze zich daar bewust van zijn. Bij het Model-Driven Development ligt de initiële focus in het ontwikkelproces op de informatie die in het systeem verwerkt en opgeslagen moet worden. Deze informatie wordt op een manier gemodelleerd zodat deze makkelijk te begrijpen en goed te hergebruiken is. Het doel van Model-Driven Design is dan ook om eerst een goed beeld te krijgen van het domein waarin de applicatie moet draaien en daarna pas van de exacte functionaliteiten die daarop uitgevoerd moeten worden.

Behaviour-Driven Development

Behaviour-Driven Development (BDD) is een ontwikkelmethode ontstaan uit Test-Driven Development, maar het kijkt op een andere manier naar de manier waarop getest moet worden. Waar bij Test-Driven Development de technische tests van de implementatie (unittests) centraal staan, probeert Behavior-Driven Development op een systematische wijze het gedrag van de applicatie te beschrijven. Het gaat dan om een manier die geschikt is voor automatisch testen, maar ook goed voor een mens te lezen is.

Domain-Driven Development

Domain-Driven Development (DDD) is een heel interessante ontwikkelmethode, die niet de ontwikkelaar als het uitgangspunt neemt, maar juist het business domein. De eerste stap in Domain-Driven Development is daarom ook het werken met de specialist uit het domain aan een verzameling van begrippen en beschrijvingen die bij beide partijen bekend zijn. Zo kan de code geschreven worden op een manier die zowel de programmeurs als de mensen uit het domein/de business goed begrijpen. Hoewel niet geheel voor de hand liggend, maar het is dat heel belangrijk. Als de business een ontwerp zou maken, en de ontwikkelaars dat ontwerp omzetten naar software, zonder te begrijpen wat ze maken, is er een grote kans dat de programmeurs wél bouwen wat er beschreven is, maar niet het inzicht hebben om te bouwen wat er echt bedoeld was. Dat is natuurlijk zonde van de tijd en inspanning. Maar ook als de programmeurs iets maken waarvan zij denken dat het goed is voor het domein/business, maar de business begrijpt niet wat er gemaakt is, dan kan het zijn dat het niet aansluit bij het domein, of dat de uiteindelijke beoogde gebruikers niet weten hoe ze de software moeten toepassen. Domain-Driven Development richt zich er op om juist deze aansluiting goed te maken.

De verkeerde aansluiting tussen het domein en de ontwikkelaars die Domain-Driven Development probeert te voorkomen, duidelijk in beeld.

Het is een goed idee om, voordat je begint met een nieuw project, te kijken of één van deze ontwikkelmethoden aansluit bij jouw wensen en natuurlijk de wensen van de opdrachtgever. Het gebruik van zo’n methode maakt het makkelijker om duidelijke afspraken te maken en geeft je houvast tijdens het ontwerpen én programmeren. Is een ****-driven development methode iets te ambitieus? Dan kun je altijd kijken naar de positieve eigenschappen die de ontwikkelmethoden heeft en kijken of deze ook in jouw ontwikkelproces te integreren zijn.