Profielfoto
Karl van Heijster

softwareontwikkelaar · blogger

Hoe ik hopelijk (nóg?) betere presentaties geef

Laatst verzorgde ik een Developer Meet-up over het schrijven van (nóg betere) unittests. Volgens mij ging de presentatie heel aardig (jeej!), maar ik heb het meest geprofiteerd van alles wat er niet goed aan ging. Liever gezegd: ik heb het meest geprofiteerd van de woorden die mij die ochtend waren aangereikt om te kunnen duiden waarom sommige dingen beter konden. Want toevallig volgde ik die ochtend een (online) masterclass online presenteren van Serge van Rooij - waar ik veel meer aantekeningen bij maakte dan ik op voorhand verwacht had. En omdat deze blog nu eenmaal het product is van een verwoede kennishamsteraar, deel ik met alle liefde de inzichten die ik graag nét een weekje eerder had willen weten.

De ForEach aan het eind van je functieketen

Het idee dat een functie altijd een waarde retourneert, is erg krachtig. Zo zorgt het ervoor dat je eenvoudige tests voor je functies kunt schrijven. Helaas is de werkelijkheid weerbarstig, en is het retourneren van een waarde niet altijd voldoende. Soms moet code neveneffecten bewerkstelligen. Denk bijvoorbeeld aan het wegschrijven van bepaalde data naar een tekst- of zipbestand. Het resultaat van zulke code kan niet in een teruggegeven waarde worden gevangen.

Horizontale en verticale architectuur

Als we onze applicatie verticaal op zouden hakken, dan zouden we af kunnen komen van onze ongemakkelijke naamgevingsconventies. Elke slice zou zijn eigen project krijgen, en elk project zijn eigen model. Of het nu over items in isolatie gaat, of items in een toets, of items in een itembank - we zouden in de code altijd over Item kunnen spreken - net als de gebruiker.

Betere documentatie door PR-templates

Elk pull request biedt een gelegenheid om documentatie te schrijven. Toen ik dat punt een tijd geleden inbracht tijdens het tweewekelijkse Alignment-overleg van mijn team, viel mij tot mijn verbazing een hoop instemmend geknik ten deel. Hoe plezierig dat ook was, eerlijk gezegd verwachtte ik niet per se dat mijn pleidooi veel navolg zou vinden. Programmeurs en documentatie is en blijft nu eenmaal een moeilijk huwelijk. Maar mijn team verraste me positief.

Wat is een functor?

Wat is een functor, vraag je? Lang verhaal kort: functors zijn typen die een Map-functie implementeren. Wat is een Map-functie, vraag je? Lang verhaal kort: ken je LINQ? - heb je wel eens Select gebruikt? - nou, dat dus. Maar misschien loont het zich er nét iets langer bij stil te staan.

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.

Twee sonnetten over Product Owners

Het staat me nu nog helder voor de geest / hoe hij uit zijn ogen keek: compleet maf. / Schuimend vroeg hij of er ook gewerkt was / of dat we twee weken hadden gefeest.

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.