Code Review - Den ultimative guide

Den ultimative guide til opbygning af dit teams kodegennemgangsproces

Efter at have gennemført hundreder af kodevurderinger, førende F & U-teams og selv skubbet på flere utilsigtede fejl, har jeg besluttet at dele mine konklusioner med hensyn til at opbygge den ultimative kodevurderingsproces for dit team.

Denne artikel antager, at du ved, hvad en kodeanmeldelse er. Så hvis du ikke gør det, skal du klikke her for en god introduktion.

Lad os hurtigt angive nogle ligefremme grunde til, hvorfor du skal lave kodevurderinger:

  1. Kan hjælpe med at reducere fejl i kode.
  2. Bekræft, at alle kodningskrav er opfyldt.
  3. En effektiv måde at lære af jævnaldrende på og blive fortrolig med kodebasen.
  4. Hjælper med at opretholde kodestil på tværs af teamet.
  5. Team samhørighed - tilskynd udviklere til at tale med hinanden om bedste praksis og kodningsstandarder.
  6. Forbedrer den overordnede kodekvalitet på grund af gruppetryk.

Kodevurderinger kan dog være en af ​​de sværeste og mest tidskrævende dele af softwareudviklingsprocessen.

Vi har alle været der. Du har muligvis ventet dage, indtil din kode blev gennemgået. Når det var gennemgået, startede du en ping pong med korrekturlæseren om at indsende din pull-anmodning igen. Pludselig bruger du uger på at gå frem og tilbage. Du skifter kontekst mellem nye funktioner og gamle forpligtelser, der stadig skal poleres.

Hvis kodegennemgangsprocessen ikke er planlagt korrekt, kan den have flere omkostninger end værdi.

Derfor er det ekstremt vigtigt at strukturere og opbygge en veldefineret proces til kodevurderinger inden for dit ingeniørteam.

Generelt skal du have på plads veldefinerede retningslinjer for både korrekturlæser og korrekturlæser, inden du opretter en pull-anmodning, og mens den gennemgås. Mere specifikt:

Definer perquisites til oprettelse af pull-anmodninger.

Jeg har fundet ud af, at følgende i høj grad reducerer friktionen:

  1. Sørg for, at kode kompileres med succes.
  2. Læs og kommenter din kode.
  3. Byg og kør tests, der validerer rækkevidden af ​​din kode.
  4. Al kode i codebase skal testes.
  5. Link relevante billetter / genstande i dit opgavestyringsværktøj (f.eks. JIRA) til din pull-anmodning.
  6. Tildel ikke en korrekturlæser, før du har afsluttet ovenstående.

Definer ansvarshavendes vurdering

Mens korrekturlæseren sidst er i kæden for at fusionere din PR, jo bedre den afleveres af korrekturlæseren, jo færre risici løber du ind på lang sigt. Her er nogle retningslinjer, der i høj grad kan hjælpe:

  1. Kommuniker med din anmelder - Giv dine korrekturlæsere baggrund om din opgave. Da de fleste af os forfattere til trækanmodninger sandsynligvis allerede har været korrekturlæsere, skal du blot sætte dig selv i anmelderens sko og spørge: "Hvordan kunne det være lettere for mig?"
  2. Foretag mindre pull-anmodninger - At lave mindre pull-anmodninger er den bedste måde at fremskynde din anmeldelsestid. Hold dine pull-anmodninger små, så du kan gentage hurtigere og mere præcist. Generelt er mindre kodeændringer også lettere at teste og verificere som stabile. Når en pull-anmodning er lille, er det lettere for korrekturlæserne at forstå sammenhængen og grunden med logikken.
  3. Undgå ændringer under kodevurderingen - Store ændringer midt i kodevurderingen nulstiller grundlæggende hele gennemgangsprocessen. Hvis du har brug for at foretage større ændringer efter indsendelse af en anmeldelse, kan du sende din eksisterende anmeldelse og opfølgning med yderligere ændringer. Hvis du har brug for at foretage større ændringer efter start af kodegennemgangsprocessen, skal du sørge for at kommunikere dette til korrekturlæseren så tidligt i processen som muligt.
  4. Svar på al feedback, der kan handles med kode - Selvom du ikke implementerer deres feedback, skal du svare på den og forklare din ræsonnement. Hvis der er noget, du ikke forstår, skal du stille spørgsmål inden for eller uden for kodegennemgangen.
  5. Kodevurderinger er diskussioner, ikke diktering - Du kan tænke på de fleste tilbagemeldinger om kodeanmeldelse som et forslag mere end en ordre. Det er fint at være uenig med anmelderens feedback, men du skal forklare hvorfor og give dem mulighed for at svare.

Definer korrekturansvarliges ansvar

Da korrekturlæseren sidst er i kæden, før koden flettes, ligger det en stor del af ansvaret for at reducere fejl. Anmelderen skal:

  1. Vær opmærksom på opgavens beskrivelse og krav.
  2. Sørg for at forstå koden fuldstændigt.
  3. Evaluer alle arkitektafvejene.
  4. Del dine kommentarer i 3 kategorier: Kritisk, Valgfri og Positiv. Den første er kommentarer, som udvikleren skal acceptere for at ændre, og sidstnævnte er kommentarer, der giver udvikleren kendskab til din påskønnelse af gode stykker kode.

Undgå også mange kommentarer og brug Github-gennemgang i stedet (se eksemplet nedenfor).

Når du har flere kommentarer, skal du bruge gennemgangsindstillingen i Github i stedet for at kommentere hver af dem separat og underrette udvikleren (PR-ejeren), når du er færdig.

Endelig har jeg fundet ud af, at det at stille følgende spørgsmål er et godt værktøj til en samlet bedre og lettere gennemgangsproces:

  • Har jeg svært ved at forstå denne kode?
  • Er der nogen kompleksitet i koden, som kan reduceres ved refactoring?
  • Er koden godt organiseret i en pakkestruktur, der giver mening?
  • Er klassenavnene intuitive, og er det indlysende, hvad de gør?
  • Er der nogen klasser, der er særlig store?
  • Er der nogen særlig lange metoder?
  • Virker alle metodens navne klare og intuitive?
  • Er koden veldokumenteret?
  • Er koden godt testet?
  • Er der måder, hvorpå denne kode kan gøres mere effektiv?
  • Opfylder koden vores standarder for teams-styling?

Der er forskellige effektive og forskellige fremgangsmåder til kodevurdering, der varierer afhængigt af holdets behov. Så antag at dette er min personlige mening, og at der er andre måder, der kan fungere for dit team. I sidste ende skal opbygning af en så følsom proces være subjektiv for dine virksomheds mål, teamets kultur og overordnede F & U-struktur.

Hvis du har spørgsmål eller feedback til forbedring af disse retningslinjer, er du velkommen til at tilføje en kommentar nedenfor!