În fiecare săptămână, la Mozaic Works, în echipa de dezvoltare de produse, descoperim 2 - 3 buguri în produsul la care lucrăm în timpul sesiunii de Code Review. Acest lucru se întâmplă în ciuda faptului că lucrăm într-un mod foarte structurat și aplicăm ATDD și Test First/TDD.
Mai mult, dezvoltatorii și liderii tehnici se plâng la noi ori în comunitate ori în timpul sesiunilor de coaching sau workshopuri despre anumite aspecte ale revizuirilor de cod.
Există două tipuri principale de guideline-uri:
Programatorii vor dezbate Guideline-urile Cosmetice ore în șir. Dovada este pe google, dar nu aș căuta „tabs vs. spaces debate” dacă aș avea multe de făcut. Așadar, Guideline-urile Cosmetice ar trebui să fie discutate o singură dată și introduse în setările IDE. Ne putem obișnui cu scrierea de acolade pe următoarea linie după numele funcției; nu merită să purtăm o dezbatere pe această temă . Însă consistența codului este cea mai importantă și fiecare echipă Scrum trebuie să lucreze după Guideline-uri Cosmetice comune.
Documentele lungi de guideline-uri erau des întâlnite atunci când lucram ca junior developer. Liderii tehnici obișnuiau să copieze principiile Microsoft sau să îi îndrepte pe dezvoltatori către acestea. Deși acestea mă ajutau să scriu cod mai bun, era imposibil să le țin minte pe toate.
Există un mod mai simplu. O arhitectură bună implică o analiză de risc, modele de cod și guideline-uri de urmat. Guideline-urile pot fi legate de securitate ( ex. “toate datele legate de dosarul pacientului trebuie criptate”), testare ( ex.“folosim peste tot dependency injection pentru a ușura testarea automată”), performanță (ex. “folosiți un profiler pentru a măsura timpul de execuție pentru toate query-urile din modulul de raportare”) etc. . Acestea sunt primele guideline-uri: specifice, contextuale și care ajută la evitarea greșelilor comune.
Iar aceasta ne duce la ..
Ne aminteam de vremurile în care liderul de echipă ne dădea în prima zi a unui proiect să citim un document de guideline-uri de 20 de pagini. Citirea acestuia consuma mult timp și nu rețineam aproape nimic. Când am ajuns lider tehnic, am decis să îmbunătățesc abordarea. Iată cum: Principiile tehnice sunt în general bazate pe “best practices”; problema cu best practices este că nu toate best practices pot fi aplicate pe toate produsele. Așa că prefer denumirea de “reguli care ajută la evitarea greșelilor comune”. Cum știm care sunt greșelile comune? Simplu, trebuie întâi să le facem. Unii dintre voi probabil vă veți încrunta, dar dacă ești onest cu tine însuți vei realiza că faci destule greșeli. Eu fac destule greșeli, însă am sprijinul colegilor în a fi onest cu mine însumi. Cum ar fi să te bucuri de avantajul greșelilor pe care le faci? Iată cum funcționează acest ciclu virtuos:
Scrie coding guidelines -> Fă code review -> Analizează greșelile -> Îmbunătățește coding guidelines.
În echipele cu care am lucrat am întâlnit trei tipuri dominante de revizuire de cod: over-the-shoulder, folosind un tool și pair programming. Fiecare are atât avantaje cât și dezavantaje și de aceea se merită să le combinăm.
Scopul revizuirilor de cod este să evităm greșelile sau așa cum le numim în industrie, bug-urile. Un efect secundar ar fi să învățăm citind și discutând codul altcuiva. Prima dificultate cu revizuirea codului în Scrum este să construim disciplina. Dacă ai început de curând să faci code review în Scrum, trebuie să stabilești clar când o să îl faci. Ca de exemplu: o dată pe săptămână sau când un user story este gata.
Odată ce ai creat obiceiul de a face code review în Scrum, strategiile pot varia.
De exemplu, la un program foarte complicat, am ajuns să folosesc următoarele tipuri de code review:
Over the shoulder - eu merg câteodată lângă colega mea Claudia și mă uit la codul pe care îl scrie. Și ea face la fel; de fapt, nu îmi este niciodată rușine să îi cer ajutorul când lucrez la un task.
Programat - în fiecare săptămână, avem o sesiune de o oră de revizuire de cod.
Pair Programming - când avem un task mai complicat sau ne decidem să încercăm un mod nou de a face lucrurile.
Noi nu folosim un tool pentru code review. Ne uităm la cod, discutăm, decidem ce îmbunătățiri am putea aduce și le aplicăm cât mai repede cu putință.
Cum procedezi într-o echipă mai mare? Propunem următoarea strategie pentru cei ce revizuiesc cod în Scrum:
Pair programming pe user stories complexe. În cazul în care story-ul a fost complet dezvoltat folosind pair programming, considerăm că este deja revizuit.
Când un story este gata, revizuiește-l cu un coleg. Nu este necesar să fie mai experimentat colegul. Revizuiește conform cu coding guidelines dar și pentru lizibilitate, simplitate, ușurința de schimbare și securitate. Notează-ți problemele constatate și dă-le mai departe Scrum Master-ului.
O dată pe sprint, programează o sesiune de 30’ cu echipa în care să analizați împreună o parte din codul scris în timpul sprint-ului. Dă mai departe rezultatele revizuirii către Scrum Master.
Cel puțin o dată la 4 sprint-uri pune un dezvoltator mai experimentat să se uite la părți aleatorii ale codului pentru 30-60’. Concluziile ar trebui să meargă (nici o surpriza aici) la Scrum Master.
Discutați constatările la retrospectivă. Scrum Master-ul ar trebui să decidă un program, în funcție de numărul de probleme identificate. Retrospectiva va duce la o actualizare a coding guidelines.
Această strategie are avantajul că pune la treabă creierele tuturor dezvoltatorilor nu doar ale liderilor tehnici.
Persoanele care erau lideri tehnici înaintea tranziției la Scrum tind să devină gatekeeper-i. O greșeală tipică este că vor să facă toate revizuirile de cod în Scrum pentru a asigura o calitate înaltă.
Deși scopul lor este bun, punerea în aplicare nu ajută echipa. Un lider tehnic care insistă să valideze singur tot codul va deveni un bottleneck foarte curând. Dezvoltatorii din echipă vor fi slab motivați să își asume responsabilitatea pentru codul pe care îl scriu dacă știu că cineva îl păzește. De asemenea, liderul tehnic riscă să se separe de echipă pentru că el este evident deasupra celorlalți colegi.
Încercați să întoarceți lucrurile pe dos și veți obține o echipă funcțională, productivă care învață împreună. Un fost lider tehnic îndrumă și ajută toată lumea să crească prin pair programming, ajutându-i cu sarcini dificile sau oferind minisesiuni de formare. Dezvoltatorii își asumă responsabilitatea pentru codul lor deoarece își revizuiesc reciproc codul. Toată lumea are roluri egale, dar toată lumea contribuie în echipă cu ce are mai bun de oferit: programatorii juniori cu abilitățile și timpul lor, dezvoltatorii seniori cu soluții inteligente și liderii tehnici cu creșterea fiecărui membru din echipă.
Încrederea în colegii tăi va duce echipa la un mod de lucru mult mai eficient.
Pentru revizuiri de cod în Scrum mai folositoare, urmează aceste reguli:
Ai încredere în colegii tăi!
