
Softwareontwikkeling is een popcultuur (maar hoeft dat niet te zijn)
Het Agile manifest belooft betere manieren van softwareontwikkeling mogelijk te maken door de nadruk te leggen op “individuals and interactions” boven “processes and tools”. Maar wat is Agile ontwikkeling verworden, ruim twintig jaar na het schrijven van dat manifest? – Scrum + Jira. Oftewel: een process en een tool.
Testen jullie private methods?
Er zit een verborgen veronderstelling in je vraag. Namelijk: dat een stuk code alleen wordt getest als deze direct wordt aangeroepen. Maar er is een verschil tussen de code die wordt aangeroepen door een test, en de code die erdoor getest wordt.
Teveel tegelijk
“We zijn met teveel dingen tegelijk bezig,” constateert een ontwikkelaar tijdens de Retrospective. Die is met dit bezig, die met dat; hij met zus en zij met zo. Er is geen eenheid, iedereen werkt op zijn eigen eiland. – Het is een terugkerend thema. Waar ligt dat aan?
Drielagencargocult
Goede abstracties worden niet bedacht. Goede abstracties worden ontdekt. Ze vinden pas het levenslicht als reactie op een concrete vraag van de codebase. Softwareontwikkeling is in wezen een empirische aangelegenheid.
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.