Ca inginer software junior, am perceput întotdeauna comentarii de recenzie a codurilor primite pentru a învăța cum să devin un coder mai bun. Dar când a venit momentul să încerc prima mea revizuire de coduri, mi-am dat seama că experiența mea nu mă pregătise să fiu de cealaltă parte.
Am dezvoltat un caz sever de sindrom impostor, în spirală în jos cu întrebări: Ar trebui să comentez această linie de cod sau nu merită? Ar trebui să găsesc articole care să susțină fiecare comentariu? Voi bloca site-ul aprobând acest lucru? Mă vor urî? Bine, recunosc că am spiralat destul de repede. Dar după ce am vorbit cu unii colaboratori, am știut că nu sunt singur în grijile mele.
Inginerii de software junior pot fi aruncați în recenzii de cod cu o ipoteză similară „știți cum să citiți o carte, astfel încât să știți cum să scrieți o carte, ceea ce nu este adevărat”, spune Jessica Rudder, inginer de experiență la GitHub.
Există așteptări care vin odată cu revizuirea codului, iar procesul poate fi îngrijorat de nervi. Așa că am intervievat alți șapte ingineri software pentru a colecta sfaturi despre cum să construiești o mentalitate de recenzie.
1. Gândiți-vă la impactul general
În general, o solicitare bună de tragere (PR) ar trebui să afecteze doar o parte restrânsă a bazei de cod. Cu toate acestea, domeniul limitat nu ar trebui să vă împiedice să vă gândiți la schimbarea codului în contextul bazei de cod mai mari.
Nigel Munoz, fost inginer full-stack la The Muse și actual inginer software independent, încurajează recenzorul să se gândească la „modul în care această schimbare afectează imaginea mai mare și mai mică.” Având în vedere că imaginea mai mare include găsirea oricărei datorii tehnice - căutați cod care este repetat, nemodular sau nu respectă cele mai recente convenții standard - precum și analiza modificărilor arhitecturii bazei de cod.
Sam Donow, un dezvoltator de bază la Hudson River Trading, consideră că „nu există nimic prea mare sau prea mic pentru a comenta. Sugestiile pentru îmbunătățiri mici ar putea duce la îmbunătățiri mai mari în mai multe părți ale bazei de cod. "
Puteți utiliza un comentariu de PR despre GitHub pentru a oferi feedback pozitiv, precum și pentru a indica unde codul poate diferi de convențiile standard ale cadrului React.
De exemplu, în timpul unuia din propriile recenzii de coduri, am primit un comentariu potrivit căruia anumite proprietăți ale unei componente React sunt confuze, ceea ce a stârnit întrebări mai largi despre modul în care componenta era folosită. În cele din urmă, am eliminat proprietățile din componenta inițială și am creat o componentă separată pentru a clarifica comportamentul fiecăruia și pentru a mă asigura că ambele pot fi utilizate în mai multe locuri.
2. Luați în considerare securitatea
Nu uitați că unele modificări ar putea afecta mai mult decât doar baza de coduri. Rudder recomandă evaluarea dacă un utilizator „ar putea folosi această funcționalitate pentru a hărțui pe cineva sau ar putea abuza de sistem.” De exemplu, dacă noua caracteristică din cererea de tragere include intrarea utilizatorului, căutați injecția SQL, accesul la date, scripturile cross-site și alte vulnerabilități de securitate.
3. Concentrați-vă asupra erorilor
Colaboratorii dvs. de cod - indiferent cât de robotici ar părea - sunt oameni, iar oamenii pot rupe sau uita funcționalitățile. Așadar, asigurați-vă că „revizuiți testele cu aceeași importanță ca și restul codului”, recomandă Abhishek Pillai, un lider tehnic la cadrele didactice Pay Pay. „Vor preveni noile erori și vor servi drept formă de documentare pentru oricine altcineva care lucrează la acest lucru în viitor.”
Citirea testelor vă poate ajuta să înțelegeți funcționalitatea unei noi caracteristici și să vedeți diferitele cazuri pe care le va introduce, în timp ce analiza testelor vă poate ajuta să evidențiați cazuri lipsă și să găsiți funcții care nu sunt conținute în acest PR. Dacă nu există teste incluse în modificarea codului și par relevante, este necesar să le solicitați în cadrul revizuirii.
Dar testele nu sunt totul. „Nu puneți prea multă credință în sistem”, avertizează Donow. „Doar pentru că testele au fost difuzate nu înseamnă că nu există erori.”
De asemenea, poate doriți să „rulați aplicația local pentru a o testa funcțional și pentru a vă asigura că funcționează. Dacă nu funcționează, atunci nu are rost să revizuim în continuare ”, spune Ryan Verner, dezvoltator de software la 8th Light. Deși unii recenzori nu cred că testarea manuală ar trebui să facă parte din procesul de revizuire a codului - în parte din cauza timpului necesar - Verner consideră că este o modalitate rapidă de a determina dacă ar trebui să investești mai mult timp în revizuire, precum și o strategie care să ajute la reducerea. creșterea unui backlog de buguri.
4. Fii jucător de echipă
Cliseul capătă un sens nou atunci când vine vorba de revizuirea codului. „Luați-vă timp să revizuiți, deoarece este baza de cod a tuturor”, spune Verner, care susține un sentiment de „proprietate colectivă”. Tu, în calitate de recenzor, ar trebui să lucrezi pentru a proteja întârzierea erorilor să crească, cu scopul de a-ți oferi echipa mai puțin lucrează în linie.
Pillai folosește gif-uri pentru a sărbători PR-urile aprobate și gata de contopire ale coechipierilor săi.
În același timp, Charles Luxton, conducător tehnologic al The Muse, încurajează recenzorul să înțeleagă și să își amintească prioritățile echipei. Având în vedere că termenele și dezacordurile se apropie rapid, uneori se creează un articol de făcut pentru întârzierea care asigură îmbunătățiri în viitor și se pune în timp un comentariu la codul în cauză. mentine-ti echipa fericita.
În cele din urmă, să vă întrebați dacă codul ar avea sens pentru cineva care tocmai s-a alăturat echipei și a fost citit în primele săptămâni ale lor, vă va ajuta să mențineți codul dvs. lizibil și inteligibil.
5. Folosiți Procesul pentru învățare și schimbul de cunoștințe
Procesul de revizuire oferă tuturor celor implicați un loc în care să poată avea mai multe informații despre baza de cod, limbile, cadrele și cele mai bune practici.
Matt Jeffery, conducător tehnologic al The Muse, sfătuiește recenzorul să "înțeleagă schimbările arhitectural. O modalitate este să citești numele fișierelor, deoarece acestea ajută la crearea contextului. De exemplu, dacă te uiți la o modificare a nivelului de acces la date. știi că nu ai de-a face cu logica de afaceri sau cu IU. "
Puteți utiliza un comentariu de PR despre GitHub pentru a partaja documentația.
Când înveți din modificările de cod, ai și posibilitatea de a împărtăși cunoștințe. „Cel mai bine este să-ți explici părerea și să o dai cu documentație”, spune Luxton. Linkurile pe care le furnizați pentru susținerea dovezilor și articolelor de încredere nu numai că ajută recenzorul și scriitorul de cod să exploreze abordări diferite, deoarece iau o decizie finală, ci și le consolidează cunoștințele de programare.
În timp ce țineți cont de aceste sfaturi, nu uitați că revizuirea este un moment pentru a vă exersa abilitățile oamenilor. „Oferă oamenilor beneficiul de îndoiala că s-au gândit la abordarea lor și evidențiază posibilități diferite în timp ce încearcă să risipească defensivitatea”, spune Rudder. "Las comentariile în întregime și un comentariu complet - iată ce este grozav, iată ce poate fi îmbunătățit, iată ce trebuie schimbat înainte de contopire."
Cu acest tip de abordare, nu numai că vă veți proteja baza de cod de datoriile tehnologice, amenințările de securitate și bug-uri, dar vă veți construi echipa.
