Som junior programvareingeniør har jeg alltid sett kommentarer om kodevurderingen jeg fikk for å lære å bli en bedre koder. Men da det var tid for meg å prøve min første kode gjennomgang, innså jeg at min erfaring ikke hadde forberedt meg til å være på den andre siden.
Jeg utviklet et alvorlig tilfelle av imposter syndrom, spiralende nedover med spørsmål: Bør jeg kommentere denne kodelinjen, eller er det ikke verdt det? Bør jeg finne artikler som støtter hver kommentar? Vil jeg krasje nettstedet ved å godkjenne dette? Vil de hate meg? OK, jeg innrømmer at jeg spiral ganske raskt. Men etter å ha snakket med noen kolleger, visste jeg at jeg ikke var alene i bekymringene mine.
Ingeniørprogramvareingeniører kan bli kastet inn i kodegjennomgang med en antagelse som er analog med "du vet hvordan du skal lese en bok, slik at du vet hvordan du skriver en bok, noe som ikke stemmer, " sier Jessica Rudder, en erfaringsingeniør ved GitHub.
Det er forventninger som følger med kodegjennomgang, og prosessen kan være nervepirrende. Så jeg intervjuet syv andre programvareingeniører for å samle tips om hvordan man bygger et gjennomgangssett.
1. Tenk over den samlede virkningen
Generelt bør en god pull-forespørsel (PR) bare påvirke en begrenset del av kodebasen. Imidlertid bør det begrensede omfanget ikke hindre deg i å tenke på kodeendringen i sammenheng med den større kodebasen.
Nigel Munoz, en tidligere full stack engineer ved The Muse og en nåværende freelance software engineer, oppfordrer anmelderen til å tenke på “hvordan denne endringen påvirker det større og mindre bildet.” Å vurdere det større bildet inkluderer å finne teknisk gjeld - se etter kode som er gjentatt, ikke-modulbasert eller ikke overholder de nyeste standardkonvensjoner - i tillegg til å analysere endringer i kodebasens arkitektur.
Sam Donow, en sentralutvikler i Hudson River Trading, mener at “det ikke er noe for stort eller for lite til å kommentere. Forslag til små forbedringer kan føre til større forbedringer i flere deler av kodebasen. ”
Du kan bruke en PR-kommentar på GitHub for å gi positive tilbakemeldinger, samt peke på hvor koden kan avvike fra standardkonvensjoner i rammevirkningen.
Under en av mine egne kodevurderinger fikk jeg for eksempel en kommentar om at visse egenskaper på en React-komponent var forvirrende, noe som vakte bredere spørsmål om hvordan komponenten ble brukt. Til slutt fjernet jeg egenskapene fra den opprinnelige komponenten og opprettet en egen komponent for å tydeliggjøre oppførselen til hver enkelt og sikre at begge kunne brukes flere steder.
2. Tenk på sikkerhet
Ikke glem at noen endringer kan påvirke mer enn bare kodebasen. Rudder anbefaler å vurdere om en bruker “kan bruke denne funksjonaliteten for å trakassere noen eller kan misbruke systemet.” Hvis for eksempel den nye funksjonen i trekningsforespørselen inkluderer brukeroppføring, se etter SQL-injeksjon, datatilgang, scripting på tvers av nettsteder og andre sikkerhetsproblemer.
3. Fokuser på feil
Din kollega-bidragsytere - uansett hvor robot de kan virke - er mennesker, og mennesker kan ødelegge eller glemme funksjonalitet. Så sørg for at du "gjennomgår testene med samme betydning som resten av koden, " råder Abhishek Pillai, en teknisk leder hos Teachers Pay Teachers. "De vil forhindre nye feil og tjene som en form for dokumentasjon til alle andre som jobber med dette i fremtiden."
Lesing av testene kan hjelpe deg med å forstå funksjonaliteten til en ny funksjon og se de forskjellige sakene den vil introdusere, mens analyse av testene kan hjelpe deg med å peke ut manglende saker og finne funksjoner som ikke er inkludert i denne PR. Hvis det ikke er noen tester som er inkludert i kodeendringen, og de virker relevante, er det riktig å be om dem i gjennomgangen.
Men tester er ikke alt. "Ikke legg for mye tro på systemet, " advarer Donow. "Bare fordi testene ble kjørt, betyr ikke det at det ikke er noen feil."
Det kan også være lurt å "kjøre appen lokalt for å teste den funksjonelt og sørge for at den fungerer. Hvis det ikke fungerer, er det ikke noe poeng i å gjennomgå videre, sier Ryan Verner, programvareutvikler hos 8th Light. Selv om noen korrekturlesere ikke mener manuell testing bør være en del av kodevurderingsprosessen - delvis på grunn av tiden det tar - mener Verner det er en rask måte å finne ut om du bør investere mer tid i gjennomgang samt en strategi for å redusere veksten av etterslep.
4. Vær en lagspiller
Klisjéen får ny mening når det gjelder gjennomgang av kode. "Ta deg tid til å gjennomgå fordi det er alles kodebase, " sier Verner, som tar til orde for en følelse av "kollektivt eierskap." Du som anmelder bør jobbe for å beskytte etterslepet på bugs fra å bli større med mål om å gi team mindre arbeid nedover linjen.
Pillai bruker gifs for å feire lagkameratene sine godkjente og klare til å slå sammen PR-er.
Samtidig oppfordrer Charles Luxton, en teknisk leder hos The Muse, anmelderen til å forstå og huske teamets prioriteringer. Med raske frister og uenigheter som florerer, er det noen ganger å lage et gjøremål for etterslepet som sikrer forbedringer i fremtiden og å sette en kommentar til den aktuelle koden i mellomtiden er den båndhjelpen du trenger for å hold teamet ditt lykkelig.
Til slutt, med å spørre deg selv om koden ville være fornuftig for noen som nettopp hadde blitt med på teamet og leste den i løpet av de første ukene, vil bidra til å holde koden lesbar og forståelig.
5. Bruk prosessen for læring og kunnskapsdeling
Gjennomgangsprosessen gir alle involverte et sted å få mer innsikt i kodebasen, språk, rammer og beste praksis.
Matt Jeffery, teknisk leder hos The Muse, råder anmelderen til å "forstå endringene arkitektonisk. En måte er å lese filnavn siden de hjelper til å gi kontekst. Hvis du for eksempel ser på en endring i datatilgangslaget du vet at du ikke har å gjøre med forretningslogikk eller brukergrensesnitt. "
Du kan bruke en PR-kommentar på GitHub for å dele dokumentasjon.
Når du lærer av kodeendringer, har du også muligheten til å dele kunnskap. "Det er best å forklare din mening og sikkerhetskopiere den med dokumentasjon, " sier Luxton. Koblingene du gir til bevis og pålitelige artikler hjelper ikke bare anmelderen og kodeskribenten å utforske forskjellige tilnærminger når de tar en endelig beslutning, men styrker også deres kunnskaper om programmering.
Mens du husker disse tipsene, må du også huske at gjennomgang er en tid for å utøve dine ferdigheter. "Gi folk fordelen av tvilen om at de tenkte på sin tilnærming og påpekte forskjellige muligheter mens de prøvde å fjerne forsvarsfrihet, " sier Rudder. "Jeg legger igjen kommentarer og en fullstendig kommentar - her er det som er flott, her er hva som kan forbedres, her er det som må endres før jeg fusjonerer."
Med denne typen tilnærminger vil du ikke bare beskytte kodebasen din mot teknisk gjeld, sikkerhetstrusler og feil, men du vil også bygge teamet ditt.
