Despre ce vorbim când spunem software de calitate? Este vorba doar de calitatea codului sau de calitatea proiectului? Sau poate ar trebui să ne raportăm la calitatea echipei și a interacțiunilor dintre oameni?
Nu-i așa că nu poate fi vorba doar de un singur element în ecuație? Hai să le luăm pe rând și să vedem cât de important este fiecare element din jurul codului.
Când vorbim de calitatea codului trebuie să avem în vedere mai multe aspecte.
În primul rând, trebuie să ne asigurăm că zecile de linii de cod fac ceea ce trebuie să facă deoarece scopul oricărui software trebuie să fie rezolvarea problemei pentru care a fost scris.
În cazul în care codul face ceea ce trebuie să facă, atunci putem trece și la alte aspecte cum ar fi consistența stilului.
Experiența ne arată că orice soft, în mod constant, are nevoie de îmbunătățiri și update-uri pentru că cerințele se schimbă des. De aceea este important să ne definim un stil pe care să-l respectăm pe întreaga durată a procesului de dezvoltare.
De ce este important să avem un stil consistent?
Putem să răspundem la această întrebare cu o altă întrebare: Este codul ușor de înțeles?
Un cod poate fi înțeles ușor în funcție de mai multe elemente, iar unul dintre ele este consistența, despre care am vorbit mai sus. Dacă respectăm acest standard, putem reduce considerabil efortul de a înțelege codul scris anterior. Evident că stilul consistent nu este singurul principiu care ne poate ajuta să avem un cod ușor de înțeles.
Un alt aspect ar fi dezvoltarea codului folosind design patterns, cunoscute și adoptate de comunitate.
Documentația, care de multe ori este lăsată în urmă, poate avea o pondere semnificativă atunci când vorbim de calitatea codului. De cele mai multe ori, comentariile specifice fiecărei metode, clase etc. nu sunt suficiente pentru a avea o vedere de ansamblu asupra unei părți a aplicației. Dar din fericire, având documentația pregătită și întreținută, cu un efort minim, un programator poate afla informațiile pe care nu le poate înțelege din codul efectiv.
O întrebare foarte bună este: Codul poate fi testat? Ce poate fi mai util decât un cod testabil? Un cod testat, evident. Dar pentru a putea scrie teste, programatorul trebuie să aibă acest lucru în vedere încă din momentul în care își stabilește modul de implementare a unei soluții. Există și cazul în care se folosește procesul TDD, unde testele sunt scrise înainte să avem codul propriu-zis. Evident, acest mod de abordare vine cu avantajul unui procent ridicat de acoperire a codului testat.
Dacă vorbim de calitatea proiectului, trebuie să răspundem la câteva întrebări care ne vor ajuta să clasificăm și ulterior să îmbunătățim acest metric.
Întrebam la început dacă este importantă calitatea proiectului. Sunt diverse moduri în care un proiect poate fi considerat de calitate sau nu.
Are proiectul un Life Cycle bine definit? Chiar dacă acest aspect descrie la nivel înalt procesul de livrare, prin el sunt stabiliți pașii de livrare a proiectului.
Automatizarea procesului de dezvoltare este un alt element important. De-a lungul procesului de dezvoltare există multe subprocese, care pot fi automatizate, cum ar fi: Build automat, Deploy Automat, Testare Automată etc. Automatizarea acestor procese va reduce timpul de lucru al task-urilor repetitive, va aduce siguranța că lucrurile funcționează, precum și predictibilitatea și stabilitatea procesului de dezvoltare și livrare al proiectului.
Pe lângă elementele concrete de mai sus, există și câteva lucruri pe care trebuie să le avem în minte, cum ar fi înțelegerea corectă a problemei reale pe care proiectul/codul o rezolvă. Este important să ne detașăm de implementarea tehnică și să privim în ansamblu întregul proiect din toate perspectivele posibile.
Calitatea echipei, la rândul ei, este esențială în dezvoltarea și livrarea unui proiect.
Orice echipă trebuie să aibă bine definit un proces prin care dezvoltă și livrează.
De asemenea, este important ca fiecare membru al echipei să fie inclus în acel proces. Mai mult decât atât, membrii echipei trebuie să-l agreeze deoarece fiecare dintre ei contribuie într-un fel sau altul la dezvoltarea produsului și fiecare poate avea un input bun la îmbunătățirea procesului.
Orice proces, oricât de bun ar fi, trebuie evaluat pentru a vedea dacă scopul inițial este atins prin utilizarea acestuia. El poate fi ajustat oricând, astfel încât să se obțină cele mai bune rezultate la nivel de echipă.
Spuneam mai sus că orice membru trebuie inclus în aceasta activitate și că procesul trebuie agreat de toți membrii. Acest lucru este necesar pentru că trebuie să existe un mod comun de evaluare și estimare a efortului de lucru.
Cum măsurăm calitatea?
În primul rând, calitatea codului poate fi analizată în mod automat luând în calcul o serie de metrici. Nimic nu poate fi catalogat decât dacă este măsurat, așa că pentru a putea emite o opinie despre calitate, trebuie să definim anumite valori de referință cu care vom compara valorile diverșilor metrici.
Numărul de Defects este un metric util. Evident, această valoare trebuie să fie zero sau cât mai apropiată de zero. Acest metric ne ajută să evaluăm cât de multe bug-uri au fost introduse în cod din greșeală de către programator.
Folosind tool-uri de analiză a codului putem obține alți metrici relevanți măsurării calității codului, în special pentru limbajele Dynamically Typed.
Testele automate sunt o sursă de încredere pentru că ne ajută să verificăm cât din codul nostru este acoperit de teste. De aici rezultă obținerea unui alt metric, anume Code Coverage.
Cum putem analiza calitatea proiectului, dar și a echipei?
Orice echipă ar trebui să facă Code Review. Unul dintre avantajele acestui proces este că anumite lucruri pot scăpa programatorului sau chiar testărilor automate, dar aceste omiteri pot fi ușor identificate de un alt membru al echipei. Un alt avantaj, poate cel mai important al code review-ului este că membrii echipei sunt conștienți de noile modificări ale aplicației, având în vedere faptul că acestea apar în mod constant.
Ieșind din sfera codului, un metric bun este rapiditatea cu care se poate adapta echipa la schimbările de direcție. Produsele software suferă schimbări, inclusiv în perioada de dezvoltare. În acest sens, o echipă flexibilă este o garanție în plus că adaptarea va fi cât mai ușoară și rapidă.
Este destul de cunoscut faptul că în industria de IT există un turnover mai ridicat când vorbim de membrii echipelor. Fie că echipa se extinde, fie că unii membri sunt înlocuiți, rămâne necesitatea de a reduce cât mai mult perioada până când cei noi devin productivi. O echipă competitivă va investi întotdeauna timp și resurse pentru a-și crește membrii noi cât mai repede.
Din fericire, aceste bune practici au fost dezvoltate și se regăsesc în metodologia Agile. Agile este metodologia care pune pe primul loc calitatea proiectului, calitatea interacțiunii între echipe. Focalizarea nu mai este pe cod în sine, ci pe echipa care dezvoltă proiectul.