Tag code reviews
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.
Pull requests als documentatie
Hoe vaak denk je na over de titel en omschrijving van je pull request? Als je een beetje op mij lijkt, dan is het antwoord: veel te weinig. Het goede nieuws is: je hoeft er niet over na te denken, want dat hebben de vriendelijke ontwikkelaars van Google al voor je gedaan. Onlangs las ik hun Code Review Developer Guide door, en vond daar een schat aan informatie.
Test-Driven Code Reviews
Door een alfabetisch toeval presenteert Azure DevOps elk pull request van mijn team in deze volgorde: eerst de front-end, dan de back-end - de API, de businesslogica, de datatoegang en het model - en ten slotte te tests. Onlangs stelde ik de vraag hoe je eigenlijk code reviewt - en waar je het best kunt beginnen bij zo’n beoordeling. Ik heb er een tijdje op zitten broeden, en ik denk dat ik eruit ben.
Hoe review je eigenlijk code?
Hoe lees je eigenlijk code? Waar begin je? En in welke volgorde loop je code door? - En zit er verschil tussen het lezen van code tijdens je programmeerwerk en tijdens een code review? Ik stelde mezelf onlangs die vragen, na in Felienne Hermans' The Programmer’s Brain te hebben gelezen dat gevorderde programmeurs op een andere manier code lezen dan nieuwelingen.
Wat is jouw mentale model?
Eerder schreef ik erover waarom het zo belangrijk is om code die data ophaalt te scheiden van code die data manipuleert. Ik kan me voorstellen dat ik lezers heb die denken: joh, dit zijn toch allemaal open deuren? Misschien hebben die lezers gelijk. Maar aan de andere kant: het aantal keren dat ik code heb kunnen verbeteren door het ophalen en manipuleren van data te scheiden, vertelt een ander verhaal. Wellicht loont het zich om daarom kort te reflecteren op een aantal redenen waarom deze goede gewoonte niet stevig verankerd is in het hoofd van elke ontwikkelaar.
Code reviews als leermiddel
Toen ik begon als softwareontwikkelaar, was ik eerlijk gezegd een beetje bang voor code reviews. Inmiddels zijn de rollen omgedraaid, en zijn mijn collega’s banger voor mijn code reviews dan ik voor die van hen. Feit is dat ik een stuk scheutiger ben met mijn opmerkingen dan mijn collega’s. Toch denk ik dat er in mijn commentaar maar weinig is om bang voor te zijn. Ik zie code reviews namelijk niet als middel en moment om kritiek te geven op andermans code. Of liever: niet alleen als middel en moment om kritiek te geven.