Wat betekent het tests te schrijven?
Het is een terugkerend thema in onze Retrospectives: testcapaciteit – en dan natuurlijk vooral het gebrek eraan. Het komt regelmatig voor dat verschillende pull requests een tijd lang open blijven staan, wachtend op iemand die de testautomatiseringsscripts aan de codewijziging toevoegt.
Enkele gedachten over code reviews
De praktijk van pull requests is een vertragingstactiek. Dat is een teken dat er niet op vertrouwd kan worden dat de kwaliteit van nieuwe code structureel aan de gewenste kwaliteitsstandaarden voldoet. Zo bezien, zijn PR’s een pleister op een wond die veel intensievere behandeling behoeft.
De beste boeken over software ontwikkeling die ik in 2024 las
Het is weer die tijd van het jaar! Wat waren de beste boeken over softwareontwikkeling die ik het afgelopen jaar heb verorberd?
Is TDD alleen nuttig als iedereen het doet?
Het is geen geheim dat ik een liefhebber ben van Test-Driven Development. Ik schrijf er regelmatig over op dit blog, probeer mijn collega’s de kneepjes van de praktijk eigen te maken, en laat het onderwerp graag ter sprake komen wanneer ik vakgenoten spreek op gebruikersgroepen of conferenties. – Vaak krijg ik de repliek: “Allemaal leuk en wel, dat TDD, maar dat heeft eigenlijk alleen maar zin als iedereen in het team het doet.” Daarmee implicerend: en dat is waarom ik het niet doe.
De filosofische geschiedenis van een ontwerpkeuze
Softwareontwikkelaars schrijven niet slechts code, ze scheppen een model van de werkelijkheid. Wat dat betreft staan ze in een lange filosofische traditie. Oftewel: wat kunnen Plato en Wittgenstein ons leren over het modelleren van een (on)geverifieerd e-mailadres?
Aanpassen of: toevoegen, vervangen en verwijderen
Laatst wilde ik een methodsignatuur op een interface aanpassen. Een naïeve manier om dat aan te pakken, zou zijn: pas de signatuur op de interface aan, kijk naar de compilatiefouten die dat oplevert op de implementerende classes, en werk die weg. – Maar het probleem van die aanpak is dat dit de codebase voor langere tijd in een gebroken staat houdt.
Meer refactoring en Hannah Arendt
Wanneer ontwikkelaars refactortaken apart inplannen of refactoren nalaten omdat ze er geen toestemming voor hebben, dan is dat een teken dat ze de activiteit van het refactoren fundamenteel verkeerd begrijpen. Helaas is dat misbegrip stevig verankerd in de wereld van de softwareontwikkeling dankzij de metafoor van technische schuld.
Waar zit de fout?
Mijn collega bracht een argument in dat vaak wordt genoemd als ik mensen vertel over testen via de voordeur: maar door de code direct aan te roepen, geven mijn tests onmiddellijk feedback over waar de fout zit. Als deze tests beginnen te falen, dan weet ik zeker dat daar de fout zit. En dat scheelt tijd in het debuggen van de code. – Maar dat laat de volgende vraag onverlet: is een unittest (waarbij “unit” wordt opgevat als “eenheid van code”) het beste middel om erachter te komen waar de fout zit?
De wet van Postel
Het is niet de verantwoordelijkheid van de aanroepende partij om de input van een functie te schiften opdat er valide waarden worden meegegeven. Een functie moet zo eerlijk mogelijk zijn in wat het accepteert – maar daar waar er speelruimte bestaat is het de verantwoordelijkheid van de functie zelf om de inputs te valideren.
Bugs zijn defecten
Een softwareontwikkelaar is: iemand die defecten fixt die hij zelf heeft geïntroduceerd.