În lumea IT, code metrics sunt cunoscute și apreciate ca fiind foarte importante. Articolul de față își propune să analizeze code metrics din perspectiva unui dezvoltator sau a unui project leader.
Folosind code metrics, orice membru din echipă își poate da seama care este starea codului din punct de vedere a calități acestuia. Teoretic acesta poate să detecteze zonele de cod care ar putea să fie problematice și să le analizeze.
Pe lângă acest lucru, folosind code metrics, echipa poate să înțeleagă starea proiectului în momentul respectiv, să măsoare într-o formă sau alta cum s-au modificat metricele în timp și să identifice potențialele riscuri.
Există destul de multe metrice care formează code metrics. Din punctul meu de vedere, cele mai cunoscute sunt:
Definirea și explicarea fiecăreia dintre metrice vă sunt oferite de Bing, economia de spațiu a articolului nu își permite și dezvoltarea acestor aspecte.Ceea ce este cel mai interesant la fiecare metrică este că avem valori "magice" care ne pot spune dacă valoarea unei metrici este în parametri corespunzători sau nu.
De exemplu, când calculăm indexul de mentenabilitate, o valoare între 0 și 9 ne va indica că va fi dificil să facem mentenanță pe codul curent. În schimb o valoare între 10 și 19 ne va indica o zona favorabilă, unde nivelul de mentenabilitate este acceptabil. Orice valoare peste 20 ne va crește încrederea în posibilitatea modificării și întreținerii cu ușurință a codului.Dar aceste valori nu sunt bătute în cuie !Pentru că în funcție de proiect, putem să avem în unele zone valori sub 9, dar care nu mai pot fi îmbunătățite din cauza sistemului însuși. Toate metricele ne ajută să identificăm zonele de risc, dar decizia finală doar noi o putem lua.
Un exemplu sugestiv al importanței metricelor este legat de proiectele noi. Clientul (stakeholder-ul) va forța în fiecare versiune nouă implicarea a cât mai multe funcționalități noi, fără să țină cont că technical dept crește la fiecare iterație. În schimb, acesta observă la fiecare nouă iterație că schimbările necesită mai mult timp și că oamenii noi pe proiect înțeleg codul din ce în ce mai greu. Totodată oamenii care până acum erau deschiși să integreze funcționalități noi sau să modifice funcționalități deja existente încep să trimită înapoi orice cerință nouă. Dacă echipa și stakeholder-ul ar fi apelat la analiza metricelor, ar fi putut detecta din timp problemele și ar fi investit resurse pentru a îmbunătăți calitatea codului.
Sonar este o platformă care ne ajută să facem management la calitatea codului unui proiect. Acesta este un proiect open source pe care oricine îl poate folosi fără nici un fel de restricție.
Ca platformă, Sonar ne aduce o multitudine de metrice la distanța unui click. Pe baza analizei codului, putem să generăm diferite rapoarte și să identificăm posibilele defecte pe care le putem avea în cod.
Ceea ce face Sonar extrem de bine este să transmită toată această informație într-un mod simplu și accesibil tuturor. Orice membru din echipă poate să acceseze aceste metrici, să identifice exact metoda sau linia de cod care a generat problema fără să fie nevoie să ruleze tool-uri complexe sau să facă analize greoaie.
În acest moment este foarte important de menționat că informația și rapoartele pe care Sonar le generează sunt utile atât dezvoltatorilor cât și managementului. Acesta poate foarte ușor să își dea seama care este starea codului, a proiectului și ce s-a întâmplat cu acesta în ultima perioadă de timp.
Metricele pe care le analizează Sonar acoperă șapte axe importante:
Pe lângă aceste șapte axe există și șapte "death sins" pe care un dezvoltator le poate face :
Sonar ne permite să facem management la diferite metrici - așa numitele profile de calitate. Fiecare profil de acest fel poate să fie activat sau dezactivat în funcție de ce necesități avem. Prin acest mod putem să personalizăm rapoartele care se generează doar cu informația de care noi avem nevoie.
În următoarea parte a articolului vom analiza dashboad-urile pe care le avem la dispoziție. Fiecare din acestea se regăsesc în cele șapte axe pe care Sonar le are.
Sonar poate să identifice codul duplicat pe care aplicația noastă îl are. Acesta ne oferă posibilitatea să navigăm de la nivel de pachet până la nivel de linie de cod și să identificăm codul duplicat. Acesta ne evidențiază toate zonele din cod care conțin codul duplicat pe care noi îl analizăm.
Așadar este foarte ușor să identificăm codul duplicat dar să-l evidențiem și pe cel care a introdus codul duplicat și în ce zone din cod.
Acestea nu se referă doar la modul în care denumit o metodă ci și ce trebuie să facem cu o resursă unmanaged, manipularea unei excepții, detectarea și tratarea unei valori null și așa mai departe.
Prin acest dashborad ne este foarte ușor să facem îmbunătățiri de cod, fără să analizăm fiecare linie din cod.
Avem posibilitatea să detectăm care este nivelul de acoperire cu teste a codului pe care îl avem la toate nivele (pachete, clase, metode) și dacă testele au trecut cu succes.
În plus, Sonar ne permite să vedem dacă pentru codul nou adăugat s-au adăugat test. Cu toți știm că dezvoltatorii spun despre codul vechi că nu era acoperit teste, dar cu acest instrument putem să identificăm codul nou care nu este acoperit de teste.
Sonar permite să vizualizăm complexitatea codului din punct de vedere a metodelor, claselor și a fișierelor. Sonar ne permite în orice moment să adăugăm metrice noi. Vă invit să vă jucați cu aceste metrici și să vedeți ce însemnă fiecare dintre aceste metrici.
Acesta detectează modul în care codul a fost comentat (dacă a fost comentat) și validează aceste comentarii. Sonar separă acest capitol în doua părți. Detectează automat API care este public și gradul de documentație la nivelul acestuia. Totodată focalizează codul și analizează dacă acest cod este comentat precum și calitatea acestuia (dacă comentariile conțin cod comentat).
În următoarele rânduri vom prezenta succint cele mai relevante valori pe care Sonar le detectează.
Package Tangle Index - prin acest indice detectăm dependințele (circulare și non-circulare) care pot să existe între diferite componente ale aplicației noastre. Acesta ne va indicat cât de ușor putem să facem modificări asupra unui anumit pachet.
Dependencies to cut - este o metrică care ne indică numărul dependințelor care trebuie tăiate. Nu doar atât, dar putem să navigăm la pachetele și fișierele unde avem aceste dependințe.
O altă metrică care este foarte relevantă este Technical Dept. Acest indice ne spune în zile (și financiar) care este costul pentru a face mentenanță sau dacă trebuie să modificăm codul. Teoretic, această valoare trebuie să fie ținută cât mai mică. În cadrul acestei metrici intră în proporții diferite: nivelul de cod duplicat, acoperirea cu teste, complexitatea codului, nivelul de comentarii și numărul de violări a code standards.
Un alt punct forte a Sonar este extensibilitatea. Pe lângă numărul mare de extensii care există pe piață, acesta ne permite foarte ușor să creăm o extensie nouă sau să adăugăm sau să modificăm o metrică deja existentă. Rulând ca o aplicație web, Sonar poate să fie accesat de către orice membru al echipei. Mai este nevoie să menționăm că din fiecare dashboard putem să navigăm în cod foarte ușor. Pornind de la o metrică la nivel de pachet, putem să ajungem la nivel de clasă, metodă și chiar linie de cod, putem să asignăm diferite probleme la colegi și să generăm issues-uri în diferite sisteme în care suntem integrați.
În concluzie, Sonar sau un tool asemănător cu acesta nu ar trebui să lipsească din nici un proiect. Sonar ne permite să detectăm schimbarea calității codului în timp și zonele din proiect unde calitatea codului scade.
Vă invit să vă jucați cu următorul demo pentru a descoperi lumea Sonar: nemo.sonarqube.org/dashboard/
de Ovidiu Mățan
de Irina Rotaru
