Tag communicatie
De edele kunst van het pull request
Veel ontwikkelaars zien code reviews als een hinderlijke onderbreking van hun werkzaamheden. Maar het goed kunnen beoordelen van een codewijziging is essentieel om de kwaliteit van een codebase op peil te houden. Gelukkig hoeft dit proces niet pijnlijk te zijn. Aan het eind van deze sessie weet je welke vragen je moet stellen voor een geslaagde code review – en hoe je deze informatie zo effectief mogelijk overbrengt in je PR.
Mijn eerste code review
De tijd maakt alles kapot – maar nu ben ik nog jong genoeg om me mijn eerste code review te herinneren. Althans, ik herinner me een gevoel – want de inhoud van het pull request ben ik natuurlijk allang kwijt. Het gevoel laat zich denk ik het best omschrijven als een vorm van hulpeloosheid – gevolgd door ongemak.
De verplichte ChatGPT-blog
Met hulp van ChatGPT wist ik in een uurtje het functionele equivalent te leveren van code waar ik eerder dagen op heb zitten zwoegen. De tijdwinst is onomstotelijk. En op het vlak van informatieoverdracht is ChatGPT een ons “echte” ontwikkelaars mijlenver vooruit.
Waarom zou je manager jouw conferenties betalen?
Het is niet voldoende om te zeggen: “Ik wil graag naar die en die conferentie.” Als de manager van je manager vraagt om die kostenpost te verantwoorden, wat moet hij dan zeggen?
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 DRY? Waarom DAMP?
Productiecode optimaliseer je voor onderhoudbaarheid; testcode voor leesbaarheid. Waarom? Omdat de context van productiecode en testcode verschilt. Beide dienen een ander doel, wat verschillende eisen aan de code stelt. Ze opereren in verschillende sferen, zogezegd.
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.
In godsnaam, neem de tijd om je Sprint Review voor te bereiden
Een Sprint Review is geen one man show. (Al wordt het - terecht - “het feestje van de Product Owner” genoemd.) Een Sprint Review is geen PowerPoint-presentatie. (Al kan en mag er gerust PowerPoint gebruikt worden tijdens de Sprint Review.) Een Sprint Review is geen demo van de nieuwste functionaliteit. (Al wordt de nieuwste functionaliteit wel gedemonstreerd.) Een Sprint Review is een teamprestatie - maar niet alleen het team is aan het woord. Een Sprint Review is een gesprek - en in een gesprek vindt altijd plaats tussen meer mensen.