code reviews
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.
Blog #250!
Jeetje, ik blog alweer een tijdje! Er zijn 767 dagen voorbij gegaan sinds ik mijn honderdste blog schreef. Dus: feest! Vandaag blik ik terug op de laatste 150 blogs.