Tag software ontwikkelen
Wij van TDD-eend...
Het is waar: uit het feit dat er tests zijn, valt niet te concluderen dat het systeem functioneert zoals verwacht - preciezer: zoals de eindgebruiker verwacht. Er valt hooguit uit te concluderen dat het systeem functioneert zoals de schrijver van de tests verwachtte. En als de schrijver van de tests tevens de ontwikkelaar van de code is, dan vormen de tests niet meer dan een verslaglegging van de aannames die de ontwikkelaar had tijdens de implementatie. En tóch geloof ik dat TDD het probleem van mijn collega - mijn feature voldoet niet aan de (impliciete?) requirements - had kunnen verhelpen.
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?
Test het systeem, niet de class
Het is belangrijk om vast te stellen dat er een bug in het systeem was geslopen, ondanks dat de functionaliteit die de bug veroorzaakte ogenschijnlijk gedekt was door tests. Waarom “ogenschijnlijk”? De class die de serialisatie voor zijn rekening nam, werd wel getest, maar alleen in isolatie en niet in de context van het systeem. - Vraag je af wat de implicatie daarvan is. Het betekent dat onze tests bewezen dat een class naar behoren werkt. Of het systeem als geheel naar behoren werkt, dat kunnen we op basis van de tests niet concluderen. Terwijl dat juist is waar het om gaat!
Waarom zijn zoveel programmeurs bètanerds?
Als filosoof kan ik een titel als How do our ideas about coding affect the software we create? natuurlijk moeilijk weerstaan - en ik heb dan ook met veel plezier naar het gelijknamige praatje van Christin Gorman gekeken. Gorman begint vanuit een probleem: de softwareontwikkelpopulatie (3x woordwaarde) is weinig divers. Ze bestaat, gechargeerd gezegd, voor het grootste gedeelte uit nerds met interesses in de hoek van de bètawetenschappen. Hoe komt dat?
De fix die productie om zeep hielp
“De fix staat op productie,” meldden we trots. “Het bleek te liggen aan wat validatielogica die in dit specifieke scenario wat te streng bleek - enfin, een technisch verhaal, dat hoef je niet te weten. Het enige wat je hoeft te weten is: we hebben weer eens geweldig werk geleverd, bedankjes worden gewaardeerd maar zijn niet noodzakelijk.” En we leefden nog lang en gelukkig. Een halfuur lang. Want toen kregen we een berichtje: “Help! Ik kan nu geen enkel item meer inzien!”
Betere documentatie door PR-templates
Elk pull request biedt een gelegenheid om documentatie te schrijven. Toen ik dat punt een tijd geleden inbracht tijdens het tweewekelijkse Alignment-overleg van mijn team, viel mij tot mijn verbazing een hoop instemmend geknik ten deel. Hoe plezierig dat ook was, eerlijk gezegd verwachtte ik niet per se dat mijn pleidooi veel navolg zou vinden. Programmeurs en documentatie is en blijft nu eenmaal een moeilijk huwelijk. Maar mijn team verraste me positief.
Collegiale documentatie
Ik ken geen enkele ontwikkelaar die het leuk vindt om documentatie te schrijven - ik ook niet - en dat is omdat goede documentatie schrijven moeilijk is. Het is moeilijk, omdat je je vanuit een positie van iemand die snapt hoe iets werkt, je in moet leven in iemand die dat begrip nog niet heeft. Mijn belofte “even” documentatie te schrijven werd daarom al gauw “een uur” documentatie schrijven. Maar het resultaat is volgens mij wel de moeite waard, dus laten we er even (…een uur?) naar kijken.
Test-driven development is een ontwerpdiscipline
Een collega benaderde me laatst met een vraag over een stuk code. Hij was bezig met het implementeren van een feature om een toets met afbeeldingen om te zetten naar een PDF-representatie ervan. Zijn vraag was: hoe kom ik aan die afbeelding? Of liever: waar kom ik aan die afbeelding? Zijn eerste ingeving was om via dependency injection de relevante repository mee te geven aan de ImagePdfGenerator. - Het is een klassiek geval van het verknopen van het ophalen van data en het manipuleren ervan. Ik bleef wel met een knagend gevoel achter: hoe makkelijk blijkt het om dankzij een DI-container de verantwoordelijkheden van classes te verwateren - en wat moeten we daarmee?
Vijf haiku's over software ontwikkelen - Vol. 5
Ik ben zó dichtbij / deze bug te fixen sinds / twee dagen of drie.
Het probleem met technische schuld op je backlog
Zo gaat mijn team om met het monitoren van technische schuld: we prikken elke Sprint een moment waarop we er met elkaar over praten, en als we het belangrijk genoeg vinden om er wat aan te doen, dan voeren we een Product Backlog Item op om die schuld weg te werken. Die aanpak werkt goed - goed genoeg, in elk geval. De technische schuld van onze huidige applicatie blijft grotendeels binnen de perken. En bovendien - dat is nog veel belangrijker - is iedereen in het team op de hoogte van het feit dat sommige plekken verbetering behoeven, en welke plekken dat zijn. Maar toch zit iets me niet helemaal lekker in die aanpak.