documentatie
Hoe commit messages ons helpen samenwerken
Wie met PR’s werkt, werkt met elk groen vinkje zijn administratie bij: die ontwikkelaar heeft de code geschreven en deze ontwikkelaar heeft die code gereviewd. De rolverdeling wordt automatisch in een systeem vastgelegd. Zoiets hadden wij niet – niet automatisch.
Procesbeschrijving pair programming
In mijn team werken we niet met pull requests. Maar hoe werken we dan? Onze security officer vroeg me een procesbeschrijving op te stellen, deels om de auditers mee tevreden te stellen en deels om kennis te delen.
Wat zegt deze test?
“Wat zegt deze test?” – Het meest voor de hand liggende antwoord is natuurlijk: wat de code doet. Maar dat is slechts wat een test expliciet zegt, de informatie die een test inhoudelijk overbrengt. Dat is niet het enige wat het zegt – verre van.
Altijd up to date documentatie met maximaal descriptieve tests
Door extra aandacht te besteden aan de scope en leesbaarheid van je tests, kun je deze transformeren van eenvoudig validatiemechanisme naar gezaghebbende bron van informatie voor ontwikkelaars. Met maximaal descriptieve tests is je documentatie altijd up to date.
Waar doe je het voor?
Een luie programmeur grijpt alles aan om zijn eigen werk makkelijker te maken (met uitzondering van het besparen op kwaliteit - daar is een andere term voor: een slechte programmeur). En makkelijker maken betekent meestal: automatiseren. Want waarom zou je zelf het werk doen, als een machine het ook voor je kan doen?
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.
Testen met productiedata
Laatst kwam ik een test tegen die checkte of een bepaald object 48 keer voorkwam in een lijst. Het was een hartstikke valide test, daar niet van. Maar hij riep wel de vraag op: waarom 48 keer?
Aantekeningen over requirements - deel 2
Het opstellen van de juiste requirements is één van de moeilijkste onderdelen van softwareontwikkeling. In een eerdere blog beschreef ik de eerste acht lessen die Karl Wiegers of dit onderwerp formuleerde in Software Development Pearls. In deze blog volgen de tweede acht.
Aantekeningen over requirements - deel 1
Het moeilijkste onderdeel van softwareontwikkelen is niet het juist bouwen, maar het juiste bouwen. Vaak zwoegen programmeurs dagenlang op hun code en worstelen testers zich door het resultaat heen, om er pas helemaal op het eind van de ontwikkelcyclus achter te komen dat er iets is gebouwd waar eindgebruikers niet helemaal (of: helemaal niet!) op zaten te wachten. Het scheppen van een juist beeld van wat er gemaakt moet worden is misschien wel de belangrijkste stap in het ontwikkelen van software - en niet zelden de minst ontwikkelde.
Waarom documentatie belangrijk is
Er is behoefte aan documentatie. Documentatie voorziet nieuwe ontwikkelaars van een kader, een context waarbinnen ze de code kunnen begrijpen. Het alternatief is: hen zelf een context laten ontwikkelen op basis van de code. Dat is niet alleen veel tijdrovender, het brengt ook het risico met zich mee dat ze zich een onjuist begrip van de code vormen.