Agile teams zijn zelforganiserend, met overal in het team waardevolle vaardigheden. Dit wordt gedeeltelijk bereikt met codebeoordeling. Codebeoordeling helpt ontwikkelaars om de basis van code te leren en hen te helpen nieuwe technologieën en technieken te leren die hun vaardigheden vergroten.
Wat is een codebeoordeling precies?
Wanneer een ontwikkelaar klaar is met het werken aan een issue, bekijkt een andere ontwikkelaar de code en overweegt hij vragen zoals:
- Zijn er duidelijke logische fouten in de code?
- Als je kijkt naar de vereisten: zijn alle cases volledig geïmplementeerd?
- Zijn de nieuwe geautomatiseerde tests voldoende voor de nieuwe code? Moeten bestaande geautomatiseerde tests worden herschreven om rekening te houden met wijzigingen in de code?
- Voldoet de nieuwe code aan de bestaande stijlrichtlijnen?
Codebeoordelingen moeten worden geïntegreerd in het bestaande proces van een team. Als een team bijvoorbeeld workflows voor taakbranching gebruikt, start je een codebeoordeling nadat alle code is geschreven en geautomatiseerde tests zijn uitgevoerd en voltooid, maar voordat de code stroomopwaarts wordt samengevoegd. Dit zorgt ervoor dat de tijd van de codebeoordelaar wordt besteed aan het controleren op dingen die niet worden gezien door machines en voorkomt dat slechte codeerbeslissingen de hoofdlijn van ontwikkeling verstoren.
Wat levert het op voor een agile team?
Elk team kan profiteren van codebeoordelingen, ongeacht de ontwikkelingsmethodologie. Agile teams kunnen echter enorme voordelen realiseren omdat het werk over het hele team gedecentraliseerd is. Niemand is de enige persoon die een specifiek deel van de codebase kent. Simpel gezegd: codebeoordelingen helpen om het delen van kennis binnen de codebase en binnen het team te vereenvoudigen.
Met codebeoordelingen wordt kennis gedeeld
De kern van alle agile teams is onverslaanbare flexibiliteit: het vermogen om werk uit de backlog te halen en te beginnen met de uitvoering door alle teamleden. Als gevolg hiervan zijn teams beter in staat zich rond nieuw werk te verzamelen omdat niemand het 'kritieke pad' is. Full-stack engineers kunnen zowel front-end werk als werk aan de serverzijde aanpakken.
Codebeoordelingen zorgen voor betere schattingen
Herinner je je het gedeelte over schatting nog? Schatting is een teamoefening en het team maakt betere schattingen naarmate productkennis over het team wordt verspreid. Naarmate nieuwe functies aan de bestaande code worden toegevoegd, kan de oorspronkelijke ontwikkelaar goede feedback geven en schattingen maken. Bovendien wordt elke codebeoordelaar ook blootgesteld aan de complexiteit, bekende issues en zorgen over dat deel van de codebase. De codebeoordelaar deelt dan de kennis van de oorspronkelijke ontwikkelaar van dat deel van de codebase. Deze werkwijze creëert meerdere, goed ontwikkelde inputs die, wanneer ze gebruikt worden voor een definitieve schatting, die schatting altijd sterker en betrouwbaarder maken.
Codebeoordelingen maken vrije tijd mogelijk
Niemand vindt het leuk om het enige aanspreekpunt te zijn op het gebied van een stukje code. Ook wil niemand zich verdiepen in een kritiek stuk code dat ze niet hebben geschreven, vooral niet tijdens een noodsituatie bij productie. Met codebeoordelingen wordt kennis gedeeld binnen het team, zodat elk teamlid de touwtjes in handen kan nemen en het schip kan blijven besturen. (We houden van gemengde metaforen bij Atlassian!) Maar dit is het punt: omdat geen enkele ontwikkelaar kritieke pad is, betekent dit ook dat teamleden vrij kunnen nemen als dat nodig is. Als je merkt dat je vastzit aan een bureau op het versiebeheersysteem, is codebeoordeling een uitstekende manier om vrijheid te vinden. Vrijheid om die nodige vakantie te nemen, of vrijheid om wat tijd te besteden aan het werken aan een ander deel van het product.
Codebeoordelijngen geven begeleiding aan nieuwere engineers
Een bijzonder aspect van agile is dat wanneer nieuwe leden zich bij het team voegen, er meer ervaren engineers zijn die de nieuwere leden begeleiden. Codebeoordeling helpt gesprekken over de codebase te vergemakkelijken. Teams hebben vaak verborgen kennis binnen de code die tevoorschijn komt tijdens codebeoordeling. Nieuwere leden ontdekken met frisse ogen vervelende, door de tijd geteisterde delen van de codebase waarvoor een nieuw perspectief nodig is. Codebeoordeling helpt er dus ook voor te zorgen dat nieuw inzicht wordt in juiste mate met bestaande kennis wordt gecombineerd.
Houd er rekening mee dat codebeoordeling niet alleen bestaat uit een senior teamlid dat de code van een junior teamlid beoordeelt. Codebeoordeling moet in het hele team in alle richtingen plaatsvinden. Kennis kent geen grenzen! Jazeker, codebeoordeling kan nieuwere engineers helpen, maar het mag in geen geval uitsluitend als oefening worden gebruikt.
Maar codebeoordelingen kosten tijd!
Natuurlijk kosten ze tijd. Maar die tijd wordt niet verspild, juist niet zelfs.
Hier zijn drie manieren om daarvoor te optimaliseren.
De last delen
Bij Atlassian hebben veel teams twee beoordelingen van elke code nodig voordat deze wordt ingecheckt in de codebase. Klinkt dat als veel overhead? Dat is het echt niet. Wanneer een auteur beoordelaars selecteert, oriënteren ze zich breed binnen het team. Elke willekeurige twee engineers kunnen input geven. Dit decentraliseert het proces zodat niemand een knelpunt is en zorgt voor een goede dekking voor codebeoordeling in het hele team.
Vóór samenvoeging controleren
Door codebeoordeling te vereisen voordat er stroomopwaarts wordt samengevoegd, wordt ervoor gezorgd dat er geen code onbeoordeeld binnenkomt. Dat betekent dat de dubieuze architectonische beslissingen die om 2.00 uur worden genomen en een stagiair die op onjuiste wijze gebruikmaakt van een fabriekspatroon worden opgemerkt voordat ze de kans krijgen om een blijvende (en betreurenswaardige) impact te hebben op je aanvraag.
Groepsdruk in je voordeel gebruiken
Wanneer ontwikkelaars weten dat hun code wordt beoordeeld door een teamgenoot, doen ze extra moeite om ervoor te zorgen dat alle tests slagen en dat de code zo goed mogelijk is ontworpen, zodat de beoordeling soepel verloopt. Die opmerkzaamheid zorgt er ook voor dat het coderingsproces zelf soepeler en uiteindelijk sneller te laten verlopen.
Wacht niet op een codebeoordeling als er eerder in de ontwikkelingscyclus feedback nodig is. Vroegtijdige feedback zorgt vaak voor betere code, dus schroom niet om anderen erbij te betrekken, wanneer dat ook is. Dat verbetert je werk en het maakt je teamgenoten betere codebeoordelaars. En de positieve cyclus gaat door ...!
