Tag leermoment

Imperatieve Options?

Ik gebruik Options graag, ze voorkomen een hoop foutmeldingen. Maar, belangrijker nog, ze maken mijn code expressiever en eleganter. Of liever: ze hebben de potentie dat te doen. Laatst kwam ik tijdens een codereview een functie tegen, waarop mijn primaire reactie was: dit moet anders. – Maar waarom?

Een oudergesprek

Onlangs mocht ik op mijn oude universiteit jonge studenten (en hun ouders) geruststellen: het is goed mogelijk een leuke en uitdagende baan te bemachtigen met een studie filosofie. Na afloop had ik een leuk gesprek met een Steve Jobs-lookalike – een vader, geen student –, die me vertelde dat ook hij overwoog om te leren programmeren. Hij zei wat iedereen zegt die overweegt te leren programmeren: “Ik heb het altijd leuk gevonden om dingen uit elkaar te halen om te kijken hoe ze werken.” – En ik besefte me opeens: ik heb dat totaal niet.

Testen: Een filosofisch retrospectief

Eerst programmeren de programmeurs, dan testen de testers: het komt niet vaak voor dat zo’n voor de hand liggend idee zoveel misvattingen herbergt. Welk aannames liggen ten grondslag aan dat idee? En wat gebeurt er wanneer we die aannames kritisch tegen het licht houden?

YAGNI veronderstelt tests

Er zijn twee soorten ontwikkelaars: ontwikkelaars die roepen: “You ain’t gonna need it”, en ontwikkelaars die mompelen: “Ja ja, dat roep je wel, maar ik bouw het voor de zekerheid toch maar in.” Ik behoor tot het eerste kamp; enkele van mijn collega’s tot het tweede. – Maar waarom?

Callback hell

In mijn werk als C#-ontwikkelaar maak ik veelvuldig gebruik van functionele programmeerconcepten. Als een functie me een object T teruggeeft of niet, dan codeer ik dat netjes in de signatuur van die functie door een Option<T> terug te geven. Dat dwingt de aanroepende partij om beide scenario’s expliciet af te handelen. Hartstikke handig! – Maar: niet zonder zijn eigen set problemen. Want wat gebeurt er als je meerdere functies achter elkaar aanroept die allemaal een Option<T> teruggeven? Dan komen we terecht in wat men callback hell noemt.

Revert!

Drie dagen hebben we de boel lopen te debuggen. Bij elke nieuwe wijziging leken we verder te zakken in een onverklaarbaar moeras van verborgen afhankelijkheden. Op een gegeven moment was ik het zat. Ik zei: “Ik ga de boel terugdraaien.” (Mijn collega, verslagen, zag al zijn harde werk voor zijn ogen in vlammen opgaan.) “Niet alles, maar wel alles in die ene class. En dan ga ik je wijziging één voor één opnieuw toepassen, net zolang totdat er tests falen.”

Waarom, wat en hoe

Waarom bestaat deze code? – wat doet het? – en hoe doet het dat? Ik maaide het gras van mijn achtertuin, toen me inviel dat het beantwoorden van die vragen niet beperkt blijft tot het lezen van code. Elke ontwikkelaar stelt zichzelf precies dezelfde vragen als deze code gaat schrijven. En een goede ontwikkelaar beantwoordt ze in die volgorde.

Nog enkele reflecties op pull requests

Onlangs hield ik een praatje op het werk over de edele kunst van het pull request. Het gesprek dat naar aanleiding daarvan ontstond, vond ik erg waardevol. Het geven van een goede presentatie werkt in bepaalde zin net als software ontwikkelen: je maakt een eerste versie, legt die voor aan een groep mensen, en gebruikt hun feedback om een betere tweede versie te ontwikkelen.

Schone interfaces, simpele implementaties

Het dilemma was als volgt: ofwel de deadline missen met een “goede” oplossing (dat wil zeggen: een oplossing die de REST-standaard volgt), ofwel de deadline halen met een slechte (die een uitzondering introduceert in de opzet van onze API). Maar: dat is een vals dilemma.

De verplichte ChatGPT-blog

Met hulp van ChatGPT wist ik in een uurtje het functionele equivalent te leveren van code waar ik eerder dagen op heb zitten zwoegen. De tijdwinst is onomstotelijk. En op het vlak van informatieoverdracht is ChatGPT een ons “echte” ontwikkelaars mijlenver vooruit.