Despre revizuirea codului

In acest articol vom discuta despre practica revizuirii codului. Practica este cunoscuta, obligatorie si destul de raspandita in diferite medii AGILE. Dar asta nu inseamna ca nu este in interesul nostru sa analizam cat de utila este aceasta precum si diferite metode prin care sa o imbunatatim.

Nov 2, 2016 1786
In acest articol vom discuta despre practica revizuirii codului. Practica este cunoscuta, obligatorie si destul de raspandita in diferite medii AGILE. Dar asta nu inseamna ca nu este in interesul nostru sa analizam cat de utila este aceasta precum si diferite metode prin care sa o imbunatatim.

Sunt cateva stadii de dezvoltare a unei echipe si la fiecare din aceste stadii pot fi implementate diferite forme de revizuire a codului. Unele echipe doar au citit despre aceasta practica in timp ce pentru altele revizuirea codului este o practica obligatorie.

Dar daca teoria este aplicata acest lucru nu garanteaza ca beneficiile revizuirii codului despre care se discuta in foarte multe carti de specialitate se vor materializa. Care ar fi problema?

About code review_1.jpg


In primul rand, revizuirea codului duce de cele mai multe ori la verificarea stilului. Este cea mai simpla forma de feedback care poate fi generata automat, in special daca stilul nu depinde de anumite tool-uri cu care se lucreaza. In acest caz daca nu avem categorii clare in instrumentul cu care revizuim, vom avea foarte multe comentarii legate de stilul de programare si foarte putin comentarii cu adevarat utile.

In cel de-al doilea rand, dupa observatiile legate de stil urmeaza cele care intra in aria УEu nu as fi facut asa!Ф Ц deoarece vor exista mereu diferente in ceea ce priveste dezvoltarea codului intre programatori diferiti. La fel cum se intampla in abordarile legate de rezolvarea anumitor sarcini. Aici este important sa intelegem in ce fel solutia actuala este mai buna / mai putin buna fata de cea oferita. Altfel nimeni nu o sa faca pasii necesari sa rezolve situatia.

In cel de-al treilea rand cei care revizuiesc codul s-ar putea sa nu cunoasca intregul context in asa fel incat procesul de revizuire sa fie cat mai complet. Exista situatii in care bucati de cod apartin unor persoane diferite si implicit o sa fie greu pentru cineva sa vada imaginea de ansamblu astfel incat sa ofere un feedback util. Daca exista comentarii cel care a scris codul va spune ca totul este ok in timp ce persoana care l-a revizuit va sustine ca sunt probleme.

In cel de-al patrulea rand, de multe ori este prea tarziu. Provocarea legata de revizuire este ca ea are loc dupa ce sarcina a fost finalizata Ц acest lucru inseamna ca investitiile s-au facut deja, entuziasmul momentului a trecut si avem alte sarcini in backlog. Din acest motiv cel care revizuieste s-ar putea sa nu vrea sa imparta clasele in unele mai mici si mai simple, sa aloce responsabilitati pentru metode si sa creasca УlizibilitateaФ testelor sau a codului.

De asemenea revizuirea codului poate genera iteratii care nu se mai termina. Atunci cand cel care revizuieste vrea ca acel cod sa arate intr-un anumit fel, el sau ea ar putea sa genereze o serie de УiteratiiФ unde cel care a produs codul incearca sa УacomodezeФ decizia pe care a luat-o cu ceea ce doreste persoana care revizuieste codul (poate sa fie parerea lead developer-ului sau a arhitectului software) Ц dar de multe ori acest lucru nu functioneaza. Rezultatul final intarzie sa apara si este ineficient atat pentru autorul codului cat si pentru cei ce il revizuiesc.

Ce ar trebui sa facem pentru a creste calitatea acestui proces?

Pentru ca un proces de revizuire sa fie eficient, toti participantii trebuie sa isi doreasca acest lucru si sa abordeze procesul ca un instrument si nu ca obiectiv final. Mai jos sunt cateva sfaturi pentru a face procesul mai eficient.

In primul rand este preferabil sa lucram in perechi atunci cand ne confruntam cu sarcini dificile Ц cum ar fi etapa de design. Acest lucru implica un УownershipФ comun asupra codului / solutiei, lucru care va simplifica procesul de revizuire. Autorul codului nu va lua feedback-ul personal deoarece exista o responsabilitate comuna. Solutia va avea o calitate mai buna din moment ce avem 2 perechi de ochi care o analizeaza. Iar in cazul unei revizuiri colegul de echipa este un back-up util si poate clarifica eventuale neclaritati.

In cel de-al doilea rand, in situatii dificile si fara un partener este rezonabil sa facilitam o revizuire inainte de a rezolva alte sarcini. Acest lucru le va permite oamenilor sa reduca riscurile asociate cu rezolvarea sarcinilor gresite sau oferirea unei solutii gresite pentru sarcina corecta. Totusi, faptul ca suntem mai clari cu privire la context dupa ce avem design-ul solutiei deja stabilit ne ajuta sa facem comentarii valide in timpul revizuirii codului din moment ce toti cei implicati in proces sunt constienti de problema care exista sau, cel putin partial, vor stii care este solutia.

In cel de-al treilea rand este rezonabil sa automatizam provocarile legate de stil in asa fel incat sa nu apara in procesul de revizuire. Va reduce astfel tentatia de a face comentarii off-topic si implicit va diminua posibilele situatii de tensiune din echipa.

Separat de aceste aspecte, trebuie sa stabilim limite si reguli Ц formale sau informale. Spre exemplu sunt mai multe instrumente care ne permit sa formulam actiunile noastre ca statusuri sau comentarii. Daca cineva decide sa inchida comentariile cu statusul УWonТt fix.Ф acest lucru va parea agresiv. In acelasi fel, daca sistemele pe care le folosim ne permit sa avem УvetoФ asupra unei revizuiri, pot sa afecteze relatiile cu echipa. Ca atare recomandarea este sa ii scriem persoanei respective, sa o sunam sau sa o abordam pentru a discuta despre aceste provocari si solutiile lor in persoana. Comunicarea verbala este in mod general un mijloc util in rezolvarea situatiilor critice.

Si in final este important sa intelegem scopul intregului proces. Scopul unui proces de revizuire nu este acela de a ne arata superioritatea ci de a imbunatatii modul de lucru. Revizuirea ne ajuta sa ne impartasim cunostintele. Acest schimb de experienta reduce riscul de implementare a unor solutii ineficiente.
Dar la fel ca orice alte tactici, revizuirea codului este utila atunci cand este folosita conform scopului ei intr-o echipa competenta.

Sergey Teplyakov
Expert in .Net, —++ and Application Architecture

Daca iti place acest articol, distribuie-l si prietenilor tai!




Mai ai intrebari?
Contacteaza-ne.
Thank you.
Your request has been received.