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.
Met atomic habits het nieuwe jaar in
Het was geen goed voornemen van me, maar op 1 januari begon ik wel met een goede nieuwe gewoonte. Twee nieuwe gewoontes, eigenlijk. Het overkoepelende thema van die gewoontes is: maak de investering klein - en maak deze daarna nóg kleiner.
Eerlijke domeinmodellen
Options en Eithers vormen nog maar de eerste aanzetten voor het idee van eerlijke functies. Het zijn constructen die, op het oog althans, redelijk beperkt blijven tot het technische domein. Maar het idee van eerlijke functies past ook uitstekend bij de praktijk van het modelleren van een domein, zoals gebruikelijk in Domain-Driven Design. Dat is een les die ik leerde van Scott Wlaschin op DevTernity.
Is pair programming minder efficiënt?
Mijn team worstelt een beetje met het vlot doorzetten van pull requests. Dus vertelde ik tijdens een borrel aan een collega uit een ander team van mijn voornemen vaker te pair programmen. Hij was geen fan.
Wel code reviews, geen pull requests
Tijdens een Sprint Retrospective zei ik: “Ik heb het gevoel dat het te lang duurt voordat onze pull requests (PR’s) worden gecodereviewd. Hebben andere mensen datzelfde idee?” Ja, ze hadden hetzelfde idee. We spraken af: als je merkt dat er niets met je PR gedaan wordt, trek dan iemand even aan de jas. Het is een oplossing die vooralsnog goed genoeg werkt. Maar hij laat een belangrijke oorzaak - misschien wel dé belangrijkste oorzaak - van het probleem in stand: het bestaan van PR’s überhaupt.
Waarom ik een stapje terug doe
Het is het eind van het jaar, en dat is altijd een mooi moment om te reflecteren. - Een nog mooier moment, bedoel ik, want reflecteren doe ik aan de lopende band - onder andere middels mijn blogs. Het afgelopen jaar heb ik elke week twee blogs geschreven over alles wat mij interesseert aan softwareontwikkeling, en dat heb ik met veel plezier gedaan. Het komend jaar doe ik daarom logischerwijs een stapje terug en ga één keer per week bloggen.
De beste boeken over software ontwikkeling die ik in 2022 las
Eindejaarslijstjestijd! Net als vorig jaar en het jaar daarvoor heb ik dit jaar weer enkele fantastische boeken over softwareontwikkeling mogen lezen. Dit waren mijn vijf favorieten - en vijf eervolle vermeldingen.
Een kerstgedicht
Elke vogel zingt zijn lied maar de app werkt nu dus niet. / In de volle maan, zet je laptop aan. / Tik tik tik, tak tak tak, laat de code stromen: / De fix zal snel komen!
Efficiënter overleg dankzij Loop-componenten
Hé jij. Ja, jij. Gebruik je Microsoft Teams voor het gros van de communicatie op je werk? Ja? - Open dan eens een chat met iemand, een collega waar je vaak nauw mee samenwerkt. Onderaan, onder die balk waar je je bericht in tikt, daar zie je een icoontje staan - tussen die van de bijlagen en de emoticons in. - Zie je ’m? Hij lijkt een beetje op een mislukt apenstaartje. Dat is nou het icoon om een Loop-component in die chat te smijten.
Tests zijn specs
Kleine (of liever: te kleine) tests geven weinig informatie over de werking van het systeem. Ze verlangen van de lezer om op de hoogte te zijn van implementatiedetails, en verliezen zo het grote geheel uit het zicht. Voor grotere unittests gaat die beperking niet op. Zulke tests doen geen aannames over de interne werking van het systeem. Ze beschrijven slechts de buitenkant ervan: wat de gebruiker - hoe we die dan ook mogen definiëren - invoert en wat deze terugkrijgt. Het gevolg daarvan is dat je tests leesbaar worden voor niet-ontwikkelaars.