code reviews
Voorbeeldarchitectuur
Een collega in een ander team is bezig een oude applicatie te vernieuwen. Hij vroeg een andere senior en ik om zijn opzetje voor een nieuwe structuur te reviewen. Zelf had ik, merkte ik, geen sterke meningen over de code – of liever: de implementatie. Zit er een goed vangnet omheen? Dan geloof ik het wel. Ik had tegen het eind van de sessie één vraag: “Is de complexiteit van de code in verhouding met de complexiteit van het probleem?”
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.
PR's vs. pairs
Je maakt een branch, je wijzigt de code. Je maakt een pull request (PR) aan om deze te integreren in de main branch. Voordat die code toegestaan wordt, moet deze eerst door een collega worden bekeken. Pas als deze zijn zegening heeft gegeven, mag de code worden geïntegreerd. – Vanwaar deze opzet?
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.
De edele kunst van het pull request, Redux
Het praatje dat ik in 2024 op T-DOSE gaf, The art of the pull request, is onlangs op YouTube verschenen. Gezien mijn houding naar pull requests de afgelopen twee jaar is veranderd, leek het me een mooie gelegenheid om die ideeën nog eens te overdenken.
Moeten refactorings ook gereviewd worden?
Niet elke codewijziging is gelijk. Sommige wijzigingen veranderen het gedrag van een systeem. Andere wijzigingen, refactorings, veranderen alleen de structuur en laten het gedrag gelijk. Zoals de meeste teams hun werk inrichten, met pull requests en formele code reviews, wordt elke wijziging door twee paar ogen bekeken. Maar is dat wel nodig?
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.
Imperatieve Options?
Ik gebruik Options graag, ze voorkomen een hoop foutmeldingen. Maar, belangrijker nog, ze maken mijn code expressiever en eleganter. Of liever: ze hebben de potentie dat te doen. Laatst kwam ik tijdens een codereview een functie tegen, waarop mijn primaire reactie was: dit moet anders. – Maar waarom?
Immutability en het Single-Responsibility Principe
Het correct – en dus volledig – instantiëren van een object is één verantwoordelijkheid. Het geïnstantieerde object gebruiken is een andere. Wie beide met elkaar vermengt, schrijft onnodig complexe code. Dat is waarom we er naar moeten streven onze objecten nooit aan te willen passen.
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.