ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 142
Numărul 141 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 19
Abonament PDF

Sonar

Radu Vunvulea
Solution Architect
@iQuest



PROGRAMARE

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

De ce code metrics?

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.

Cele mai importante metrice

Există destul de multe metrice care formează code metrics. Din punctul meu de vedere, cele mai cunoscute sunt:

  • Complexitate ciclomatică (Cyclomatic complexity) ,
  • Indexul de mentenabilitate (Maintainability index) ,
  • Adâncimea de moștenire (Depth of inheritance) ,
  • Nivelul de cuplare a claselor (Class coupling) ,
  • Numărul de linii de cod (Lines of code) .

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.

Avantajul analizării metricelor

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

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.

Puncte forte

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.

Cele 7 Axe

Metricele pe care le analizează Sonar acoperă șapte axe importante:

  1. Cod duplicat - detectarea automată a codului duplicat.
  2. Standarde de cod - respectarea standardelor de cod care există la nivel de proiect.
  3. Unit teste - nivelul de cod care este acoperit de unit teste.
  4. Complexitatea codului .
  5. Potențiale bug-uri - detectarea automată a codului care poate să genereze probleme.
  6. Comentarii la cod - nerespectarea standardelor din punct de vederea a comentariilor (nu doar ce se comentează și cum, ci și detectarea codului comentat care a fost împins în source control) .
  7. Arhitectură și design - validarea arhitecturi și designului pe care proiectul îl are.

Pe lângă aceste șapte axe există și șapte "death sins" pe care un dezvoltator le poate face :

  1. Să introducă cod duplicat.
  2. Să nu respecte best practice și standardele de cod de pe proiect.
  3. Să nu comenteze codul și API public expus de aplicație.
  4. Să creeze componente complexe, greu de înțeles și care sunt greu de menținut.
  5. Să nu aibă codul (în special cel complex) acoperit de teste.
  6. Să introducă cod care poate să genereze posibile bug-uri.
  7. Să aibă un design sub forma unor spaghete, unde fiecare componentă accesează orice altă componentă.

Metrice

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.

Cod duplicat

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.

Standarde de cod și Potențiale bug-uri

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.

Unit teste

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.

Complexitatea codului

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.

Comentarii la cod

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

Arhitectură și design

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

Să nu uităm că …

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.

Concluzie

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

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects

INTERVIURI VIDEO