Tag intentie van code

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).

Nóg een reden om testgedreven te ontwikkelen

Als je mij zou vragen: waarom zou je testgedreven ontwikkelen? dan zou ik zeggen: zodat je tests hebt. Maar in The Art of Agile Development van James Shore vond ik een andere reden. Test-Driven Development dwingt je na te denken hoe het is een stuk code te gebruiken, in plaats van het te implementeren. Het vraagt je om helder te krijgen: hoe kan ik deze functionaliteit zo goed mogelijk ontsluiten, in plaats van: hoe kan ik deze functionalteit zo goed mogelijk bouwen?

Hoe droog wil je je test hebben?

Ik heb in het verleden over droger tests geschreven, want ik ben een softwareontwikkelaar en wij herhalen onszelf niet graag. En precies daarom ga ik het nóg een keer over droger tests hebben - of liever: minder droge tests. Want, anders dan je als naïeve ontwikkelaar zou verwachten, gelden er voor productiecode en testcode andere regels wat betreft de mate waarin herhaling tolerabel of zelfs wenselijk is.

Code reviews als leermiddel

Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.

Dertig seconden winst in twee commits

Eén enkele commit was voldoende om de latency van een cruciale call naar onze back-end te verlengen van minder dan één seconde naar twintig tot dertig (!) seconden. Wat was er in hemelsnaam gebeurd?

Goede code documenteert zichzelf (niet)

Uit de code valt niet af te leiden wat de specificaties zouden moeten zijn. Om met David Hume (1711-1776) te spreken: een ought valt niet af te leiden uit een is. Wie zegt dat goede code zichzelf documenteert, maakt zich schuldig aan de naturalistische dwaling. En toch zit er een kern van waarheid in het idee dat goede code zichzelf documenteert.