Un dezvoltator deschide o cerere de extragere (pull request) care adaugă un calcul de reducere la un serviciu de finalizare a comenzii. Testele sunt satisfăcute, iar diferența este scurtă. Un recenzent o aprobă în două minute cu „LGTM”. Trei luni mai târziu, un coechipier trebuie să modifice aceeași funcție și descoperă că aceasta combină reguli de stabilire a prețurilor, rotunjirea și accesul la baza de date într-un singur loc. Nimeni nu poate spune cu certitudine ce are voie să facă.
Acesta este un scenariu ilustrativ, nu un incident documentat. Arată ce trebuie să producă o evaluare inter pares a codului atunci când funcționează ca o activitate de învățare: un recenzent care poate observa o schimbare plauzibilă, poate identifica problema care nu este încă o eroare și o poate explica într-un mod în care autorul poate acționa.
Acest ghid este destinat liderilor în domeniul responsabil cu ingineria și managerilor de inginerie. Acesta arată cum să proiectați exerciții de revizuire a codului care dezvoltă acea abilitate intenționat, în loc să spere că evaluatorii o vor alege din coadă. Acoperă problema de performanță, lacunele de diagnosticat, cum să structurezi pregătirea și practica, un exemplu practic și cum să verifici dacă abilitatea se poate transfera în recenziile reale. Rugați ingineri seniori să valideze fiecare caz, defect și criteriu înainte de a-l utiliza.
Ce sunt exercițiile de revizuire a codului?
Exercițiile de revizuire a codului sunt sarcini structurate de practică în care un dezvoltator analizează o modificare pregătită, explică ce a descoperit și de ce este importantă și primește feedback cu privire la calitatea acelei explicații. Acestea sunt diferite de analizele pe care echipa dvs. le face în fiecare zi. Modificarea este aleasă în avans, problemele legate de aceasta sunt cunoscute, iar scopul este de a îmbunătăți recenzentul, mai degrabă decât de a expedia modificarea.
Scurte
| Întrebare | Răspuns scurt |
|---|---|
| Care este sarcina? | Explicați concluziile analizei și oferiți feedback pe baza căruia autorul poate acționa. |
| Ce punctaj obții? | Acuratețea constatărilor și cât de utilă este explicația. |
| Este suficientă numărarea defectelor? | Nu. Recenziile sunt despre mai mult decât defecte, așa că un exercițiu care recompensează doar numărul de erori formează un obicei greșit. |
| Care este cererea cognitivă? | Analizați și evaluați un design, apoi creați o sugestie mai bună. |
| Cine validează cazul? | Un manager de inginerie sau un inginer senior care deține baza de cod. |
| Ce nu pot rezolva exercițiile? | Timp de revizuire, proprietate neclară și presiune pentru fuziune rapidă. |
| De unde știi că a funcționat? | O schimbare nouă, nevăzută, revizuită în funcție de criterii convenite, plus o monitorizare a revizuirilor reale. |
1. Descrieți problema de performanță
Începeți cu sarcina, într-o singură propoziție: având în vedere o modificare, recenzorul explică ce a descoperit, de ce este importantă și ce ar putea face autorul în privința acesteia. „Explică” este cuvântul important. A identifica o problemă este jumătate din abilitate. A o spune astfel încât un coleg cu o altă perspectivă să o poată înțelege, să o poată evalua și să acționeze este cealaltă jumătate.
Cercetările privind revizuirea modernă a codului susțin o analiză mai profundă decât simpla căutare de erori. Într-un studiu realizat la Microsoft, Bacchelli și Bird au observat, intervievat și chestionat dezvoltatori și manageri. Aceștia au descoperit că găsirea defectelor era în continuare principala motivație pentru revizuire, dar că revizuirile se concentrau mai puțin pe defecte decât se așteptau oamenii. De asemenea, acestea au adus și alte beneficii, cum ar fi partajarea cunoștințelor, conștientizarea echipei și soluții alternative, iar cercetătorii au descris înțelegerea codului și a schimbărilor ca aspect cheie al revizuirii (Bacchelli și Bird, ICSE 2013Este un studiu al echipelor unei companii, așa că folosește-l ca motiv pentru a proiecta pentru înțelegere, nu ca o rată pentru a ta.
Standardul de evaluare publicat de Google indică același lucru. Acesta le spune recenzorilor să favorizeze aprobarea unei modificări odată ce aceasta îmbunătățește cu siguranță starea generală a codului, chiar dacă acesta nu este perfect, și precizează că evaluarea poate învăța dezvoltatorii ceva nou, așa că comentariile care ajută pe cineva să învețe sunt binevenite (Practici de inginerie GoogleAmbele surse descriu revizuirea ca un loc în care se exercită și se emite judecata. Asta ar trebui să repete exercițiile tale.
2. Diagnosticați lacunele de învățare și context
Comparați sarcina cu ceea ce exersează și evaluează programul dumneavoastră actual.
- Practica actuală folosește sarcina reală? Dacă noii recenzori învață citind un ghid de stil și apoi revizuind solicitări de extragere în timp real, ei exersează pe o lucrare reală, fără a avea un loc sigur în care să greșească. Dacă evaluarea este un test despre eticheta de evaluare, ea măsoară amintirea regulilor, nu capacitatea de a le aplica la o modificare.
- Care este cererea cognitivă? În taxonomia Bloom revizuită, evaluarea solidității unui design și evaluarea compromisurilor aferente se află la nivelurile de analiză și evaluare, iar propunerea unei structuri mai bune ajunge la nivelul de creare. Dacă exercițiile tale se întreabă doar „ce face acest cod?”, ele se opresc la înțelegere. Ghidul nostru pentru potrivirea activităților de învățare cu taxonomia lui Bloom arată cum se potrivește activitatea cu nivelul.
- Oare altceva în afară de abilitate intervine în cale? Verificați timpul de revizuire, instrumentele, responsabilitatea și normele echipei. Dacă recenzorii au la dispoziție cinci minute pentru fiecare solicitare de extragere, niciun exercițiu nu va produce o explicație atentă. Dacă autorii consideră fiecare comentariu drept critică, recenzorii își vor atenua concluziile până când nu vor mai spune nimic. Raportați aceste cauze persoanelor care le pot remedia.
3. Pregătirea, practica și feedback-ul designului
Acordă fiecărei etape o sarcină separată.
Pregătirea. Verificați ce au nevoie recenzorii înainte de a începe: lista de verificare a echipei, principiile de proiectare pe care se bazează și cum să citiți o diferență în instrumentele dvs. Păstrați această verificare concisă și în ritmul propriu. O verificare de rechemare confirmă doar cerințele preliminare și nu este o dovadă că cineva poate revizui.
Practică. Folosește modificări pregătite cu un număr mic de probleme inițiale de diferite tipuri: o eroare de corectitudine, o problemă de mentenanță, cum ar fi responsabilitățile mixte din exemplul inițial, un nume neclar sau un test lipsă și niște cod care este în regulă. Roagă recenzorul să scrie comentariul pe care l-ar lăsa, să clasifice problemele și să spună ce informații suplimentare ar dori. Lecția practică a CodeRefinery arată forma: oamenii deschid o cerere de extragere care conține o mică greșeală de scriere și o greșeală mai mare, apoi o revizuiesc împreună cu un coleg (CodeRefinery, Practicarea revizuirii codului). Construiește-ți codul din propria bază de cod, astfel încât convențiile și compromisurile să fie reale.
Parere. Leagă-l de deciziile luate de recenzent. „Ai observat problema rotunjirii, dar comentariul tău a spus «asta pare greșit» fără a specifica ce intrare o încalcă” este mai util decât „am găsit 2 din 4”.
Intrare în timp real sau revizuire asincronă? Comentariile transmise în timp real adaugă cea mai mare valoare atunci când o problemă este ambiguă, iar evaluatorii învață ascultând un inginer senior spunând de ce ar ridica-o sau ar lăsa-o baltă. Revizuirea asincronă este suficientă pentru a compara comentariile cu o recenzie adnotată a unui expert.
4. Lucrează printr-un exemplu realist
Ilustrativ. Un manager de inginerie ar trebui să valideze cazul și criteriile de răspuns înainte de utilizare.
Cazul. O modificare adaugă un calcul de reducere la un serviciu de finalizare a comenzii. Aceasta trece testele. Într-o funcție, aplică reduceri procentuale și fixe, rotunjește rezultatul, scrie în baza de date și trimite un eveniment. Are un singur test, pentru o singură reducere procentuală.
Sarcina. Recenzentul notează comentariile pe care le-ar lăsa, le clasifică preocupările și spune ce ar trebui să știe înainte de a aproba.
O primă încercare. „Pare în regulă, testul trece. Poate fi împărțit în două?” Recenzentul a observat ceva, dar nu a spus ce anume, de ce este important sau ce trebuie făcut. Autorul nu poate acționa în acest sens.
Feedback și reîncercare. Facilitatorul întreabă: ce ar risca să afecteze o modificare viitoare a acestei funcții? Ce i-ați cere autorului să adauge înainte de a aproba? Reîncercarea solicită un comentariu specific pentru fiecare problemă, cu motivul și o sugestie.
O încercare mai puternică. „Funcția aplică două tipuri de reducere: rotunjește, salvează și publică un eveniment, așa că o modificare a rotunjirii ar putea modifica ceea ce stocăm și ceea ce publicăm în același timp. Aș solicita ca regulile de stabilire a prețurilor să fie mutate într-o funcție pură pe care o putem testa independent. Testul unic acoperă doar o reducere procentuală. Aș solicita o reducere fixă și o comandă care aduce totalul la zero. Nu sunt sigur dacă evenimentul este menit să se declanșeze atunci când totalul este zero, așa că aș întreba autorul.” Observați că acest comentariu numește problema, oferă motivul, face o sugestie concretă și afirmă ceea ce recenzentul nu știe.
5. Evaluarea capacității și planificarea transferului
Dovada capacității este performanța la o nouă schimbare pe care evaluatorul nu a observat-o. Evaluați acuratețea constatărilor și utilitatea explicației. O rubrică simplă folosește o scală de la 0 la 2 pentru fiecare criteriu:
| Criteriu | Dovezi observabile |
|---|---|
| Executarea sarcinilor | Găsește preocupările relevante în schimbare și înregistrează dovezile pentru fiecare dintre ele. |
| Raţionament | Explică de ce fiecare preocupare este importantă, oferă o alternativă și spune ce rămâne incert. |
| Limite | Respectă regulile de evaluare ale echipei și solicită ajutor sau informații atunci când lipsește autoritatea sau contextul. |
Ancore: 0 înseamnă absent sau nejustificat, 1 înseamnă parțial cu omisiuni relevante și 2 înseamnă complet și justificat în funcție de criteriile convenite. Definiți separat erorile critice, de exemplu, aprobarea unei modificări cu risc de pierdere a datelor, astfel încât un scor general bun să nu poată ascunde unul. Adaptați criteriile împreună cu managerul de inginerie; această rubrică este o propunere de pornire, nu un standard de pregătire validat. Pentru mai multe informații despre raționamentul de notare, consultați ghidul nostru pentru... proiectarea unei practici interactive cu feedback util.
Planificați transferul. După exercițiu, verificați un eșantion de recenzii reale ale evaluatorului câteva săptămâni mai târziu, utilizând aceleași criterii. Comparați cu o valoare inițială stabilită înainte de instruire și definiți populația și calendarul de la început. Analizați alte schimbări care au avut loc în aceeași perioadă, cum ar fi un nou instrument de evaluare sau o schimbare de personal, înainte de a acorda credit exercițiilor.
6. Desfășoară exercițiul în timp real sau în ritmul tău propriu cu AhaSlides
Puteți desfășura exercițiul într-un atelier sau puteți lăsa evaluatorii să lucreze singuri la el. Într-o sesiune live, prezentați modificarea pregătită și folosiți diapozitive interactive pentru discuție:
- Alegeți Răspuns pentru „ce problemă ați ridica prima?”, cu preocupările selectate ca opțiuni. Afișați diferența înainte de a vă dezvălui propriul clasament.
- Deschis încheiat pentru „scrie comentariul pe care l-ai lăsa”. Recenzorii își pot compara formularea cu cea a altora, ceea ce reprezintă punctul de vedere al abilității de explicare.
- Scara de evaluare pentru „cât de grav este acest lucru?”, astfel încât grupul să poată vedea unde diferă judecățile și să discute de ce.
Pentru evaluatorii care nu pot participa, aceeași secvență poate fi utilizată în ritmul propriu, recenzia adnotată a expertului fiind afișată după fiecare răspuns. Tratați orice afirmație despre execuția codului, integrări sau funcții de inteligență artificială ca neconfirmată până când nu ați încercat-o cu propriul material.
Dacă instruiți și recenzori în utilizarea codului scris cu ajutorul inteligenței artificiale, consultați ghidul nostru suplimentar despre Instruire pentru revizuirea codului generat de inteligența artificialăPostarea respectivă este despre auditarea rezultatelor generate. Aceasta este despre modul în care oamenii își evaluează reciproc munca și cum explică ceea ce constată.
Constrângeri care pot rămâne
- Timp de revizuire. Un comentariu atent făcut durează mai mult decât „LGTM”, iar termenele limită împing spre versiunea scurtă.
- Normele echipei. Dacă feedback-ul este interpretat ca o critică personală, recenzorii își vor atenua sau își vor abandona concluziile.
- Acoperirea cazului. Un exercițiu arată câteva tipuri de îngrijorare. Un scor nu descrie judecata unui evaluator în general.
- Transfer. Performanța într-un atelier nu este aceeași cu performanța într-o coadă aglomerată, așa că verifică și recenzii reale.
Numiți-le sponsorilor din timp și planificați remedieri separate. Exercițiile îmbunătățesc ceea ce un recenzent poate vedea și explica. Nu creează timpul sau normele necesare.
Întrebări frecvente
Ce sunt exercițiile de revizuire a codului?
Sunt sarcini de practică pregătite, în care un dezvoltator analizează o modificare cu probleme cunoscute, scrie comentariile pe care le-ar lăsa și primește feedback cu privire la acuratețe și utilitate. Scopul este de a dezvolta abilitățile recenzentului, nu de a expedia modificarea.
Cum evaluezi dacă judecata unui recenzent s-a îmbunătățit?
Prezentați o nouă modificare pe care nu au observat-o și evaluați constatările și explicația în funcție de criteriile convenite. Apoi, verificați un eșantion de recenzii reale câteva săptămâni mai târziu. Un test despre regulile de evaluare confirmă doar condițiile preliminare.
Revizuirea codului de la colegi se referă în principal la găsirea erorilor?
Detectarea defectelor este încă o motivație principală, dar un studiu realizat de Microsoft a constatat că recenziile au fost mai puțin despre defecte decât se așteptau și au oferit, de asemenea, schimb de cunoștințe și conștientizare a echipei. Proiectați exerciții care recompensează explicațiile și înțelegerea, precum și numărul de defecte.
Unde să încep
Alegeți un tip de schimbare pe care echipa dvs. o evaluează des. Scrieți declarația de performanță, rugați un inginer senior să pregătească o schimbare cu trei sau patru probleme de îngrijorare și elaborați o rubrică cu trei criterii, cu o scală de la 0 la 2 și o listă de erori critice. Testați-o cu un grup mic, apoi comparați următoarele evaluări reale cu o valoare de referință.
Pentru a vedea cum un exercițiu de recapitulare ar putea fi desfășurat live cu propria echipă și reutilizat ulterior în ritmul propriu, explorează AhaSlides.
