Būdamas jaunesniuoju programinės įrangos inžinieriumi, visada skaitydavau gautus kodų peržiūros komentarus, kad išmokčiau geresnio programuotojo. Bet kai atėjo laikas man išbandyti savo pirmąjį kodo peržiūrą, supratau, kad mano patirtis neparengė man būti kita puse.
Aš sukūriau sunkų apgaulingo sindromo atvejį, nukreipdamas žemyn į klausimus: Ar turėčiau pakomentuoti šią kodo eilutę, ar ji nėra verta? Ar turėčiau rasti straipsnių, kurie paremtų kiekvieną komentarą? Ar sutrauksiu svetainę, patvirtindamas tai? Ar jie manęs nekęs? Gerai, pripažįstu, kad spiraliauju gana greitai. Bet pakalbėjęs su kai kuriais bendradarbiais, aš žinojau, kad nerimauju ne vienas.
Jaunesniems programinės įrangos inžinieriams gali būti suteikta galimybė perskaityti kodus su prielaida, analogiška „jūs žinote, kaip skaityti knygą, kad žinotumėte, kaip rašyti knygą, o tai netiesa“, - sako Jessica Rudder, „GitHub“ patyrusi inžinierė.
Yra lūkesčių, susijusių su kodų peržiūra, ir procesas gali būti nervingas. Taigi aš apklausiau septynis kitus programinės įrangos inžinierius, norėdamas surinkti patarimus, kaip sukurti apžvalginę mintį.
1. Pagalvokite apie bendrą poveikį
Paprastai tinkamo kaupimo užklausa (PR) turėtų paveikti tik uždarą kodų bazės dalį. Tačiau ribota taikymo sritis neturėtų užkirsti kelio galvoti apie kodo pakeitimą didesnės kodo bazės kontekste.
Nigelas Munozas, buvęs „The Muse“ visos kamino inžinierius ir dabartinis laisvai samdomas programinės įrangos inžinierius, skatina apžvalgininką pagalvoti apie „kaip šis pakeitimas paveikia didesnį ir mažesnį paveikslėlį“. Turint omenyje didesnį vaizdą, reikia rasti techninių skolų - ieškokite kodo tai pakartojama, nemoduliuota arba nesilaikoma naujausių standartinių konvencijų, taip pat analizuojami kodo bazės architektūros pakeitimai.
Sam Donow, pagrindinis „Hudson River Trading“ kūrėjas, mano, kad „nėra nieko per daug ar per mažo, kad galėtumėte komentuoti. Pasiūlymai dėl nedidelių patobulinimų gali paskatinti didesnius patobulinimus keliose pagrindų bazės dalyse. “
Galite naudoti „GitHub“ PR komentarą, kad gautumėte teigiamų atsiliepimų, taip pat nurodytumėte, kur kodas gali skirtis nuo standartinių „React“ sistemos konvencijų.
Pavyzdžiui, per vieną iš savo kodų apžvalgų gavau komentarą, kad tam tikros „React“ komponento savybės yra painios, o tai sukėlė platesnius klausimus apie tai, kaip komponentas buvo naudojamas. Galų gale pašalinau pirminio komponento savybes ir sukūriau atskirą komponentą, kad paaiškinčiau kiekvieno jų elgesį ir įsitikinčiau, kad abu gali būti naudojami daugiau vietų.
2. Apsvarstykite saugumą
Nepamirškite, kad kai kurie pakeitimai gali turėti įtakos ne tik kodų bazei. Rudderis rekomenduoja įvertinti, ar vartotojas „galėtų naudoti šią funkciją siekdamas priekabiauti prie asmens, ar galėtų piktnaudžiauti sistema“. Pvz., Jei naujoji funkcija traukimo užklausoje apima vartotojo įvedimą, ieškokite SQL įterpimo, duomenų prieigos, svetainių scenarijavimo ir kitas saugumo spragas.
3. Dėmesys klaidoms
Jūsų kolegos kodo bendradarbiai - nesvarbu, kokie robotai jie gali atrodyti - yra žmonės, ir žmonės gali sulaužyti ar pamiršti funkcijas. Taigi įsitikinkite, kad „peržiūrite testus taip pat svarbiai, kaip ir likusį kodą“, pataria Abhishekas Pillai, „Mokytojų darbo užmokesčio mokytojams“ vadovas. „Jie užkirs kelią naujoms klaidoms ir taps dokumentų forma visiems kitiems, kurie ateityje su tuo dirbs“.
Testų skaitymas gali padėti suprasti naujos funkcijos funkcionalumą ir pamatyti skirtingus atvejus, kuriuos ji pristatys, o testų analizė gali padėti atkreipti dėmesį į trūkstamus atvejus ir rasti funkcijas, kurių šiame PR nėra. Jei į kodo pakeitimą neįtraukti jokie testai ir jie atrodo svarbūs, tikslinga jų paprašyti peržiūros metu.
Bet testai dar ne viskas. „Negalima per daug tikėti sistema“, - perspėja Donow. „Vien todėl, kad atlikti testai nereiškia, kad nėra klaidų“.
Taip pat galbūt norėsite „paleisti programą vietoje, kad galėtumėte ją išbandyti ir įsitikinti, ar ji veikia. Jei jis neveikia, tada nėra prasmės toliau žiūrėti “, - sako Ryanas Verneris, „ 8th Light “programinės įrangos kūrėjas. Nors kai kurie recenzentai nemano, kad rankinis testavimas turėtų būti kodų peržiūros proceso dalis - iš dalies dėl to, kad tam reikia laiko - Verner mano, kad tai yra greitas būdas nustatyti, ar turėtumėte skirti daugiau laiko peržiūrai, taip pat strategiją, kuri padėtų sumažinti didėja klaidų atsilikimas.
4. Būk komandos žaidėjas
Klišė įgauna naują prasmę, kai reikia peržiūrėti kodą. „Skirkite laiko peržiūrai, nes tai yra visų pagrindų bazė“, - sako Verneris, kuris pasisako už „kolektyvinės nuosavybės“ jausmą. Jūs, kaip apžvalgininkas, turėtumėte stengtis apsaugoti klaidas nuo didėjančių klaidų, siekdami suteikti savo komanda dirba mažiau.
Pillai naudoja gifus, kad paminėtų savo komandos draugų patvirtintus ir pasirengusius sujungti PR.
Tuo pat metu „The Muse“ technikos lyderis Charlesas Luxtonas skatina apžvalgininką suprasti ir atsiminti komandos prioritetus. Greitai artėjant prie galutinių terminų ir nesutarimų, kartais sukuriama užimtumo dalis, kuri užtikrins, kad ateityje bus patobulinta, ir tuo tarpu komentuoti aptariamą kodą yra ta pagalba, kurios jums reikia norint išlaikyk savo komandą laimingą.
Galiausiai, jei paklausite savęs, ar kodas yra prasmingas ką tik prisijungusiam prie komandos ir jį perskaičiusiam per jų pirmąsias kelias savaites, jūsų kodas bus skaitomas ir suprantamas.
5. Pasinaudokite mokymosi ir dalijimosi žiniomis procesu
Peržiūros procesas suteikia kiekvienam dalyvaujančiam asmeniui galimybę daugiau sužinoti apie kodų bazę, kalbas, sistemas ir geriausią praktiką.
Matt Jeffery, „The Muse“ lyderis, pataria apžvalgininkui „suprasti pokyčius architektūriškai. Vienas iš būdų yra perskaityti failų pavadinimus, nes jie padeda pateikti kontekstą. Pvz., Jei žiūrite į duomenų prieigos sluoksnio pakeitimus. žinote, kad nesate susijęs su verslo logika ar vartotojo sąsaja “.
Norėdami pasidalinti dokumentais, galite naudoti PR komentarą „GitHub“.
Kai išmoksti iš kodo pakeitimų, taip pat turi galimybę pasidalyti žiniomis. „Geriausia paaiškinti savo nuomonę ir pagrįsti ją dokumentais“, - sako Luxtonas. Jūsų pateiktos nuorodos į patvirtinamuosius įrodymus ir patikimus straipsnius ne tik padeda apžvalgininkui ir kodų rašytojui tyrinėti skirtingus metodus priimant galutinį sprendimą, bet ir sustiprina jų žinias apie programavimą.
Turėdami omenyje šiuos patarimus, taip pat atminkite, kad peržiūra yra laikas savo žmonėms įgyti įgūdžių. „Suteikite žmonėms naudos iš abejonės, kad jie pagalvojo apie savo požiūrį, ir nurodykite skirtingas galimybes, bandydami išsklaidyti gynybinę galią“, - sako Rudderis. „Aš palieku komentarus ir apvynioju komentarą - štai kas yra puiku, štai ką galima patobulinti, štai ką reikia pakeisti prieš sujungiant“.
Taikydami tokį požiūrį, ne tik apsaugosite savo kodo bazę nuo techninių skolų, saugumo grėsmių ir klaidų, bet ir sukursite savo komandą.
