Kot mlajši programski inženir sem vedno preučil komentarje o pregledu kode, ki sem jih prejel, da se naučim postati boljši koder. Ko pa je prišel čas, da poskusim svoj prvi pregled kode, sem ugotovil, da me moja izkušnja ni pripravila na drugo stran.
Razvil sem hud primer sindroma imposterja, ki se spušča navzdol z vprašanji: Ali naj komentiram to vrstico kode ali je ni vredno? Naj najdem članke, ki podpirajo vsak komentar? Ali bom s tem odobril spletno mesto? Ali me bodo sovražili? Okej, priznam, da sem hitro spiral. Toda po pogovoru z nekaterimi sodelavci sem vedel, da nisem sam v skrbeh.
Mlajši programski inženirji bodo morda vključeni v pregledovanje kode s predpostavko, ki je analogna "saj znate brati knjigo, da boste znali napisati knjigo, kar ni res, " pravi Jessica Rudder, izkušena inženirka pri GitHubu.
Obstajajo pričakovanja, ki jih spremlja pregled kode, postopek pa je lahko živčen. Tako sem opravil razgovor s sedmimi drugimi inženirji programske opreme, da sem zbral nasvete, kako sestaviti mnenje o pregledu.
1. Razmislite o celotnem vplivu
Na splošno bi morala dobra zahteva za vleko (PR) vplivati le na omejen del zbirke kod. Vendar vas omejen obseg ne bi smel preprečevati, da razmišljate o spremembi kode v okviru večje zbirke kod.
Nigel Munoz, nekdanji inženir s polnim stanjem pri The Muse in sedanji samostojni programski inženir, recenzenta spodbudi k razmišljanju o "kako ta sprememba vpliva na večjo in manjšo sliko." Glede na to, da večja slika vključuje iskanje kakršnega koli tehničnega dolga - poiščite kodo ki se ponavlja, nemodularno ali se ne drži najnovejših standardnih konvencij - kot tudi analizo sprememb arhitekture kodne baze.
Sam Donow, osrednji razvijalec pri Hudson River Trading, meni, da "ni nič prevelikega niti premajhnega, da bi ga lahko komentirali. Predlogi za majhne izboljšave bi lahko privedli do večjih izboljšav v več delih kode. "
S PR komentarjem na GitHub lahko uporabite pozitivne povratne informacije in opozorite, kje se koda lahko razlikuje od standardnih konvencij okvirnega React-a.
Med enim lastnim pregledom kode sem na primer prejel komentar, da so nekatere lastnosti komponente React zmedene, kar je sprožilo širša vprašanja, kako se komponenta uporablja. Na koncu sem lastnosti odstranil iz prvotne komponente in ustvaril ločeno komponento, da bi razjasnil vedenje vsake posamezne in zagotovil, da se lahko oboje uporablja na več mestih.
2. Razmislite o varnosti
Ne pozabite, da lahko nekatere spremembe vplivajo na več kot samo kodno bazo. Rudder priporoča oceno, ali bi uporabnik "lahko to funkcijo uporabil za nadlegovanje nekoga ali bi lahko zlorabil sistem." Na primer, če nova funkcija v zahtevi za vleko vključuje uporabnikov vnos, poiščite injekcijo SQL, dostop do podatkov, skriptno preiskovanje spletnih strani in druge varnostne ranljivosti.
3. Osredotočite se na hrošče
Vaši sodelavci kode - ne glede na to, kako robotično se zdijo - so ljudje in ljudje lahko zlomijo ali pozabijo na svoje funkcije. Tako se prepričajte, da "preverjate teste z enakim pomenom kot preostala koda", svetuje Abhishek Pillai, vodja tehnike pri Teachers Pay Teachers. "Preprečili bodo nove napake in služili kot oblika dokumentacije vsem drugim, ki se ukvarjajo s tem v prihodnosti."
Z branjem testov boste lažje razumeli funkcionalnost nove funkcije in si ogledali različne primere, ki jih bo uvedla, medtem ko vam analiza testov lahko pomaga ugotoviti manjkajoče primere in poiskati funkcije, ki jih ta PR ne vsebuje. Če v spremembi kode ni nobenih testov in se zdijo ustrezni, je primerno, da jih zahtevate v pregledu.
Toda testi niso vse. "Ne vlivajte preveč vere v sistem, " opozarja Donow. "Samo zato, ker so bili opravljeni testi, ne pomeni, da ni napak."
Prav tako boste morda želeli aplikacijo »zagnati lokalno, da jo funkcionalno preizkusite in se prepričajte, da deluje. Če ne bo šlo, potem ni smisla za nadaljnje preglede, "pravi Ryan Verner, razvijalec programske opreme v podjetju 8th Light. Čeprav nekateri recenzentji ne mislijo, da bi moralo biti ročno testiranje del postopka pregledovanja kode - deloma zaradi potrebnega časa - Verner meni, da je to hiter način za določitev, ali bi morali vložiti več časa v pregled in strategijo za zmanjšanje. rast zaostankov hroščev.
4. Bodite moštveni igralec
Pri pregledu kode kliše dobi nov pomen. "Vzemite si čas za pregled, ker gre za kode za vsakogar, " pravi Verner, ki se zavzema za občutek "kolektivnega lastništva". Vi kot recenzent bi si morali prizadevati za zaščito večjih zaostankov hroščev, da bi dali svoj ekipa manj dela na poti.
Pillai uporablja gifs za proslavo odobrenih PR-jev in so jih pripravljeni na združitev.
Hkrati Charles Luxton, tehnološki vodja pri The Muse, spodbuja recenzenta, da razume in si zapomni prednostne naloge ekipe. S hitro bližajočimi se roki in nesoglasji je veliko, včasih ustvarite opravilo za zaostanke, ki zagotavljajo izboljšave v prihodnosti, pri čemer dodate komentar k zadevni kodi, medtem je Band-Aid, ki ga potrebujete, da naj bo vaša ekipa srečna.
In končno, če se vprašate, ali bi bila koda smiselna za nekoga, ki se je pravkar pridružil skupini in jo je bral v prvih nekaj tednih, vam bo pomagalo, da bo vaša koda berljiva in razumljiva.
5. Uporabite postopek za učenje in izmenjavo znanja
Postopek pregleda vsem vključenim omogoči boljši vpogled v zbirko podatkov, jezike, okvire in najboljše prakse.
Matt Jeffery, tehnični vodja pri The Muse, svetuje recenzentu, naj "arhitekturno razume spremembe. Eden od načinov je branje imen datotek, saj pomagajo dati kontekst. Če na primer gledate na spremembo plasti dostopa do podatkov veste, da se ne ukvarjate s poslovno logiko ali uporabniškim vmesnikom. "
Za izmenjavo dokumentacije lahko uporabite PR komentar na GitHub.
Ko se učite iz sprememb kode, imate tudi možnost izmenjave znanj. "Najbolje je, da svoje mnenje razložite in podkrepite z dokumentacijo, " pravi Luxton. Povezave, ki jih navedete v podporo dokazom in zanesljivih člankov, ne samo pomagajo recenzentu in piscu kode pri iskanju različnih pristopov, ko se dokončno odločijo, temveč tudi okrepijo svoje znanje programiranja.
Medtem ko upoštevate te nasvete, ne pozabite, da je pregled čas, da uresničite svoje sposobnosti. "Dajte ljudem koristi od dvoma, da so razmišljali o njihovem pristopu, in opozorite na različne možnosti, medtem ko poskušajo razbliniti obrambo, " pravi Rudder. "Komentarje puščam povsod in končni komentar - tukaj je, kaj je super, tukaj je, kaj je mogoče izboljšati, tukaj je treba spremeniti, preden se združite."
S takšnim pristopom ne samo da boste zaščitili svojo kodno bazo pred tehnološkim dolgom, varnostnimi grožnjami in napakami, ampak boste tudi gradili svojo ekipo.
