Tag leermoment
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.
Deze blog bevat tooltips
Je hebt van die dagen, dan blog je al ruim twee jaar en dan pas ontdek je dat Markdown tooltips ondersteunt.
Tijdreis
Ik vroeg mijn collega’s: “Wat doet dit ding precies?” - waarop ze prompt de code tevoorschijn haalden en me stap voor stap door het importproces loodsten. Het was alsof ik terug werd geslingerd naar het begin van mijn ontwikkelcarrière, toen we met z’n allen een twaalf jaar oude legacy applicatie onderhielden die alleen te doorgronden was door nauwgezet de code te doorlopen. Wat blijkt: tijdreizen bestaat - je hoeft alleen maar bij een ander team te buurten.
Gedachten over modelaanpassingen
Wanneer er modelwijzigingen in het spel zijn, dan is een wijziging van de code alléén niet voldoende. Je zult ook moeten zorgen voor een migratie die de oude data omzet naar het nieuwe model. Zo’n migratie kan verschillende vormen aannemen - big bang of stapje voor stapje -, maar dat ‘ie er moet komen, staat vast. De vraag waar ik me op wil richten is: wannéér moet die migratie er komen?