Aduceți o mentalitate sănătoasă de revizuire a codului echipei dvs

O „revizuire a codului” este un moment al procesului de dezvoltare în care tu (ca dezvoltator) și colegii tăi lucrezi împreună și cauți erori într-un fragment recent de cod înainte de a fi lansat. Într-un astfel de moment, poți fi fie autorul codului, fie unul dintre recenzori.

Când faceți o revizuire a codului, este posibil să nu fiți sigur de ceea ce căutați. Pe de altă parte, atunci când trimiteți o revizuire a codului, este posibil să nu știți ce să așteptați. Această lipsă de empatie și așteptări greșite între cele două părți pot declanșa situații nefericite și pot grăbi procesul până se termină într-o experiență neplăcută pentru ambele părți.

În acest articol, voi împărtăși modul în care acest rezultat poate fi schimbat prin schimbarea mentalității în timpul unei revizuiri a codului:

• Ca o echipa
• Ca autor
• Ca recenzent

Lucrul în echipă

Promovați o cultură a colaborării

Înainte de a începe, este fundamental să înțelegem valoarea de ce trebuie revizuit codul. Partajarea cunoștințelor și coeziunea echipei sunt benefice pentru toată lumea, totuși, dacă se face cu o mentalitate slabă, o revizuire a codului poate fi un consumator mare de timp, cu rezultate neplăcute.

Atitudinea și comportamentul echipei ar trebui să îmbrățișeze valoarea unei colaborări fără judecăți, cu scopul comun de a învăța și de a împărtăși – indiferent de experiența altcuiva.

Includeți recenzii de cod în estimările dvs

O revizuire completă a codului necesită timp. Dacă o modificare a durat o săptămână, nu vă așteptați ca revizuirea codului să dureze mai puțin de o zi. Pur și simplu nu funcționează așa. Nu încercați să grăbiți o revizuire a codului și nici să o priviți ca pe un blocaj.

Recenziile codului sunt la fel de importante ca și scrierea codului propriu-zis. Ca echipă, nu uitați să includeți recenzii de cod în fluxul dvs. de lucru și să setați așteptări cu privire la cât timp ar putea dura o revizuire a codului, astfel încât toată lumea să fie sincronizată și încrezătoare în munca lor.

Economisiți timp cu linii directoare și automatizare

O modalitate eficientă de a garanta contribuții consistente este integrarea unui șablon Pull Request în proiect. Acest lucru îl va ajuta pe autor să trimită un PR sănătos, cu o descriere completă. O descriere PR ar trebui să explice care este scopul schimbării, motivul din spatele acesteia și cum să o reproducă. Capturile de ecran și link-urile de referință (problemă Git, fișier de design și așa mai departe) sunt ultimele atingeri pentru o trimitere auto-explicativă.

Făcând toate acestea, veți împiedica comentariile timpurii din partea recenzenților care vor solicita mai multe detalii. Un alt mod de a face ca recenziile de cod să pară mai puțin captivante este să utilizați linters pentru a găsi probleme de formatare a codului și de calitate a codului înainte ca un examinator să se implice. Ori de câte ori vedeți un comentariu repetitiv în timpul procesului de revizuire, căutați modalități de a-l minimiza (fiind cu linii directoare mai bune sau automatizare a codului).

Rămâi Student

Oricine poate face o revizuire a codului și toată lumea trebuie să primească o revizuire a codului, indiferent de nivelul de vechime. Primiți orice feedback cu recunoștință ca o oportunitate de a învăța și de a împărtăși cunoștințele. Privește orice feedback ca o discuție deschisă , mai degrabă decât o reacție defensivă. După cum spune Ryan Holiday:

„Un amator este defensiv. Profesionistului consideră că învățarea (și chiar, ocazional, prezentarea) este plăcută; le place să fie provocați și umiliți și se angajează în educație ca un proces continuu și nesfârșit. (...)”

— Ryan Holiday, Ego-ul este inamicul

Rămâi umil pentru că în clipa în care încetezi să mai fii student, cunoștințele tale devin fragile.

Arta de a selecta recenzenții

În opinia mea, alegerea recenzenților este una dintre cele mai importante decizii pentru o revizuire eficientă și sănătoasă a codului ca o echipă.

Să presupunem că colegul dvs. trimite o revizuire a codului și decide să eticheteze „toată lumea”, deoarece, în mod inconștient, ar putea dori să accelereze procesul, să livreze cel mai bun cod posibil sau să se asigure că toată lumea știe despre modificarea codului. Fiecare dintre evaluatori primește o notificare, apoi deschide linkul PR și vede o mulțime de persoane etichetate ca recenzori. Gândul că „altul o va face” le apare în minte, ceea ce duce la ignorarea revizuirii codului și la închiderea linkului.

Deoarece nimeni nu a început încă revizuirea, colegul tău va reaminti fiecăruia dintre evaluatori să o facă, adică creând presiune asupra lor. Odată ce recenzenții încep să o facă, procesul de revizuire durează o veșnicie pentru că fiecare are propria părere și este un coșmar să ajungi la un acord comun. Între timp, oricine a decis să nu revizuiască codul, este apoi trimis spam cu miliarde de notificări prin e-mail cu toate comentariile de revizuire, creând astfel zgomot în productivitatea lor.

Acesta este ceva ce văd că se întâmplă mai mult decât mi-aș dori: solicitări de tragere cu o grămadă de persoane etichetate ca evaluatori și care se termină, în mod ironic, într-o revizuire a codului neproductivă.

Există câteva fluxuri eficiente comune atunci când selectați recenzenții: Un posibil flux este să alegeți doi până la trei colegi care sunt familiarizați cu codul și să le cereți să fie recenzori. O altă abordare, explicată de echipa Gitlab este de a avea un flux de recenzii înlănțuit în care autorul alege un recenzent care alege un alt evaluator până când cel puțin doi recenzenti sunt de acord cu codul. Indiferent de fluxul pe care îl alegeți, evitați să aveți prea mulți recenzenți . A fi capabil să ai încredere în judecata codului colegilor tăi este cheia pentru a efectua o revizuire eficientă și sănătoasă a codului.

Ai empatie

Identificarea unor fragmente de cod care trebuie îmbunătățite este doar o parte a unei revizuiri de succes a codului. La fel de important este să comunici acel feedback într-un mod sănătos, arătând empatie față de colegii tăi.

Înainte de a scrie un comentariu, nu uitați să vă puneți în locul celorlalți. Este ușor să fii înțeles greșit când scrii, așa că revizuiește-ți propriile cuvinte înainte de a le trimite. Chiar dacă o conversație începe să fie urâtă, nu lăsați-o să vă afecteze - rămâneți întotdeauna respectuos. A vorbi bine altora nu este niciodată o decizie proastă.

Aflați cum să faceți compromisuri

Când o discuție nu este rezolvată rapid, du-o la un apel personal sau la un chat. Analizați împreună dacă este un subiect care merită să paralizeze cererea de modificare actuală sau dacă poate fi abordat în altul.

Fiți flexibili, dar pragmatici și știți cum să echilibrați eficiența (livrarea) și eficacitatea (calitate). Este un compromis de făcut ca o echipă. În aceste momente îmi place să mă gândesc la o revizuire a codului mai degrabă ca la o iterație decât la o soluție finală. Există întotdeauna loc de îmbunătățire în runda următoare.

Evaluări personale ale codului

Adunarea autorului și a recenzentului împreună într-un stil de programare în pereche poate fi foarte eficientă. Personal, prefer această abordare atunci când revizuirea codului implică schimbări complexe sau există o oportunitate pentru o cantitate mare de schimb de cunoștințe. În ciuda faptului că aceasta este o revizuire a codului offline, este un obicei bun să lăsați comentarii online despre discuțiile purtate, mai ales când trebuie făcute modificări după întâlnire. Acest lucru este, de asemenea, util pentru a menține la zi alți recenzenți online.

Învățați din rezultatele revizuirii codului

Când o revizuire a codului a suferit multe modificări, a durat prea mult sau a avut deja prea multe discuții, adună-ți echipa și analizează cauzele și ce acțiuni pot fi luate din aceasta. Când revizuirea codului este complexă, împărțirea unei sarcini viitoare în sarcini mai mici facilitează fiecare revizuire a codului.

Când decalajul de experiență este mare, adoptarea programării în pereche este o strategie cu rezultate incredibile - nu numai pentru partajarea cunoștințelor, ci și pentru colaborarea și comunicarea off-line. Oricare ar fi rezultatul, urmăriți întotdeauna o echipă dinamică sănătoasă, cu așteptări clare.

Ca Autor

Una dintre principalele preocupări atunci când lucrați la o revizuire a codului în calitate de autor este de a minimiza surpriza recenzentului când citește codul pentru prima dată. Acesta este primul pas către o revizuire a codului previzibilă și fără probleme. Iată cum o poți face.

Stabiliți o comunicare timpurie

Nu este niciodată o idee rea să discutați cu viitorii dvs. recenzenți înainte de a codifica prea mult. Ori de câte ori este o contribuție internă sau externă, puteți face o rafinare împreună sau un pic de programare în pereche la începutul dezvoltării pentru a discuta soluții.

Nu este nimic greșit în a cere ajutor ca prim pas. De fapt, lucrul împreună în afara revizuirii este un prim pas important pentru a preveni greșelile timpurii și pentru a garanta un acord inițial. În același timp, recenzenții tăi sunt la curent cu o viitoare revizuire a codului care urmează să fie făcută.

Urmați Ghidurile

Când trimiteți o cerere de tragere pentru a fi revizuită, nu uitați să adăugați o descriere și să urmați instrucțiunile. Acest lucru îi va scuti pe evaluatori de a petrece timp pentru a înțelege contextul noului cod. Chiar dacă recenzenții dvs. știu deja despre ce este vorba, puteți profita de această oportunitate ca o modalitate de a vă îmbunătăți abilitățile de scriere și comunicare.

Fii primul tău evaluator

Vederea propriului cod într-un context diferit vă permite să găsiți lucruri pe care le-ați rata în editorul de cod. Efectuați o revizuire a codului propriului cod înainte de a vă întreba colegii. Aveți o mentalitate de recenzent și treceți cu adevărat prin fiecare linie de cod.

Personal, îmi place să adnotez propriile mele recenzii de cod pentru a-mi ghida mai bine recenzenții. Scopul aici este de a preveni comentariile legate de o posibilă lipsă de atenție și de a vă asigura că ați respectat instrucțiunile de contribuție. Încercați să trimiteți o revizuire a codului așa cum doriți să primiți una.

Fii răbdător

După ce ați trimis o examinare a codului, nu treceți direct într-un nou mesaj privat prin care le cere recenzenților să „arută o privire, durează doar câteva minute” și, indirect, dorește după acel emoji cu degetul mare în sus. Încercarea de a-ți grăbi colegii să-și facă treaba nu este o mentalitate sănătoasă. În schimb, aveți încredere în fluxul de lucru al colegilor dvs., deoarece aceștia au încredere în dvs. pentru a trimite o evaluare bună a codului. Între timp, așteptați să vă răspundă când sunt disponibile. Nu vă priviți recenzenții ca pe un blocaj. Amintiți-vă să aveți răbdare pentru că lucrurile grele necesită timp.

Fii un ascultător

Odată ce o revizuire a codului este trimisă, vor veni comentarii, vor fi adresate întrebări și vor fi propuse modificări. Regula de aur aici este să nu luați niciun feedback ca pe un atac personal. Amintiți-vă că orice cod poate beneficia din perspectivă externă .

Nu vă priviți recenzenții ca pe un inamic. În schimb, profită de acest moment pentru a-ți lăsa ego-ul deoparte, accepta că faci greșeli și fii deschis să înveți de la colegii tăi, astfel încât să poți face o treabă mai bună data viitoare.

Ca recenzent

Planificați înaintea timpului dvs

Când vi se cere să fiți recenzent, nu întrerupeți lucrurile imediat. Este o greșeală comună pe care o văd tot timpul. Revizuirea codului necesită toată atenția dvs. și de fiecare dată când schimbați contextul codului, vă scădeți productivitatea pierzând timpul în recalibrarea concentrației. În schimb, planificați din timp alocați intervale de timp ale zilei pentru a face recenzii de cod.

Personal, prefer să fac recenzii de cod la prima oră dimineața sau după prânz, înainte de a-mi alege alte sarcini. Acesta este ceea ce funcționează cel mai bine pentru mine, deoarece creierul meu este încă proaspăt, fără un context de cod anterior din care să se dezactiveze. Pe lângă asta, odată ce am terminat cu revizuirea, mă pot concentra pe propriile sarcini, în timp ce autorul poate reevalua codul pe baza feedback-ului.

Fii susținător

Când o solicitare de tragere nu respectă regulile de contribuție, sprijiniți-vă, în special noilor veniți. Luați acel moment ca pe o oportunitate de a-l ghida pe autor pentru a-și îmbunătăți contribuția. Între timp, încercați să înțelegeți de ce autorul nu a urmat instrucțiunile în primul rând. Poate că există loc de îmbunătățire de care nu erai conștient înainte.

Verificați sucursala și rulați-o

În timp ce revizuiți codul, faceți-l să ruleze pe propriul computer - mai ales când implică interfețe cu utilizatorul. Acest obicei vă va ajuta să înțelegeți mai bine noul cod și să identificați lucrurile pe care le-ați putea rata dacă tocmai ați folosit un instrument de diff implicit în browser, care vă limitează domeniul de examinare la codul modificat (fără a avea contextul complet ca în editorul de cod) .

Întrebați înainte de a presupune

Când nu înțelegi ceva, nu-ți fie teamă să-l spui și să pui întrebări. Când întrebați, amintiți-vă să citiți mai întâi codul din jur și să evitați să faceți presupuneri.

Majoritatea întrebărilor se încadrează în aceste două tipuri de categorii:

1. Întrebări „Cum”.
   Când nu înțelegeți cum funcționează ceva sau ce face, evaluați împreună cu autorul dacă codul este suficient de clar. Nu confunda codul simplu cu ignoranța. Există o diferență între codul care este greu de citit și codul de care nu știți. Fiți deschis să învățați și să utilizați o nouă funcție de limbă, chiar dacă nu o cunoașteți încă profund. Cu toate acestea, utilizați-l numai dacă simplifică baza de cod.
2. Întrebări „De ce”.
   Când nu înțelegeți „de ce”, nu vă fie teamă să sugerați să comentați codul, mai ales dacă este un caz limită sau o remediere a erorilor. Codul ar trebui să se explice de la sine atunci când vine vorba de explicarea a ceea ce face. Comentariile sunt o completare pentru a explica de ce din spatele unei anumite abordări. Explicarea contextului este foarte valoroasă atunci când vine vorba de mentenanță și va salva pe cineva de la ștergerea unui bloc de cod despre care credea că este inutil. (Personal, îmi place să comentez codul până când mă simt în siguranță că îl uit mai târziu.)

Critica constructiva

Odată ce găsiți o bucată de cod despre care credeți că ar trebui îmbunătățită, amintiți-vă întotdeauna să recunoașteți efortul autorului de a contribui la proiect și să vă exprimați într-un mod receptiv și transparent.

• Discuții deschise.
  Evitați să vă oficializați feedbackul ca o comandă sau o acuzație, cum ar fi „Ar trebui să...” sau „Ați uitat...”. Exprimați-vă feedbackul ca o discuție deschisă în loc de o solicitare obligatorie. Nu uitați să comentați codul, nu autorul. Dacă comentariul nu este despre cod, atunci nu ar trebui să aparțină unei revizuiri a codului. După cum s-a spus mai devreme, sprijiniți-vă. Folosirea unei voci pasive, vorbirea la plural, exprimarea întrebărilor sau sugestiilor sunt abordări bune pentru a sublinia empatia cu autorul.
  

În loc de „Extrageți această metodă de aici...” preferați „Această metodă ar trebui extrasă...” sau „Ce părere aveți despre extragerea acestei metode...”

• Fii clar.
  Un feedback poate fi interpretat greșit cu ușurință, mai ales când vine vorba de exprimarea unei opinii versus împărtășirea unui fapt sau a unui ghid. Amintiți-vă întotdeauna să ștergeți acest lucru imediat în comentariul dvs.

Neclar: „Acest cod ar trebui să fie….”

Opinie: „Cred că acest cod ar trebui să fie...”

Fapt: „Urmând [orientările noastre], acest cod ar trebui să fie…”.

• Explică de ce.
  Ceea ce este evident pentru tine, s-ar putea să nu fie pentru alții. Nu este niciodată prea mult să explici motivația din spatele feedback-ului tău, astfel încât autorul nu numai că înțelege cum să schimbi ceva, ci și care este beneficiul din acesta.

Opinie: „Cred că acest cod ar putea fi...”

A explicat: „Cred că acest cod ar putea fi (...) deoarece acest lucru va îmbunătăți lizibilitatea și va simplifica testele unitare.”

• Dați exemple.
  Când partajați o caracteristică de cod sau un model cu care autorul nu este familiarizat, completați sugestia dvs. cu o referință ca ghid. Când este posibil, treceți dincolo de documentele MDN și partajați un fragment sau un exemplu de lucru adaptat scenariului de cod curent. Când scrierea unui exemplu este prea complexă, sprijiniți -vă și oferiți-vă ajutor personal sau printr-un apel video.

Pe lângă faptul că spuneți ceva precum „Folosirea filtrului ne va ajuta să [motivați]”, spuneți și „În acest caz, ar putea fi ceva de genul: [fragment de cod]. Puteți verifica [un exemplu la Finder.js]. Orice îndoială, nu ezitați să-mi trimiteți un ping pe Slack.”

• Fii rezonabil.
  Dacă aceeași eroare este făcută de mai multe ori, preferați să lăsați doar un comentariu despre ea și amintiți-vă că autorul să o revizuiască și în alte locuri. Adăugarea de comentarii redundante creează doar zgomot și ar putea fi contraproductivă.

Păstrați focalizarea

Evitați să propuneți modificări de cod care nu au legătură cu codul actual. Înainte de a sugera o schimbare, întreabă-te dacă este strict necesar în acel moment. Acest tip de feedback este obișnuit în special în refactori. Este unul dintre multele compromisuri între eficiență și eficacitate pe care trebuie să le facem ca o echipă.

Când vine vorba de refactor, personal, tind să prefer îmbunătățiri mici, dar eficiente . Acestea sunt mai ușor de revizuit și există mai puține șanse de a avea conflicte de cod atunci când actualizați ramura cu ramura țintă.

Stabiliți așteptări

Dacă lăsați o revizuire a codului pe jumătate, anunțați autorul despre ea, astfel încât așteptările de timp să fie sub control. În cele din urmă, anunțați și autorul dacă sunteți de acord cu noul cod sau dacă doriți să-l revizuiți din nou mai târziu.

Înainte de a aproba o revizuire a codului, întrebați-vă dacă sunteți confortabil cu privire la posibilitatea de a atinge acel cod în viitor. Dacă da, acesta este un semn că ați făcut o revizuire reușită a codului!

Învață să refuzi o revizuire a codului

Deși nimeni nu recunoaște acest lucru, uneori trebuie să refuzi o revizuire a codului. În momentul în care decideți să acceptați o revizuire a codului, dar încercați să o grăbiți, calitatea proiectului este compromisă, precum și mentalitatea echipei dvs.

Când acceptați să revizuiți codul altcuiva, acea persoană are încredere în capacitățile dvs. - este un angajament. Dacă nu aveți timp să fiți recenzent, spuneți nu colegilor dvs. Vorbesc serios; nu-i lăsa pe colegi să aștepte o revizuire a codului care nu se va face niciodată. Nu uitați să comunicați și să păstrați clar așteptările . Fii sincer cu echipa ta și – chiar mai bine – cu tine însuți. Oricare ar fi alegerea ta, fă-o sănătos și fă-o corect.

Concluzie

Având suficient timp și experiență, efectuarea recenziilor de cod vă va învăța mult mai mult decât doar cunoștințe tehnice. Veți învăța să oferiți și să primiți feedback de la alții, precum și să luați decizii cu mai multă atenție.

Fiecare revizuire a codului este o oportunitate de a crește ca comunitate și individual. Chiar și în afara recenziilor codurilor, nu uitați să promovați o mentalitate sănătoasă până în ziua în care va veni firesc pentru dvs. și pentru colegii dvs. Pentru că împărtășirea este ceea ce ne face mai buni!

Citiți suplimentare despre SmashingMag:

• Lucrând împreună: Cum pot comunica designerii și dezvoltatorii pentru a crea proiecte mai bune
• O mai bună colaborare prin introducerea designerilor în procesul de revizuire a codului
• Ce podcasturi ar trebui să asculte designerii și dezvoltatorii web?
• Cum să creați CV-ul perfect pentru dezvoltator web