Har du lavet et stykke arbejde, er det altid godt at få nogle andres friske øjne til at tage et kig på det. Det gælder også for udvikling af kode og software med høj kvalitet. I Magenta bruger vi gennemsyn af andres kode under softwareudvikling (code review) både til at højne kvaliteten af den kode, der laves, og til at udvikle hinandens kompetencer.
Herunder får du et par tips til, hvordan code reviews typisk foregår i Magenta, og hvad der forventes af dig som reviewer eller udvikler.
Formålet med code review er høj kvalitet
Vi har to primære formål med code reviews.
Det ene er naturligvis relateret til kvaliteten af den endelige kode: Vi ønsker at fange og fikse så mange bugs som muligt, inden det bliver merget ind i resten af kodebasen.
Det andet formål er at udvikle dig som både udvikler og reviewer. Som udvikler vil du blive klogere på din kode, når du f.eks. bliver bedt om at forklare et valg, som reviewer ikke forstår. Som reviewer lærer du noget om, hvordan koden fungerer i det givne projekt, og hvordan andre løser et givent problem.
Så code reviews bruges i Magenta både som kvalitetskontrol og vidensdeling.
Hvordan laver du code review i Gitlab som netværksorganisation
Magenta er en netværksorganisation med mange forskellige projekter. Det vil være forskelligt fra projekt til projekt, hvordan code reviews præcist gribes an, men herunder er den generelle procedure:
Udvikler:
- Du har lavet en git branch med dine ændringer og skubber den til projektets repositorium.
- Du opretter en Merge Request™ i Gitlab og sætter en anden udvikler på denne MR som “reviewer.” Med lidt held får vedkommende en mail om, at der er en branch klar til review.
- Hvis du vil hjælpe reviewer godt i gang, kan du notere på din MRs beskrivelse, hvad du specifikt ønsker feedback på.
Reviewer:
- Du modtager besked om, at der er kode klar til review.
- Herfra varierer det meget fra projekt til projekt, hvad du skal gøre. Men som minimum bør du gå til merge request siden i Gitlab og kigge den ændrede kode igennem under “changes”-fanen. Her kan du sætte kommentarer til bestemte linier kode eller MR som helhed, som udvikleren kan læse. Forsøg at reagere på requests for review så hurtigt som muligt, så MRs ikke ligger for længe og venter.
Udvikler:
- Hvis reviewer har kommenteret på dele af koden, vil udvikleren måske skulle lave nogle ændringer og bede revieweren om at kigge på koden igen senere. I Gitlab kan man markere diskussioner som “resolved”, når en passende ændring er lavet eller et valg er blevet tilfredsstillende forklaret.
Reviewer:
- Når det hele spiller, klikker revieweren på “approve” knappen i Gitlab.
Udvikler:
- Herefter kan udvikleren merge MR og sætte sagens status til “Done” (eller anden status afhængigt af projekt).
Ting, du bør aftale inden review
Som nævnt kan review-processen variere lidt fra projekt til projekt, så hvis du er ny på et team og er klar til at kaste dig ud i dit første code review, bør du få vendt følgende spørgsmål med de øvrige på teamet:
Hvad forventes der af reviewer?
Bør reviewer checke hele projektet ud og se, om koden faktisk kører? Eller er det nok at tage et kig på koden i Gitlab før der gives approval?
Hvad har udvikleren brug for af feedback? Skal du være den menneskelige linter? Eller har udvikleren mere behov for feedback på designvalg?
Hvad forventes der af udvikler?
Skal alle review-kommentarer følges op af rettelser til koden? Nogle gange er udvikler og reviewer måske ikke helt enige om en implementering. Hvem skal have det afgørende ord?
Hvis udvikler og reviewer ikke har stort overlap i kompetencer – f.eks. hvis en Python-udvikler bliver bedt om at reviewe noget Javascript – så skal I vurdere, om det er ok. Måske skal der hentes en ekstern reviewer til projektet i stedet for.
Tips til code review i softwareudvikling
Som reviewer er din vigtigste rolle at forhindre bugs i at finde vej ud til kodebasen. Du skal naturligvis kommentere på kode, der åbenlyst er i stykker eller som du ikke kan gennemskue konsekvenserne af. Men du behøver ikke lede efter issues for at påvise, at du rent faktisk har lavet et review.
Don’t be clever. Be helpful
Du må gerne foreslå alternative løsninger eller sætte spørgsmålstegn ved issues, som ikke er direkte relateret til den reviewede kode – f.eks. fremtidige udviklingsmuligheder. Men gør det for alt i verden på en hjælpsom måde.
Hvis udvikler og reviewer har forskellige opfattelser af, hvad den bedste løsning burde være, så opret en sag på at udrede det issue og prøv at komme igennem det indeværende review med et kompromis så hurtigt som muligt. Det skader projektet mere, at MRs strander i review, end at de kommer uperfekte ud i verden.
Med disse ord ønsker vi dig et godt review.
