Interaktive code reviews er spild af tid

Interaktive code reviews har eksisteret siden de første code reviews – omkring sidst i 70’erne. I dag er det et fast værktøj for stort set alle gode udviklerteams (laver i ikke code reviews, så læs denne artikel). Men – ikke alle code reviews er skabt lige. En særlig udbredt type er på en god dag værdiløs.

Den type reviews vi oftest møder er det, vi kalder ”interaktive” code reviews. Der sætter udvikleren og revieweren sig ned sammen og gennemgår koden. Hvis de sidder det samme sted, foregår gennemgangen ofte ved udviklerens skrivebord – måske endda ved at revieweren står bag ved og kigger over skulderen.

Alternativt, kan det selvfølgelig foregå gennem et videokonferenceværktøj. Det er typisk en relativt hurtig proces, men også en proces med nogle udfordringer, som vi kigger nærmere på her:

Når revieweren og udvikleren sidder sammen, er det normalt udvikleren, der sidder i førersædet og guider revieweren gennem koden. Det sker ofte når udvikleren er ivrig for at vise sit arbejde frem eller hvis han har kæmpet med opgaven længe, og gerne vil have den lukket, så de kan arbejde videre på næste opgave.
Mens udvikleren blæser afsted gennem mesterværket, skal revieweren:

At holde styr på alle de opgaver er ikke nemt, og revieweren vil typisk være nødt til at antage en masse ting. Det begrænser den kritiske tænkning, der er så vigtig en del af reviewet. Udover det er en guidet tour gennem koden kontraproduktiv, når reviewerens opgave i bund og grund er at vurdere, om koden er let at læse og forstå uden forklaring.

En undersøgelse foretaget af Microsoft Research viser, at reviewerens status i det sociale hierarki på teamet påvirker kvaliteten af code reviewet. Den viste, at en reviewer, der er placeret lavere i hierarkiet end udvikleren, vil være mindre kritisk i sit review. Den effekt bliver sandsynligvis kun større af at de to sidder sammen.

Sociologen Erving Goffman har også fremsat ”Face teorien”. En teori der grundlæggende siger, at mennesker gerne vil hjælpe andre mennesker med at opretholde deres facade (’face’). På samme måde som Microsoft Research’s undersøgelse ligger det lige for, at det bliver forstærket af at sidde sammen.

Et review vil være mere objektivt, hvis reviewer og udvikler ikke sidder sammen.

For at lave et review sammen, skal udvikler og reviewer finde et tidspunkt, der passer ind i begges kalender. Det fører til forstyrrelser og en præference for korte code reviews. Det betyder også at flere iterationer og flere forskellige reviewers bliver rigtig besværligt.

Problemet bliver kun større hvis revieweren også har kontakt med andre afdelinger (forretningen) – det betyder typisk at kalenderen er godt fyldt med møder.

Der er ikke kun dårlige ting ved den interaktive metode. Når udvikleren gennemgår sin kode og forklarer den for revieweren, forklarer han også sin egen tankeproces. Det kan hjælpe ham til at opdage fejl i hans ræssonement eller forkerte antagelser. Det kan også bare vise, at en del af koden ikke er så forståelig, som han troede til at starte med.

De erfaringer vil hjælpe udvikleren forstå hans egen tendenser og vaner. Som Galileo sagde: ”Du kan ikke lære et menneske noget. Du kan bare hjælpe det til at opdage det i sig selv.”

Selvom det kan “virke”, virker det ineffektivt at skulle forstyrre en kollega med et interaktivt code review, bare for at gennemgå din egen tankeproces igen.

Der findes historier om udviklerteams, der har en bamse på kontoret til samme formål. Det er måske ikke så fjollet som det lyder – det kan ofte være en fordel for tankeprocessen at forklare problemstillinger højt.

Reviewet er en ekstremt effektiv måde at dele viden og hjælpe yngre udviklere på vej på. Det kan du læse mere om her.

Men hvordan får vi skabt en effektiv proces for reviews? Du kan spørge dig selv: “hvad ville jeg gøre, hvis jeg havde hyret en korrekturlæser til en bog eller en artikel?”.

Du ville formodentlig lade revieweren læse og komme med kommentarer i fred og ro – når det passer ham/hende. Det du gerne vil have er en ærlig vurdering, baseret på hans/hendes erfaring. Er det til at læse? Nemt at forstå? Fejlfrit?

Det leder os til den konklusion at code reviews skal:

Ved at lade revieweren foretage reviewet når det passer ham, kan han passe det ind, når det passer ham. Det giver ham mulighed for at bruge den tid, han har brug for, hvis han skal gøre det ordentligt. Og det giver ham mulighed for at gøre det på et tidspunkt, hvor hans energiniveau og mindset matcher opgaven. Det asynkrone review betyder også, at det er praktisk muligt at have mere end en reviewer.

Processen hvor en reviewer sidder for sig selv og skal gennemgå koden minder om, når en udvikler skal grave i en kodebase for at lave rettelser. Det bliver på den måde en direkte test af, om koden er til at vedligeholde. Udover det – i kraft af at revieweren skal kommunikere med udvikleren på skrift, vil alle kommentarer være dokumenteret til senere brug.

De fleste værktøjer til version control giver en mekanisme til at reviewe kode på denne måde. Bitbucket og Github har begge rigtig gode værktøjer til at reviewe på den måde. Men du har også masser af muligheder, selvom du ikke bruger en af de tjenester.

Undgå interaktive code reviews. De er, i bedste fald, spild af tid. For at være effektive skal code reviews gennemføres på reviewerens præmisser.