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.
Hoe hersenwetenschap programmeurs kan helpen
Er is in de vakliteratuur over softwareontwikkeling geen gebrek aan gepeperde meningen over hoe goede code eruit dient te zien. Goede code is naar hun mening eenvoudig, bijvoorbeeld, of testbaar of uitbreidbaar. Je zou kunnen zeggen dat hun redenen erop geënt zijn software zo goed mogelijk te kunnen onderhouden. Wie dat zou moeten doen en hoe ze dat aan moeten pakken, daar zijn de meningen minder gepeperd over. Veel professionals lijken code te beschouwen als iets wat op zichzelf staat, zonder veel oog te hebben voor de programmeurs die dat onderhoud zouden moeten plegen. Dat geldt niet voor Felienne Hermans. In The Programmer’s Brain behandelt ze vragen als: wat gebeurt er in het brein als je code leest? Hoe leer je zo efficiënt mogelijk nieuwe programmeertalen en -concepten? En hoe kun je deze kennis inzetten om betere code te schrijven?
Historie van Koenraad van Codeghat
Koenraad bestijgt dapper ’t ros / van de debugger, bereid / te dolen onder de linde. // Hij stapt door het beslisbos / dat hem naar hier heeft geleid / maar kan de oorzaak niet vinden.
Hoe review je eigenlijk code?
Hoe lees je eigenlijk code? Waar begin je? En in welke volgorde loop je code door? - En zit er verschil tussen het lezen van code tijdens je programmeerwerk en tijdens een code review? Ik stelde mezelf onlangs die vragen, na in Felienne Hermans’ The Programmer’s Brain te hebben gelezen dat gevorderde programmeurs op een andere manier code lezen dan nieuwelingen.
Wat is jouw mentale model?
Eerder schreef ik erover waarom het zo belangrijk is om code die data ophaalt te scheiden van code die data manipuleert. Ik kan me voorstellen dat ik lezers heb die denken: joh, dit zijn toch allemaal open deuren? Misschien hebben die lezers gelijk. Maar aan de andere kant: het aantal keren dat ik code heb kunnen verbeteren door het ophalen en manipuleren van data te scheiden, vertelt een ander verhaal. Wellicht loont het zich om daarom kort te reflecteren op een aantal redenen waarom deze goede gewoonte niet stevig verankerd is in het hoofd van elke ontwikkelaar.
Scheid data ophalen van data manipuleren
Het aantal refactoravonturen (met goede of slechte afloop) dat ik heb beleefd is, inmiddels al lang niet meer op één hand te tellen. In de loop der tijd is een terugkerend fenomeen me opgevallen: code waarin het ophalen van data niet wordt gescheiden van het manipuleren ervan. Laten we dat eens wat nader bekijken.