ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 31
Abonament PDF

Cinci sfaturi practice pentru Code Review în Scrum

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works



PROGRAMARE

Î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.

Sfatul #1: Discutați guideline-urile cosmetice doar o singură dată

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.

Sfatul #2: Pornește cu un număr minim de principii derivate din arhitectură

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 ..

Sfatul #3: Îmbunătățește guideline-urile în funcție de greșelile din trecut

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.

Sfatul #4: Folosește diferite tipuri de Code Review

Î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:

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.

Sfatul #5: Ai încredere în colegii tăi

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.

Sumar

Pentru revizuiri de cod în Scrum mai folositoare, urmează aceste reguli:

Ai încredere în colegii tăi!

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO