Som junior softwareingeniør har jeg altid gennemgået kommentarer til kodegennemgang, jeg modtog for at lære at blive en bedre koder. Men da det var tid for mig at prøve min første kodeanmeldelse, indså jeg, at min oplevelse ikke havde forberedt mig til at være på den anden side.
Jeg udviklede et alvorligt tilfælde af imposter-syndrom, der spiralede nedad med spørgsmål: Skal jeg kommentere denne kodelinje, eller er det ikke værd? Bør jeg finde artikler, der understøtter enhver kommentar? Vil jeg gå ned på webstedet ved at godkende dette? Vil de hader mig? Okay, jeg indrømmer, at jeg spiral temmelig hurtigt. Men efter at have talt med nogle kolleger, vidste jeg, at jeg ikke var alene i mine bekymringer.
Juniorsoftware-ingeniører kan blive kastet i kodevurdering med en antagelse, der er analog med "du ved, hvordan man læser en bog, så du ved, hvordan man skriver en bog, hvilket ikke er sandt, " siger Jessica Rudder, en erfaringsingeniør hos GitHub.
Der er forventninger, der følger med kodevurdering, og processen kan være nervøs. Så jeg interviewede syv andre softwareingeniører for at indsamle tip til, hvordan man opbygger et gennemgangssyn.
1. Tænk på den samlede indvirkning
Generelt bør en god pull-anmodning (PR) kun påvirke en begrænset del af kodebasen. Dog bør det begrænsede omfang ikke forhindre dig i at tænke på kodeændringen inden for rammerne af den større kodebase.
Nigel Munoz, en tidligere full-stack ingeniør hos The Muse og en nuværende freelance software-ingeniør, opfordrer korrekturlæseren til at tænke over ”hvordan denne ændring påvirker det større og mindre billede.” I betragtning af det større billede inkluderer at finde enhver teknisk gæld - se efter kode der gentages, ikke-modulopbygget eller ikke overholder de nyeste standardkonventioner - såvel som at analysere ændringer til kodebasens arkitektur.
Sam Donow, en centraludvikler hos Hudson River Trading, mener, at “der ikke er noget for stort eller for lille til at kommentere. Forslag til små forbedringer kan føre til større forbedringer i flere dele af kodebasen. ”
Du kan bruge en PR-kommentar på GitHub til at give positiv feedback samt påpege, hvor koden kan afvige fra standardkonventionerne i rammevirkningen.
Under en af mine egne kodevurderinger modtog jeg for eksempel en kommentar om, at visse egenskaber på en React-komponent var forvirrende, hvilket fik anledning til bredere spørgsmål om, hvordan komponenten blev brugt. I sidste ende fjernede jeg egenskaberne fra den originale komponent og oprettede en separat komponent for at tydeliggøre hver enkelt opførsel og sikre, at begge kunne bruges flere steder.
2. Overvej sikkerhed
Glem ikke, at nogle ændringer kan påvirke mere end blot codebase. Rudder anbefaler at evaluere, om en bruger "kunne bruge denne funktionalitet til at chikanere nogen eller kunne misbruge systemet." Hvis den nye funktion f.eks. I pull-anmodningen inkluderer brugerindtastning, skal du kigge efter SQL-injektion, datatilgang, scripting på tværs af websteder og andre sikkerhedssårbarheder.
3. Fokus på fejl
Dine medkodeadbydere - uanset hvor robuste de ser ud - er mennesker, og mennesker kan ødelægge eller glemme funktionaliteter. Så sørg for at "gennemgå prøverne med samme betydning som resten af koden, " råder Abhishek Pillai, en teknisk leder hos Teachers Pay Teachers. "De vil forhindre nye fejl og tjene som en form for dokumentation til alle andre, der arbejder med dette i fremtiden."
Læsning af testene kan hjælpe dig med at forstå funktionaliteten af en ny funktion og se de forskellige sager, den vil introducere, mens analyse af testene kan hjælpe dig med at påpege manglende sager og finde funktioner, der ikke findes i denne PR. Hvis der ikke er nogen test inkluderet i kodeskiftet, og de synes at være relevante, er det passende at anmode om dem inden for gennemgangen.
Men test er ikke alt. ”Lad ikke for stor tro på systemet, ” advarer Donow. ”Bare fordi testene kørte betyder ikke, at der ikke er nogen fejl.”
Du ønsker måske også "køre appen lokalt for funktionelt at teste den og sikre dig, at den fungerer. Hvis det ikke fungerer, er der ingen mening i at gennemgå yderligere, ”siger Ryan Verner, en softwareudvikler hos 8th Light. Selvom nogle korrekturlæsere ikke synes, at manuel test bør være en del af kodevurderingsprocessen - delvis på grund af den tid det tager - mener Verner, at det er en hurtig måde at afgøre, om du skal investere mere tid i at gennemgå samt en strategi til at hjælpe med at begrænse væksten af en fejlbehæftelse.
4. Vær en holdspiller
Klichéen får en ny betydning, når det kommer til at gennemgå kode. ”Tag dig tid til at gennemgå, fordi det er alles kodebase, ” siger Verner, der går ind for en følelse af ”kollektivt ejerskab.” Du som korrekturlæser bør arbejde for at beskytte efterslæbet med bugs fra at blive større med målet om at give din hold mindre arbejde ned linjen.
Pillai bruger gifs for at fejre sine teamkammerers godkendte og klar til fusion PR'er.
Samtidig opfordrer Charles Luxton, en teknisk leder hos The Muse, anmelderen til at forstå og huske holdets prioriteringer. Med hurtige frister og uoverensstemmelser i overflod, er det undertiden at oprette et to-do-element til efterslæb, der sikrer forbedringer i fremtiden og at sætte en kommentar til den pågældende kode i mellemtiden er den Band-Aid, du har brug for for at hold dit team lykkeligt.
Til sidst vil du spørge dig selv, om koden giver mening for en person, der netop var tilsluttet teamet og læste den inden for deres første par uger, hjælpe med at holde din kode læselig og forståelig.
5. Brug processen til læring og viden deling
Gennemgangsprocessen giver alle involverede et sted at få mere indsigt i codebase, sprog, rammer og bedste praksis.
Matt Jeffery, en teknisk leder hos The Muse, råder korrekturlæseren til at "forstå ændringerne arkitektonisk. En måde er at læse filnavne, da de hjælper med at give kontekst. Hvis du f.eks. Ser på en ændring i datatilgangslaget ved du, at du ikke har med forretningslogik eller UI at gøre. "
Du kan bruge en PR-kommentar på GitHub til at dele dokumentation.
Når du lærer af kodeændringer, har du også muligheden for at dele viden. ”Det er bedst at forklare din mening og sikkerhedskopiere den med dokumentation, ” siger Luxton. De links, du leverer til dokumentation og pålidelige artikler, hjælper ikke kun korrekturlæser og kodeskriver med at udforske forskellige tilgange, når de træffer en endelig beslutning, men styrker også deres viden om programmering.
Mens du har disse tip i tankerne, skal du også huske, at gennemgang er et tidspunkt at udøve dine menneskers færdigheder. ”Giv folk fordelen ved tvivlen om, at de tænkte over deres tilgang og påpegede forskellige muligheder, mens de forsøger at fjerne forsvarsevne, ” siger Rudder. "Jeg lægger kommentarer igennem og en indpakket kommentar - her er hvad der er fantastisk, her er hvad der kan forbedres, her er hvad der skal ændres inden sammenfletning."
Med denne form for tilgang beskytter du ikke kun din kodebase mod teknisk gæld, sikkerhedstrusler og bugs, men du bygger også dit team.
