Tests als ontwerpmiddel
Tests zijn een ontwerpmiddel, een design tool. Ze fungeren als indicator voor de kwaliteit van het ontwerp van je code. De vuistregel is even eenvoudig als zag-het-niet-want-het-stond-recht-voor-mijn-neus-vanzelfsprekend: Is het moeilijk om er een test voor te schrijven? Dan deugt het ontwerp niet!
Tests als vangnet
Tests zijn een vangnet. Elke keer dat je code aanraakt - en dat doe je continu -, dan speel je een balanceeract. Als je code blijft functioneren zoals bedoeld, blijf je op het koord. Zo niet, dan val je. En als je valt, heb je een keus: te pletter vallen, of opgevangen worden door een vangnet. Tests zijn je vangnet, je afgrond is - ontevreden ontwikkelaars, stakeholders, eindgebruikers.
Tests als documentatie
Tests zijn een vorm van documentatie. Ze leggen vast hoe een deel van je codebase zich hoort te gedragen. Maar ook: hoe je dat deel van de codebase gebruikt - wat je nodig hebt om het system under test te instantiëren, het gedrag van z’n methods etc.. Wie de tests leest, weet hoe de code gebruikt dient te worden. - Althans, dat is de ideale wereld.
Over afwas en software
Afwassen is net als software ontwikkelen. Althans, ik probeer mijn afwas net zo aan te pakken zoals ik mijn software het liefst ontwikkel. Het fundamentele idee wordt kernachtig verwoord door Kent Beck in de volgende quote: “For each desired change, make the change easy (warning: this may be hard), then make the easy change.”
Samen je ontwikkel-ik ontdekken
Praten over je eigen leer- en ontwikkelingsproces is een moeilijke opgave. Maar weinig mensen hebben de taal om hun ideeën daarover uit te kunnen drukken - als ze er überhaupt al een idee over hebben. En de kans dat ze die ideeën, en de bijbehorende taal, in hun eentje zullen ontwikkelen, is nagenoeg nul. Je hebt anderen - andere mensen, perspectieven, leerdoelen en -stijlen - nodig om gestalte te kunnen geven aan je eigen ontwikkeling. Maar hoe ga je het gesprek aan als je er de taal voor ontbeert? Daar hebben Manon Ruijters, Gerritjan van Luin en Robert-Jan Simons Ons ontwikkelen ontward voor, eh, ontwikkeld
Test-Driven Code Reviews
Door een alfabetisch toeval presenteert Azure DevOps elk pull request van mijn team in deze volgorde: eerst de front-end, dan de back-end - de API, de businesslogica, de datatoegang en het model - en ten slotte te tests. Onlangs stelde ik de vraag hoe je eigenlijk code reviewt - en waar je het best kunt beginnen bij zo’n beoordeling. Ik heb er een tijdje op zitten broeden, en ik denk dat ik eruit ben.
Succesvol falen
Van fouten kun je leren, zegt men. Daaruit volgt: hoe meer fouten je maakt, hoe meer leerkansen je creëert. Eigenlijk zou je het maken van fouten dus moeten vieren. Hoe meer er mis gaat, hoe meer je leert – en hoe meer je leert, hoe minder er mis zal gaan. Toch is dat niet hoe het in veel organisaties werkt. Daar wordt er hard gewerkt om fouten te voorkomen. Erger nog, medewerkers die de mist in gaan, worden afgerekend op hun misstappen. Dat maakt hen voorzichtig, conservatief. En daardoor staan ze hun eigen groei – en die van de organisatie – in de weg.
Collegiale documentatie
Ik ken geen enkele ontwikkelaar die het leuk vindt om documentatie te schrijven - ik ook niet - en dat is omdat goede documentatie schrijven moeilijk is. Het is moeilijk, omdat je je vanuit een positie van iemand die snapt hoe iets werkt, je in moet leven in iemand die dat begrip nog niet heeft. Mijn belofte “even” documentatie te schrijven werd daarom al gauw “een uur” documentatie schrijven. Maar het resultaat is volgens mij wel de moeite waard, dus laten we er even (…een uur?) naar kijken.
Test-driven development is een ontwerpdiscipline
Een collega benaderde me laatst met een vraag over een stuk code. Hij was bezig met het implementeren van een feature om een toets met afbeeldingen om te zetten naar een PDF-representatie ervan. Zijn vraag was: hoe kom ik aan die afbeelding? Of liever: waar kom ik aan die afbeelding? Zijn eerste ingeving was om via dependency injection de relevante repository mee te geven aan de ImagePdfGenerator. - Het is een klassiek geval van het verknopen van het ophalen van data en het manipuleren ervan. Ik bleef wel met een knagend gevoel achter: hoe makkelijk blijkt het om dankzij een DI-container de verantwoordelijkheden van classes te verwateren - en wat moeten we daarmee?
Twee stijlen van refactoren
Het was een tijd terug 40 graden en dat leek me, om redenen die ik achteraf niet kan bevatten, geen reden om het geairconditioneerde pand van mijn werkgever te bezoeken. In plaats daarvan bleef ik met de gordijnen dicht op mijn snikhete kantoortje zitten en begon aan een grootscheepse refactorslag. Of liever: twee refactorslagen - de ene met een gestaag toenemende hoeveelheid koortsig zweet op mijn voorhoofd, en de ander met een stabiele hoeveelheid normalehittezweet. De ene refactorslag was een ramp, de ander een succes. In beide gevallen moest ik het kantoor nadien goed luchten - dat wel.