Forestil dig: Dit team er for nyligt blevet hyper-produktivt, selv om det er et lille team. Dejlig situation, ikke? Desværre betyder det også at din bedste senior-udvikler er ved at knække nakken på køen af ting der skal reviewes. Resten af teamet kender ikke domænet helt så godt som hende, så hvis reviewet skal have vægt, så skal koden forbi hende. Det er ikke den sjoveste position for din senior-udvikler og hun sukker jævnligt over hendes karrierevalg som har ført hende til den position, men hun gør sin pligt og giver grundig feedback til al kode.
Hvad gør vi som team?
Vi kunne starte med at tage et kig på hvorfor vi reviewer. Er reviewet en kvalitets-sikring for at undgå bugs? Kigges der efter hvorvidt vores kode-standarder er overholdt? Et reviewet vidensdeling så der kan holdes et overblik? Eller er reviewet en godkendelsesproces? Er det for at tjekke at koden rent faktisk adresserer problemet – altså at der ikke er misforståelser af domænet og problemet? Er det for at tjekke Definition of Done? Er det for at tjekke arkitekturen? Non-funktionelle krav? At vi stadig overholder API-kontrakter? Sikkerhedproblemer? Har vi introduceret en ny måde at gøre tingene på som skal diskuteres?
Når vi ved hvad vi skal have ud af reviewet er det nemmere at optimere.
Et godt sted at starte kunne være at se om nogle reviews kan undværes. Er dette en prototype? Er det en meget simpel, begrænset ændring som kunne være lavet af en 4-årig? Er koden lavet med pair-programming/mob-programming og på den måde måske allerede reviewet? Lav en risiko-vurdering og se om reviewet kan undværes.
Men mange reviews kan nok ikke undværes, så hvad gør vi med dem? Vi kan kigge på grunden til at reviewe og se om det kan adresseres på andre (gerne automatiserede) måder.
Hvis vi reviewer for at undgå bugs, kan de en stærk testsuite være svaret og en fælles kultur omkring kvalitet. Stoler vi på vores tests? Kører vi TDD? Har vi brugt tid på vores tests? Er de primære flows dækket godt af tests?
Statisk kodeanalyse kan også adressere en god bunke review-vinkler. Finde død kode, forkert brug af API, standard sikkerhedproblemer såsom SQL injection, duplikeret kode, lange metoder, brud på konventioner omkring navngivning, dårlig formattering og sågar nogle performance problemer.
Generelt skal mennesker ikke bruges til at tjekke de ting vi kan tjekke med maskiner.
Vi kan også se på om vi kan hjælpe til (f.eks. parprogrammering) tidligere i processen, så misforståelser bliver fanget tidligt.
Og så er der også hele processen omkring reviewet. Skal det være senior-udvikleren der reviewer? Er der andre der kan lave et delvist review? Skal det være seniorudvikleren alene? Kan vi gå sammen om at reviewe, så alle i teamet får en forståelse? Kan en junior reviewe før en senior og dermed stille nogle mere eller mindre gode spørgsmål, som kan fange noget? En junior udvikler har måske netop de rette øjne til at se om koden er forståelig – hvis ikke alle teammedlemmer kan forstå koden, er det så god kode? Kan vi bruge AI til at lave et “first-pass” review? Kan vi sikre at en pull request er en god størrelse – altså ikke rører 100 forskellige filer og adresserer 4 forskellige issues? Hvordan håndterer vi et review, når vi ER nød til at opgradere et bibliotek og dermed rører 100 forskellige filer selv om vi kun adresserer 1 issue… i fællesskab?
Vi kan altså fange mange ting inden reviewprocessen fører os forbi hende senior-udvikleren vi mødte i indledningen. Servere koden på et sølvfad, så hun kun skal reviewe den domæneforståelse som hun er den der har mest af. Og ikke bare koden – gør hele processen omkring et review nemt og hurtigt og ikke noget man skal ind i flere forskellige systemer for at gøre eller at man skal skrive en rapport ud fra reviewet. Er reviewet snarere en uformel samtale? Gør hvad der virker for jer.
Hvis andre tiltag er blevet taget først, kan seniorudvikleren stole på koden på en lang række punkter. Dermed bliver reviewprocessen kortere, har færre reviewpunkter og tager hende ud af flow i kortere tid.
Hvis hun tager hele teamet med i reviewprocessen kan vi endda med tiden komme derhen hvor alle i teamet kan reviewe med lige så stor tillid fra teamet. Der er ikke så koldt på toppen, hvis vi står der sammen.
Altså hvis vi skal opsummere:
– Brug ikke mennesker til at tjekke det der kan være automatiske tjek for.
– Tag flere teammedlemmer med på rejsen. (Så er den også sjovere)
– Optimer review-processen ved at servere opgaven på et sølvfad og gøre den let-vægt.
Og nu til et lidt provokerende spørgsmål – producerer vi for meget kode, hvis vi ikke kan nå at reviewe det? For meget kode til at vi kan følge med til at forstå koden? Skal vi sætte farten ned? Er teamets fælles kode-ejerskab og forståelse en del af den produktleverence vi forventer af os selv?
Så hvis I har en lang review-kø så stil jer selv dette centrale spørgsmål. Målet med et review er at få værdifuldt, forståelig, sikker kode i produktion uden at gøre nogen til en flaskehals i processen – hvordan gør vi det bedst i vores situation?
