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.
Waarom wil Carl niet pairen?
Scenario: Alice en Bob bespreken hun positieve ervaringen met pair programming in de Sprint Retrospective. Ze stellen voor het vaker te doen. Carl is defensief. “Ik vind het niet fijn als een ontwikkelaar op mijn vingers meekijkt hoe ik code typ.” – Wat is hier aan de hand?
Karl overdenkt een metafoor
Via code praat je met de geest van een andere ontwikkelaar. Hij zegt: dit is in hoeverre ik het probleem heb gesnapt. Soms antwoord je: maar ik weet nu beter!, of: over dat scenario had ik nog niet nagedacht! – Via code praat je met een ontwikkelaar zoals je met een schrijver praat via een boek. – Maar tegelijkertijd zegt men toch ook: de Auteur is dood.