Tag intentie van code
Testen met productiedata
Laatst kwam ik een test tegen die checkte of een bepaald object 48 keer voorkwam in een lijst. Het was een hartstikke valide test, daar niet van. Maar hij riep wel de vraag op: waarom 48 keer?
Waarom documentatie belangrijk is
Er is behoefte aan documentatie. Documentatie voorziet nieuwe ontwikkelaars van een kader, een context waarbinnen ze de code kunnen begrijpen. Het alternatief is: hen zelf een context laten ontwikkelen op basis van de code. Dat is niet alleen veel tijdrovender, het brengt ook het risico met zich mee dat ze zich een onjuist begrip van de code vormen.
Over de volgorde van je unit tests
Maakt het uit in welke volgorde je unit tests staan? - Nee. Tests slechts een middel om de werking van het systeem te valideren. Het maakt niet uit in welke volgorde de tests worden afgetrapt, als ze maar allemaal slagen. (Of liever: als ze maar op het juiste moment falen.) Dat is een mogelijk antwoord. - In een praatje van Kevlin Henney vond ik een ander antwoord.
Pull requests als documentatie
Hoe vaak denk je na over de titel en omschrijving van je pull request? Als je een beetje op mij lijkt, dan is het antwoord: veel te weinig. Het goede nieuws is: je hoeft er niet over na te denken, want dat hebben de vriendelijke ontwikkelaars van Google al voor je gedaan. Onlangs las ik hun Code Review Developer Guide door, en vond daar een schat aan informatie.
Identifiers zijn ook objecten
Het oneigenlijk gebruik van “primitieve” types voor iets wat eigenlijk op een domeinniveau gedefinieerd hoort te worden, wordt primitive obsession genoemd. Het gebruik van een ingebouwd type voor een Id, is een specifieke instantie daarvan. De oplossing is: gebruik een door jou (of liever: jouw team) gedefinieerd object om het Id mee weer te geven.
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.
Spelen met Options
Options vormen de brug tussen totale en gedeeltelijke functies. Het is een type dat de eigenlijke return value van een functie wrapt. In het geval dat de mapping zinvol is, dan geeft de functie een Option terug met daarin de gezochte waarde. En als de mapping dat niet is, dan geeft deze een Option terug zónder die waarde. Wat het resultaat dus ook is, één ding weet je zeker: je krijgt een Option terug. De functie is altijd eerlijk.
De elf rollen van variabelen
Pas wanneer de vanzelfsprekendheid van code in het geding komt, gaan we nadenken - écht nadenken - over wat er op je scherm staat en waarom. Pas dan wordt de vraag “Wat doet deze variabele hier precies?” relevant. Goed, vraag jezelf nu eens af: als dat moment komt, hoe beschrijf je de rol van een variabele dan? - Heb je enig idee waar je moet beginnen bij het beantwoorden van die vraag?
Wat zijn eerlijke functies?
Uit Enrico Buonanno’s Functional Programming in C# (Second Edition) leerde het concept van een eerlijke functie kennen - en dat maakte me bewust van de oneerlijkheid van de code die ik doorgaans schrijf. Wat zijn eerlijke functies? Voordat we die vraag kunnen beantwoorden, moeten we eerst een antwoord geven op een onderliggende vraag, en dat is: wat is een functie überhaupt?
Heb je die setter echt nodig?
"prop" + tab + tab - welke C#-ontwikkelaar maakt niet bijna dagelijks dankbaar gebruik van dat code snippet om zijn ontwikkelsnelheid te verhogen? Standaard properties zijn zo alomtegenwoordig in de wereld van objectgeoriënteerd programmeren in het algemeen - en C# in het bijzonder - dat je er haast niet meer bij stilstaat dat het ook anders kan. Maar dat het ook anders kan, leerde ik dankzij Spencer Schneidenbach, in een uitstekende lezing over immutability (onveranderlijkheid).