Recenzii de cod

Sunt necesare recenzii de cod? Nu revedem deja codul în același timp în care dezvoltăm? Dacă folosesc deja refactoringul ca practică obișnuită, ce rost are să verific din nou codul?

Există multe întrebări care pot apărea într-o echipă de dezvoltatori cu referire la recenziile de cod. Dar chiar mai rău decât întrebările sunt îngrijorările sau nelămuririle („dacă codul meu este verificat, munca mea va fi distrusă!”). În primul rând, vom începe prin a defini ce este o revizuire a codului (Revizuirea codului).

Definiția Code Review

Să începem de la un scenariu în care lucrăm într-un cadru agil și, în cadrul diferitelor opțiuni, să alegem Scrum. Obiectivul acestui post nu este să aprofundăm în funcționarea acestor metodologii. Deși este posibil ca în viitor să vorbesc mai multe despre ele, Internetul este plin de informații despre ele; Recomand în mod special blogul lui Javier Garzás.

Este necesar să se stabilească un cadru inițial pentru a localiza modul în care abordăm dezvoltarea software-ului nostru. În Scrum „unitatea de dezvoltare” este povestea utilizatorului, iar unitatea de timp este sprintul.

Să ne imaginăm atunci că o echipă de 4 dezvoltatori trebuie să împartă dezvoltarea mai multor povești ale utilizatorilor de-a lungul unui sprint. Să ne imaginăm că unui dezvoltator solo (să-i spunem Luis) i se atribuie povestea utilizatorului X (de exemplu, „Creați un strat de persistență a datelor”).

O revizuire a codului este procesul prin care restul echipei revizuiește împreună implementarea lui Luis pentru acea poveste de utilizator, oferind idei despre cum să o îmbunătățească, poate să o refactorizeze, descoperind posibile erori, erori de arhitectură, lipsa acoperirii testelor pentru anumite cazuri și o serie de alte lucruri care pot apărea.

Reticenta ...

Să fim direcți: profilurile „complicate” abundă în profesia noastră. Fără a intra în prea multe detalii, anumiți dezvoltatori nu sunt deschiși criticilor, cu atât mai puțin să modifice un cod pe care l-au completat și funcționează, în teorie. Dacă vreunul dintre cititori aparține acestui grup, le-aș pune următoarele întrebări:

Codul dvs. este ușor de înțeles pentru altcineva decât dvs.?
Ați putea să înțelegeți acest cod în câțiva ani?
Ați luat în considerare TOȚI factorii care afectează sau pot afecta sistemul atunci când vă dezvoltați codul?
Dacă ați descoperit o eroare flagrantă în codul altcuiva, nu credeți că este responsabilitatea dvs. ca profesionist să o remediați? În acest caz, nu este mai bine să detectăm astfel de erori cât mai curând posibil?

Colectivitatea codului. Codul nu este al meu

Într-adevăr, atunci când lucrăm la un proiect de afaceri, programăm un cod care va continua să fie dezvoltat, îmbunătățit și întreținut de o mână bună de dezvoltatori în viitor. Cred că într-o astfel de zonă nu are sens să vorbim despre proprietatea individuală a codului, ci dimpotrivă.

Proprietatea colectivă a codului încurajează o echipă agilă să își asume responsabilitatea pentru funcționarea absolut întregului sistem livrat. Nu arăta cu degetul spre vinovați când ceva nu funcționează sau sugerează că „nu am fost acolo” sau „nu am fost acolo”. Aș spune că așa ceva este evident ... dar nu este deloc.

Experiența m-a învățat că recenziile codurilor sunt cel mai eficient mod de a atinge acel ideal.

Procesul

Procesul de revizuire a codului începe atunci când un dezvoltator va încărca sau a încărcat deja în depozitul central (presupunem că folosim Git sau un instrument similar de control al versiunilor) toate modificările asociate cu implementarea istoricului atribuit utilizator.