'Y'

Pacatele unui code reviewer

Activitatea de revizuiere a codului (code review) este un lucru bun dar la fel ca alte lucruri bune facute gresit, poate face mai mult rau decat bine. Asta n-ar trebui sa fie un motiv de ingrijorare, deoarece mai jos veti gasi o lista de lucruri de evitat atunci cand faceti code review.

Feb 21, 2017 2256
Activitatea de revizuiere a codului (code review) este un lucru bun dar la fel ca alte lucruri bune facute gresit, poate face mai mult rau decat bine. Asta n-ar trebui sa fie un motiv de ingrijorare, deoarece mai jos veti gasi o lista de lucruri de evitat atunci cand faceti code review.

Revizuierea codului este buna

Revizuirea codului este o activitate foarte importanta. Nu este nevoie sa vorbim foarte mult despre asta deoarece sunt nenumarate articole care scot in evidenta beneficiile. Majoritatea este de acord ca revizuirea codului este un element cheie pentru a avea un cod de calitate. Totusi mai putini observa si restul beneficiilor, precum imbunatatirea abilitatilor analitice ale programatorilor, a competentelor acestora de argumentare, comunicare si impartasire a cunostintelor impreuna cu echipa, ca sa evidentiem doar cateva dintre ele. Dar aceasta activitate este general acceptata ca fiind buna. La fel ca spalatul pe dinti.

Oameni diferiti o fac diferit

Unele echipe vad revizuirea codului ca fiind un proces optional, recomandat dar nu neaparat impus. Anumiti team leads aloca cateva ore per sprint pentru aceasta activitate si incurajeaza programatorii sa revizuiasca codul colegilor. Sunt si companii unde acest proces este obligatoriu: codul produs de un developer trebuie sa fie revizuit de unul sau mai multi colegi, de obicei cei care sunt vazuti ca avand mai multa experienta, si trebuie sa obtina acordul acestora inainte de a fi inclus in branch-ul principal. Nu este nevoie sa discutam daca acest lucru este nejustificat sau singura modalitate responsabila de a dezvolta software, deoarece au fost multe dezbateri pe aceasta tema. Dar asta arata importanta pe care aceste companii o atribuie revizuirii codului: nu vor accepta cod care nu este revizuit, vor amana lansarea sau vor incetinii procesul de dezvoltare pentru a asigura acest lucru. Ele cred cu tarie in importanta revizurii codului.

With great power comes great responsibility

Asta am invatat cu totii de la Spiderman. Revizuirea codului este dificila. Cel care revizuieste codul trebuie sa inteleaga care a fost nevoia care l-a impins pe programator sa scrie acel cod si acest lucru nu este usor deoarece dezvoltarea de software este un efort complex. Programatorul trebuie sa explice nevoia si rationamentul din spatele alegerilor pe care le-a facut cand a scris codul. Si nici asta nu este usor. Fara a apela la stereotipuri putem spune ca majoritatea programatorilor intampina dificultati atunci cand vine vorba sa explice in cuvinte munca si alegerile pe care le-au facut. In special cand vorbim de alegerile facute cu ani in urma si care intre timp s-au transformat in obiceiuri.

Revizuirea codului este dificila pentru ego

Atunci cand doi oameni discuta despre o portiune de cod, cineva trebuie sa aiba dreptate si cineva nu. Asta este destul de dur. Ce face lucrurile si mai dificile este ca cel care revizuieste codul se afla intr-o pozitie de putere: de obicei un programator cu mai multa experienta, uneori un team lead, care se afla acolo pentru a face codul “mai bun”. Revizuirea codului poate merge foarte prost si implicit consecintele pot sa fie dramatice: un impact negativ asupra relatiilor de la locul de munca, tensiune, resentimente, sentimentul ca nu ai control, lipsa de ownership pe cod, un sentiment de neimplinire etc. O persoana care este convinsa impotriva vointei sale va avea in continuare aceeasi opinie.

Aspectul cel mai important

Un proces de revizuire care are un impact major si pozitiv asupra codului dar care afecteaza negativ relatiile de munca si atitudinea pozitiva a programatorului este mai bine sa nu fie facut. Imbunatatirea unei anumite parti din cod intr-o seara de miercuri nu este principalul beneficiu al revizuirii codului. Incurajarea si mentinerea unor relatii bune de lucru intre colegi in timp ce colaboram sau facem mentorship pentru programatorii incepatori – acestea trebuie sa fie obiectivele principale deoarece avantajele de pe urma lor sunt mult mai mari.

Pacatele unui code reviewer.jpg


Bineinteles ca influentarea nu este o sarcina usoara

Pentru diplomati si politicieni ma refer, deoarece pentru programatori este mult mai dificil. Trecerea de la a declara raspicat punctul tau de vedere, a-l considera de necontestat si a-l promova cu forta la colaborare, influentare si mentorat nu este la fel de usoara ca invatarea unui nou limbaj de programare. Dar nu va faceti griji. Putem sa invatam si asta. Trebuie in primul rand sa evitam obiceiurile de mai jos:

1. Generalizare exagerata

Atunci cand vedem ceva care pare in neinregula si exageram acest lucru prin generalizari:

  • Asta facem acum, construim interfete pentru toate clasele?
  • Unde vom ajunge, sa facem wrapping pentru toate clasele SDK?
Este important sa nu generalizam pana nu vedem un comportament recurent, clar si cu impact negativ. Trebuie sa plecam de la presupunerea ca acel programator evalueaza fiecare situatie separat.

2. Preferinte personale

Invocarea ideii de preferinta personala este o metoda usoara de a evita confruntarile si efortul necesar pentru a gasi argumente logice.

  • Este opinia mea personala ca asa ar trebui sa facem aici.
  • Asa imi place mie sa fac lucrurile si cred ca si tie iti va placea daca incerci.
Cel care revizuieste codul trebuie ca de fiecare data sa foloseasca argumente logice, sa compare beneficiile cu costurile si sa faca trimitere la referinte general acceptate precum carti bune (Clean Code, Effective Java sau altele).

3. Neatentie la nevoile celui care a scris codul

Nici o solutie nu este perfecta sau fara costuri. Dar acest lucru nu poate sa fie reparat prin a nu avea cod deloc. Programatorul are nevoie de o solutie si codul actual nu poate sa fie respins fara o alternativa.

  • Nu inteleg de ce ai nevoie de asta, dar nu arata bine.
  • Nu vreau asta, vom gasi o solutie buna cu alta ocazie, dar asta nu pare corect, te rog sa folosim vechea versiune.
Acest lucru nu o sa faca altceva decat sa frustreze programatorul. Daca nu avem timp pentru o solutie mai buna, solutia actuala este cea mai buna.

4. Acuze de posesivitate

  • Problema este ca tu nu vrei sa accepti altceva in afara de versiunea ta.
  • Nu iti place cand cineva are ceva de spus despre codul tau.
Aceste lucruri reduc din calitatea discutiei astfel ca mai bine renuntam la revizuire.

5. Pozitie de putere

Utilizarea unei pozitii de putere, bazata fie pe experienta, fie pe rolul in echipa, in locul arugmentelor nu va convinge programatorul. Din contra, il va face sa atace autoritatea celui care revizuieste codul.

  • Crede-ma, din experienta mea aceasta este cea mai buna solutie.
  • Inteleg punctul tau de vedere, dar am opinia mea si la finalul zilei este sunt Team Lead...

Cum procedam in caz de egalitate?

Ce se intampla cand avem argumente logice si valide de ambele parti si nu putem obtine un acord? Atunci va recomand sa lasati codul asa cum este. De ce? Deoarece programatorul a investit efort in el si l-ar afecta negativ daca ar trebui sa il schimbe impotriva vointei lui. Adevarul, in general, se vede, rar se aude. Daca, dupa cateva saptamni, apar probleme la cod, atunci cel care a scris codul isi va aduce aminte de sugestia celui care l-a revizuit si o va accepta.

Fac toate astea o diferenta semnificativa?

Da. Cei care revizuiesc codul ineficient sunt evitati de colegii lor. Oamenii vorbesc in soapta in asa fel incat cel care revizuieste sa nu intervina in conversatie. Revizuirea codului nu este o experienta usoara. Nimeni nu revizuieste gresit codul de buna voie, unii programatori se concentreaza exclusiv pe partea tehnica a revizuirii si uita de modul in care comunica cu colegii lor.

O persoana care revizuieste eficient codul este curajoasa – isi spune punctul de vedere si il sustine, dar in acelasi timp transmite acest lucru in mod respectuos. Este apreciata chiar si de cei care nu sunt de acord cu ea si i se cere opinia din senin in afara ritualului de code review. Colaboreaza cu succes si influenteaza pozitiv colegii in multe feluri, unele din ele insesizabile.

Ionut Bilica
Software Development Consultant

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




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