Kao mlađi softver inženjer, uvijek sam proučavao komentare pregledavanja koda koje sam dobio kako bih naučio kako postati bolji koder. Ali kad je došlo vrijeme da pokušam pregledati svoj prvi kôd, shvatio sam da me to iskustvo nije pripremilo da budem s druge strane.
Razvio sam težak slučaj implantacijskog sindroma, spiralizirajući se prema dolje s pitanjima: Trebam li komentirati ovu liniju koda ili ne vrijedi? Trebam li naći članke kojima bih podržao svaki komentar? Hoću li srušiti web mjesto tako što ću to odobriti? Hoće li me mrziti? Ok, priznajem da se vrlo brzo spiraliram. Ali nakon razgovora s nekim kolegama, znao sam da nisam sam u brizi.
Mlađi softverski inženjeri mogu biti ubačeni u pregled koda uz pretpostavku analognu "znate kako čitati knjigu pa znate kako napisati knjigu, što nije istina", kaže Jessica Rudder, inženjerka iskustva u GitHubu.
Postoje očekivanja koja dolaze s pregledom koda, a postupak može biti nervozan. Tako sam intervjuirao sedam drugih softverskih inženjera kako bih prikupio savjete o tome kako izraditi mišljenje mišljenja.
1. Razmislite o ukupnom utjecaju
Općenito, dobar zahtjev za povlačenjem (PR) trebao bi utjecati samo na ograničeni dio baze podataka. Međutim, ograničeni opseg ne bi vas trebao spriječiti da razmišljate o promjeni koda u kontekstu veće baze podataka.
Nigel Munoz, bivši full-stack inženjer u The Muse i trenutni freelance softverski inženjer, potiče recenzenata na razmišljanje o tome "kako ta promjena utječe na veću i manju sliku." S obzirom na to da veća slika uključuje pronalaženje tehničkog duga - potražite kod koja se ponavlja, nemodularna ili se ne pridržava najnovijih standardnih konvencija - kao i analiza izmjena arhitekture kôdne baze.
Sam Donow, glavni programer u Hudson River Tradingu, smatra da "ne postoji ništa preveliko ili previše malo za komentiranje. Prijedlozi za mala poboljšanja mogli bi dovesti do većih poboljšanja u više dijelova baze podataka. "
Možete koristiti PR komentar na GitHub da pružite pozitivne povratne informacije kao i istaknuti gdje se kôd može razlikovati od standardnih konvencija okvira React.
Na primjer, tijekom jednog od mojih vlastitih pregleda kodova, primio sam komentar da su određena svojstva na React komponenti zbunjujuća, što je postavilo šire pitanja o tome kako se komponenta koristi. Na kraju sam uklonio svojstva iz izvorne komponente i stvorio zasebnu komponentu da pojasnim ponašanje svakog od njih i osiguram da se oba mogu koristiti na više mjesta.
2. Razmislite o sigurnosti
Ne zaboravite da bi neke promjene mogle utjecati na više nego samo na bazu kodova. Rudder preporučuje procjenu može li korisnik "upotrijebiti ovu funkciju za uznemiravanje nekoga ili može zloupotrijebiti sustav." Na primjer, ako nova značajka u zahtjevu za povlačenje uključuje unos korisnika, potražite SQL injekciju, pristup podacima, skriptiranje na više mjesta i ostale sigurnosne ranjivosti.
3. Usredotočite se na bugove
Vaši suradnici kodova - bez obzira na to koliko robotski oni izgledali - su ljudi, a ljudi mogu slomiti ili zaboraviti funkcije. Stoga osigurajte da "pregledate testove s jednakom važnošću kao i ostatak koda", savjetuje Abhishek Pillai, vodeći tehničar u Teachers Pay Teachers. "Oni će spriječiti nove bugove i poslužiće kao oblik dokumentacije svima koji budu radili na tome u budućnosti."
Čitanje testova može vam pomoći da razumijete funkcionalnost nove značajke i vidite različite slučajeve koje će ih uvesti, dok analiza testova može vam pomoći ukazati na slučajeve koji nedostaju i pronaći značajke koje nisu sadržane u ovom PR-u. Ako u promjeni koda nisu uključeni testovi i oni izgledaju relevantno, prikladno je zatražiti ih u okviru recenzije.
Ali testovi nisu sve. "Nemojte previše vjerovati u sustav", upozorava Donow. "Samo što su izvršeni testovi ne znači da nema pogrešaka."
Također biste trebali pokrenuti aplikaciju lokalno kako biste je funkcionalno testirali i uvjerili se da radi. Ako to ne uspije, nema smisla daljnje pregledavanje ", kaže Ryan Verner, programer softvera u kompaniji 8th Light. Iako neki recenzenti ne misle da bi ručno testiranje trebalo biti dio postupka pregledavanja koda - dijelom i zbog vremena koje je potrebno - Verner vjeruje da je to brz način da se utvrdi treba li uložiti više vremena u pregled, kao i strategiju za pomoć smanjenju rast zaostataka bugova.
4. Budite timski igrač
Klišej poprima novo značenje kada je u pitanju pregled koda. „Odvojite vrijeme za pregled jer je to svačija kodna baza“, kaže Verner, koji se zalaže za osjećaj „kolektivnog vlasništva“. Vi, kao recenzent, trebali biste raditi na zaštiti broja zaostalih grešaka od porasta s ciljem davanja svog tim manje radi na liniji.
Pillai koristi gifove kako bi proslavio PR-ove odobrene i spremne za spajanje svojih suigrača.
U isto vrijeme, Charles Luxton, tehnički voditelj u The Museu, potiče recenzenata na razumijevanje i pamćenje prioriteta tima. Budući da rokovi i nesuglasice koje se brzo približavaju neprestano stvaraju, ponekad, stvaranje zadataka za zaostatke koji osiguravaju poboljšanja u budućnosti, a u međuvremenu se komentira dotični kôd je Band-Aid koji vam je potreban da biste neka vaš tim bude sretan.
I na kraju, pitanje hoće li kôd imati smisla nekome tko se upravo pridružio timu i čita ga tijekom prvih nekoliko tjedana pomoći će da vaš kôd bude čitljiv i razumljiv.
5. Koristite Proces za učenje i dijeljenje znanja
Proces pregleda daje svima koji su uključeni mjesto za bolji uvid u bazu kodova, jezike, okvire i najbolje prakse.
Matt Jeffery, voditelj tehnologije u The Museu, savjetuje recenzentu da "arhitektonsko razumije promjene. Jedan od načina je čitanje imena datoteka jer one pomažu u kontekstu. Na primjer, ako gledate promjenu sloja pristupa podacima znate da se ne bavite poslovnom logikom ili korisničkim sučeljem. "
Možete koristiti PR komentar na GitHub za dijeljenje dokumentacije.
Kad učite iz promjena koda, također imate priliku dijeliti znanje. "Najbolje je objasniti svoje mišljenje i poduprijeti ga dokumentacijom", kaže Luxton. Veze koje pružate u prilog dokazima i pouzdanim člancima ne samo pomažu recenzentu i piscu koda da istraže različite pristupe prilikom donošenja konačne odluke, već i poboljšavaju svoje znanje programiranja.
Iako imajte na umu ove savjete, imajte na umu i da je pregled vrijeme da vježbate svoje ljude. "Dajte ljudima koristi sumnje da su razmišljali o svom pristupu i ukažite na različite mogućnosti dok pokušavaju odagnati odbrambbu", kaže Rudder. "Komentar ostavljam u cijelosti i završni komentar - evo što je sjajno, evo što se može poboljšati, evo što treba promijeniti prije spajanja."
Ovakvim pristupom ne samo da ćete zaštititi bazu kodova od tehničkog duga, sigurnosnih prijetnji i propusta, već ćete i graditi svoj tim.
