Tag test-driven development
Test-Driven Development en YAGNI
Vaak werkt het zo: tests maken x mogelijk, Test-Driven Development (TDD) tilt x naar een volgend niveau. Welnu, het idee van YAGNI – You Ain’t Gonna Need It – veronderstelt tests. TDD tilt het naar een volgend niveau. Tests faciliteren YAGNI, TDD radicaliseert het.
TDD voorbij de intro
Vandaag laat ik liever even iemand anders aan het woord. – Hoewel, “even”? Romeu Moura neemt in de onderstaande twee video’s uit-ge-breid de tijd om zijn toehoorders kennis te laten maken met zijn test-gedreven ontwikkelproces. In niets ontziend detail neemt hij elke beslissing onder de loep en analyseert hij, reflecteert – op het proces net zozeer als op zichzelf.
Testen: een retrospectief in vijf fasen
Het leek me zinvol om te reflecteren op de ontwikkeling die mijn team en ik door hebben gemaakt op het gebied van testen. Want – en dat is goed nieuws – de manier waarop we het testen van onze software aanvliegen is radicaal veranderd sinds ik begon als ontwikkelaar.
Drie feedbackloops die verbeteren met unit tests
Ik ben geneigd te zeggen: alles in het leven wordt beter met unit tests – en dat toont hoe ver ik inmiddels van het padje ben geraakt. – Maar op het gebied van softwareontwikkeling gaat die vlieger wel degelijk op. Toen ik voor het Najaarsevenement van TestNet begon uit te werken waarom testers code zouden moeten reviewen, stuitte ik op drie feedbackloops die geautomatiseerde tests kunnen versnellen.
Erfenissen van waterval
Op het Najaarsevenement van TestNet betoogde ik dat testers een belangrijke rol hebben te spelen in het reviewen van code. Tijdens de voorbereiding van mijn presentatie realiseerde ik me dat mijn team, alle Agile ambities ten spijt, in zijn denken nog diep verankerd zit in het gedachtegoed van de watervalopvatting van softwareontwikkeling.
Waarom, wat en hoe
Waarom bestaat deze code? – wat doet het? – en hoe doet het dat? Ik maaide het gras van mijn achtertuin, toen me inviel dat het beantwoorden van die vragen niet beperkt blijft tot het lezen van code. Elke ontwikkelaar stelt zichzelf precies dezelfde vragen als deze code gaat schrijven. En een goede ontwikkelaar beantwoordt ze in die volgorde.
Coderen met luchthaken en hijskranen
In mijn vakantie las ik Darwin’s Dangerous Idea van Daniel Dennett, het boek is een aanrader. Omdat ik een beroepsdeformatie heb, deed het me aan softwareontwikkeling denken.
Refactoren als context switch
Context switching heeft een slechte naam in softwareontwikkelland en dat is niet helemaal onterecht. Het is enorm vervelend als je nét lekker aan het programmeren bent – om vervolgens weggeroepen te worden voor een snelle vraag of ellenlange vergadering (die ook een e-mail had kunnen zijn). Op dat moment raak je alle informatie kwijt die je in je hoofd hebt opgebouwd om een probleem te kunnen tackelen, en mag je opnieuw beginnen. Maar dat is maar de helft van het verhaal.
Waar doe je het voor?
Een luie programmeur grijpt alles aan om zijn eigen werk makkelijker te maken (met uitzondering van het besparen op kwaliteit - daar is een andere term voor: een slechte programmeur). En makkelijker maken betekent meestal: automatiseren. Want waarom zou je zelf het werk doen, als een machine het ook voor je kan doen?
Tijdreis
Ik vroeg mijn collega’s: “Wat doet dit ding precies?” - waarop ze prompt de code tevoorschijn haalden en me stap voor stap door het importproces loodsten. Het was alsof ik terug werd geslingerd naar het begin van mijn ontwikkelcarrière, toen we met z’n allen een twaalf jaar oude legacy applicatie onderhielden die alleen te doorgronden was door nauwgezet de code te doorlopen. Wat blijkt: tijdreizen bestaat - je hoeft alleen maar bij een ander team te buurten.