A revizui — ce este, cum funcționează code review și verificarea PR

Ce este code review

Code review — este verificarea sistematică a codului de către colegi înainte de integrarea sa. În contextul Git, aceasta înseamnă: dezvoltatorul creează un pull request cu modificări, numește recenzori, iar aceștia studiază diff-ul, lasă comentarii și emit un verdict. Recenzorul poate solicita modificări (Request Changes), aproba PR-ul (Approve) sau lăsa un comentariu general.

Code review urmărește cinci obiective: îmbunătățirea calității codului (detectarea defectelor înainte de a ajunge în producție), răspândirea cunoștințelor (recenzorul află despre abordări noi, autorul primește feedback), respectarea standardelor (verificarea conformității cu code style și deciziile arhitecturale), reducerea bus factor (codul nu este cunoscut de un singur dezvoltator) și construirea unei culturi a responsabilității (autorul scrie mai atent, știind că codul va fi verificat).

Opusul code review este blind commit: dezvoltatorul trimite modificări în ramura comună fără review. Această abordare este permisă doar în proiecte cu un singur utilizator sau pentru hotfix-uri urgente cu review ulterior. În dezvoltarea profesională în echipă, code review este o etapă obligatorie pentru orice modificare, inclusiv corecturi de documentație și configurare.

Ce se verifică în code review

Code review trebuie să fie sistematic, nu haotic. Recenzorii experimentați verifică codul într-o anumită ordine: mai întâi arhitectura și logica, apoi testele, apoi securitatea și performanța, și la sfârșit — stilul și denumirile. Această ordine garantează că problemele critice sunt observate înainte ca recenzorul să obosească.

Arhitectura și logica: rezolvă codul problema, există abstracții inutile, sunt respectate principiile SOLID și DRY. Codul complex care este greu de înțeles la prima citire — un semnal că necesită refactorizare. Recenzorul trebuie să se asigure că codul face exact ceea ce este specificat în sarcină și nu are efecte secundare în afara domeniului său de responsabilitate.

Testele: acoperă testele noi toate scenariile — pozitive, negative, cazuri limită. Testele existente trec după modificări. Există teste flaky care cad instabil. Securitatea: absența injecțiilor SQL, XSS, scurgeri de date sensibile prin loguri sau răspunsuri API. Performanța: eficiența algoritmilor, interogări redundante la baza de date, scurgeri de resurse.

• Arhitectura — corectitudinea soluției, respectarea SOLID, absența over-engineering-ului.
• Logica — gestionarea tuturor scenariilor, inclusiv erori și cazuri limită.
• Testele — acoperirea modificărilor noi, absența testelor vechi stricate.
• Securitatea — injecții, XSS, CSRF, scurgeri de date prin loguri.
• Performanța — complexitatea algoritmilor, interogări N+1, scurgeri de memorie.

Dimensiunea review-ului: de ce 400 de linii este maximul

Limitarea dimensiunii PR — cea mai importantă metrică a eficienței code review. Cercetarea Cisco (2015) și experimentele ulterioare SmartBear și Google au arătat: la un volum de review de peste 400 de linii, capacitatea recenzorului de a detecta defecte scade dramatic. Dacă PR depășește 400 de linii, erorile sunt detectate cu o probabilitate nu mai mare decât cea aleatoare.

Dimensiunea optimă: 200-400 de linii pentru un PR. Acest volum poate fi verificat de recenzor în 30-60 de minute, păstrând concentrarea. Google recomandă nu mai mult de 200 de linii pentru o rundă de review cu concentrare deplină. Dacă modificările sunt mai multe — sarcina trebuie descompusă în mai multe PR-uri consecutive, fiecare aducând o modificare logic încheiată.

Timpul de review: în termen de 24 de ore de la momentul creării PR. Dacă review-ul se prelungește câteva zile, contextul sarcinii se pierde, iar autorul trebuie să piardă timp pentru restabilirea contextului la răspunsul la comentarii. Echipele cu o cultură înaltă a code review stabilesc SLA pentru review: de exemplu, 4 ore pentru modificări critice și 24 de ore pentru cele obișnuite.

Cum să scrii corect comentarii la review

Tonul comentariilor — este crucial pentru eficiența code review. Comentariul „Acest lucru este incorect" provoacă o reacție defensivă și nu oferă autorului informații utile. Cea mai bună formulare este întrebarea-sugestie: „Ce părere ai despre această abordare?", „Aici poate apărea NPE dacă user == nil. Poate adăugăm un guard?". Întrebările presează mai puțin și stimulează discuția.

Structura unui comentariu bun include trei părți: ce este în neregulă, de ce este o problemă și cum se corectează. Exemplu: „În această buclă se folosește O(n²) din cauza contains-ului imbricat, ceea ce poate încetini la 10k+ înregistrări. Încearcă să înlocuiești cu Set pentru căutare O(1)". O astfel de formulare indică simultan problema, explică importanța sa și propune o soluție — autorul nu trebuie să ghicească.

GitHub și GitLab suportă suggestions — propuneri încorporate de modificări ale codului. Recenzorul poate scrie: „```suggestion Filtrează liniile goale înainte de procesare```" — iar autorul aplică modificarea cu un singur click. Aceasta accelerează corecturile mici și reduce numărul rundelor de review. Pentru corecturi mari, este mai bine să scrii un comentariu general decât să inserezi blocuri mari în suggestion.

# Șablon pentru un comentariu bun de code review

# RĂU: „Acest cod este incorect"
# BINE: „Am putea pierde date la un răspuns gol.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Sintaxa sugestiei GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Workflow-ul code review în echipă

Un workflow eficient de review se bazează pe patru etape. Prima — autorul pregătește PR-ul: scrie un nume clar (de exemplu, „feat: add password reset screen"), adaugă descrierea modificărilor, linkuri către sarcina din tracker și instrucțiuni de testare. A doua — autorul numește recenzori prin auto-assign (pe baza CODEOWNERS) sau manual.

A treia etapă — recenzorul verifică codul și lasă comentarii. A patra — autorul face corecturi, răspunde la comentarii și solicită re-review. Ciclul se repetă până la obținerea aprobării. După aprobare, autorul execută merge (sau merge-ul este executat de bot). Automatizarea prin Mergify sau GitHub Auto-merge accelerează etapa finală.

Un element important al workflow-ului este gestionarea PR-urilor învechite. Dacă PR rămâne fără review mai mult de 3 zile, procesul se blochează. Soluții: rotația recenzorilor (dacă cel desemnat este indisponibil), notificări prin Slack/Teams, limită de timp pentru review (SLA). În unele echipe, PR-ul fără review mai mult de 7 zile este închis automat, iar autorul creează unul nou după sincronizarea cu main.

• Crearea PR — nume clar, descriere, linkuri către sarcină, capturi de ecran pentru modificări UI.
• Desemnarea — auto-assign prin CODEOWNERS sau selecție manuală a 1-2 recenzori.
• Review — verificare în ordinea: arhitectură → logică → teste → securitate → stil.
• Corecturi — autorul răspunde la toate comentariile, corectează blocking issues, solicită re-review.
• Merge — după aprobare și CI verde, autorul sau botul execută îmbinarea.

Greșeli tipice în code review

Prima greșeală — review superficial. Recenzorul parcurge în fugă diff-ul, fără a pătrunde în logică, și apasă Approve. Cauze: PR mare, deadline, oboseală. Consecințe: bug-uri ajung în producție. Soluție: dacă nu ai timp pentru un review de calitate — scrie sincer „Nu pot verifica astăzi, amână pentru mâine" în loc de o aprobare formală.

A doua greșeală — critica excesivă (nitpicking). Recenzorul lasă zeci de comentarii despre stilul de formatare, denumirea variabilelor, detalii banale. Acest lucru demotivează autorul și prelungește review-ul. Soluție: StyleGuide și linterele ar trebui să verifice stilul automat. Omul în review verifică logica, arhitectura și securitatea.

A treia greșeală — review fără întrebări. Dacă recenzorul pune doar Request Changes și Approve, dar nu pune întrebări, pierde oportunitatea de a învăța ceva nou. Cel mai bun indicator al sănătății code review este prezența discuțiilor în care ambele părți învață ceva nou. Dacă review-ul este un monolog al unuia dintre participanți — procesul este stricat.

• Review superficial — Approve fără aprofundare. Soluție: nu revizui dacă nu ai timp.
• Nitpicking — critica stilului care este verificat de linter. Soluție: automatizează style checks.
• Percepția personală — „eu aș fi scris altfel". Soluție: codul trebuie să funcționeze, nu să placă recenzorului.
• Prelungirea — review mai lung de 24 de ore. Soluție: SLA pentru review, escaladare la încălcare.
• Ignorarea contextului — review de cod fără înțelegerea sarcinii. Soluție: citește descrierea PR înainte de diff.