Som en mjukvaruingenjör granskade jag alltid kommentarer om kodgranskning som jag fick för att lära mig att bli en bättre kodare. Men när det var dags för mig att försöka min första kodgranskning, insåg jag att min erfarenhet inte hade förberett mig att vara på andra sidan.
Jag utvecklade ett allvarligt fall av imposter-syndrom med spiral nedåt med frågor: Ska jag kommentera den här kodraden eller är det inte värt det? Ska jag hitta artiklar som stöder varje kommentar? Kommer jag att krascha webbplatsen genom att godkänna detta? Kommer de hatar mig? Okej, jag medger att jag spiralar ganska snabbt. Men efter att ha pratat med några medarbetare visste jag att jag inte var ensam i mina bekymmer.
Junior-programvaruingenjörer kan kastas in i kodgranskning med ett antagande som är analogt med ”du vet hur man läser en bok så att man vet hur man skriver en bok, vilket inte är sant”, säger Jessica Rudder, erfarenhetsingenjör på GitHub.
Det finns förväntningar som följer med kodgranskning, och processen kan vara nervstängande. Så jag intervjuade sju andra programvaruingenjörer för att samla in tips om hur man bygger en granskande tankesätt.
1. Tänk på den totala inverkan
Generellt sett bör en bra pull-begäran (PR) endast påverka en begränsad del av kodbasen. Det begränsade omfånget bör dock inte hindra dig från att tänka på kodändringen inom ramen för den större kodbasen.
Nigel Munoz, en före detta full-stack ingenjör på The Muse och en nuvarande frilans mjukvaruingenjör, uppmuntrar granskaren att tänka på ”hur denna förändring påverkar den större och mindre bilden.” Att betrakta den större bilden inkluderar att hitta alla tekniska skulder - leta efter kod som upprepas, icke-modulär eller inte följer de senaste standardkonventionerna - liksom att analysera ändringar av kodbasens arkitektur.
Sam Donow, en kärnutvecklare på Hudson River Trading, anser att ”det inte finns något för stort eller för litet att kommentera. Förslag till små förbättringar kan leda till större förbättringar i flera delar av kodbasen. ”
Du kan använda en PR-kommentar på GitHub för att ge positiv feedback samt påpeka var koden kan skilja sig från standardkonventionerna i ramverket React.
Under en av mina egna kodrecensioner fick jag till exempel en kommentar om att vissa egenskaper på en React-komponent var förvirrande, vilket väckte bredare frågor om hur komponenten användes. I slutändan tog jag bort egenskaperna från den ursprungliga komponenten och skapade en separat komponent för att klargöra beteendet hos var och en och säkerställa att båda kunde användas på fler platser.
2. Överväg säkerhet
Glöm inte att vissa förändringar kan påverka mer än bara kodbasen. Rudder rekommenderar att utvärdera om en användare "kan använda den här funktionen för att trakassera någon eller kan missbruka systemet." Om till exempel den nya funktionen i pull-begäran innehåller användarinmatning, leta efter SQL-injektion, datatillgång, skript på flera webbplatser och andra säkerhetsproblem.
3. Fokusera på buggar
Dina medkodbidragare - oavsett hur robot de kan verka - är mänskliga och människor kan bryta eller glömma funktionaliteter. Så se till att du "granskar testerna med samma betydelse som resten av koden", råder Abhishek Pillai, en teknisk ledare vid lärarna betala lärare. "De kommer att förhindra nya buggar och fungera som en form av dokumentation för alla andra som arbetar med detta i framtiden."
Att läsa testerna kan hjälpa dig att förstå funktionaliteten i en ny funktion och se de olika fallen den kommer att introducera, medan analysen av testerna kan hjälpa dig att påpeka saknade fall och hitta funktioner som inte finns i denna PR. Om det inte finns några tester som ingår i kodändringen och de verkar relevanta, är det lämpligt att begära dem inom granskningen.
Men tester är inte allt. "Sätt inte för mycket på systemet, " varnar Donow. "Bara för att testen kördes betyder inte att det inte finns några buggar."
Du kanske också vill "köra appen lokalt för att funktionellt testa den och se till att den fungerar. Om det inte fungerar, är det ingen mening med att granska ytterligare, säger Ryan Verner, en programutvecklare på 8th Light. Även om vissa granskare inte tycker att manuell testning bör vara en del av kodgranskningsprocessen - delvis på grund av den tid det tar - anser Verner att det är ett snabbt sätt att avgöra om du ska investera mer tidgranskning samt en strategi för att hjälpa till att minska tillväxten av en bugg-orderstock.
4. Var en lagspelare
Klichén får ny mening när det gäller granskning av kod. "Ta dig tid att granska eftersom det är allas codebase, " säger Verner, som förespråkar för en känsla av "kollektivt ägande." Du, som granskaren, bör arbeta för att skydda eftersläpningen av buggar från att bli större med målet att ge din lag mindre arbete längs linjen.
Pillai använder gifs för att fira sina lagkamrater godkända och redo att fusionera PR.
Samtidigt uppmuntrar Charles Luxton, en teknisk ledare på The Muse, granskaren att förstå och komma ihåg teamets prioriteringar. Med snabbt närma tidsfrister och oenigheter i överflöd, ibland att skapa en att göra objekt för eftersläpningen som säkerställer förbättringar kommer att göras i framtiden och att lägga en kommentar till den aktuella koden under tiden är det bandhjälp du behöver för att hålla ditt team lyckligt.
Slutligen, om du frågar dig själv om koden skulle vara vettig för någon som just har anslutit sig till teamet och läst den inom de första veckorna kommer att hjälpa till att hålla din kod läsbar och förståelig.
5. Använd processen för lärande och kunskapsdelning
Granskningsprocessen ger alla inblandade en plats att få mer inblick i kodbasen, språk, ramar och bästa praxis.
Matt Jeffery, en teknisk ledare på The Muse, råder granskaren att "förstå förändringarna arkitektoniskt. Ett sätt är att läsa filnamn eftersom de hjälper till att ge sammanhang. Om du till exempel tittar på en förändring i datatillgångsskiktet du vet att du inte har att göra med affärslogik eller UI. "
Du kan använda en PR-kommentar på GitHub för att dela dokumentation.
När du lär dig av kodändringar har du också möjlighet att dela kunskap. "Det är bäst att förklara din åsikt och säkerhetskopiera den med dokumentation, " säger Luxton. Länkarna du tillhandahåller stödjande bevis och pålitliga artiklar hjälper inte bara granskaren och kodförfattaren att utforska olika tillvägagångssätt när de fattar ett slutligt beslut, utan stärker också deras kunskaper om programmering.
Medan du har dessa tips i åtanke, kom också ihåg att granskning är en tid att utöva dina folkfärdigheter. "Ge människor nytta av tvivel om att de tänkte på sin inställning och påpekar olika möjligheter samtidigt som de försökte fördriva försvar, " säger Rudder. "Jag lämnar kommentarer hela tiden och en sammanfattad kommentar - här är vad som är fantastiskt, här är vad som kan förbättras, här är vad som måste ändras innan den slås samman."
Med den här typen av tillvägagångssätt skyddar du inte bara din kodbas från teknisk skuld, säkerhetshot och buggar, utan du kommer också att bygga upp ditt team.
