În articolul din numărul trecut am analizat modul cum putem să măsurăm metricele software folosind Sonar. Acesta este un tool care poate fi util liderului echipei cât și restului echipei. Orice membru din echipă poate extrem de ușor să verifice pe interfața web a Sonar-ului care este valoarea la diferite metrice.
Dacă folosim ca mediu de dezvoltare Visual Studio 2013 vom descoperi că avem opțiunea de a calcula o parte dintre metrici direct din Visual Studio, fără să fim obligați să folosim alte aplicații sau tool-uri. În cadrul acestui articol vom descrie metricele pe care le putem calcula folosind direct ceea ce ne pune la dispoziție Visual Studio.
Acest tip de tool ne ajută să detectam posibilele probleme pe care aplicația noastră le are, informându-ne în același timp și asupra calității codului pe care l-am scris. Așa cum se va vedea în rândurile de mai jos, toate regulile și recomandările pe care Microsoft le are legate de cod se regăsesc în acest tool.
O parte dintre defectele pe care le descoperă un astfel de tool sunt uneori extrem de greu de găsit folosind unit teste. Datorită unui tool de acest gen, putem avea certitudinea că aplicația pe care o scriem este de calitate.
Începând cu Visual Studio 2013, toate versiunile de Visual Studio (mai puțin Visual Studio Test Professional) ne oferă posibilitatea să calculăm metricele direct din el. De la bun început trebuie să știm că numărul de metrici pe care le putem calcula folosind Visual Studio este limitat. Din păcate, nu avem posibilitatea să calculăm toate metricele care sunt disponibile în Sonar, dar există câteva extensii pentru Visual Studio care ne ajută să calculăm și alte metrice, nu doar pe cele care există în Visual Studio.
Visual Studio ne permite să calculăm o parte dintre metrice folosind Static Code Analysis. Acesta analizează codul încercând să ofere dezvoltatorilor date despre proiect și codul pe care l-au scris, înainte ca aceștia să îl înainteze spre source control. Pe baza acestei analize putem să identificăm posibile probleme legate de:
Sau multe alte probleme. Totul ține și de abilitatea pe care o are dezvoltatorul pentru a interpreta aceste metrice. Un aspect interesant la acest analizator este faptul că toate regulile și recomandările pe care Microsoft le are legate de cod, de stilul codului și de modul în care trebuie să folosim diferite clase și metode se regăsesc în acest analizator. Toate aceste reguli sunt grupate în diferite categorii.
Prin acest mod identificăm cu ușurință zone din aplicația noastră care nu folosesc un API așa cum ar trebui. În cazul în care doriți să creați o regula specifică veți avea nevoie de Visual Studio 2013 Premium sau Ultimate. Aceste două versiuni de Visual Studio ne permit să adăugăm reguli noi, specifice proiectului sau companiei în care lucrăm. Odată aceste reguli adăugate, analizatorul de cod va verifica dacă acestea sunt respectate, avertizându-ne în cazul unei abateri de la reguli. Din păcate în acest moment putem să analizăm doar codul scris C#, F#, VB și C/C++.
O parte dintre cititori ar putea să spună că acest lucru se putea face și în versiunile mai vechi de Visual Studio. Se poate subscrie la afirmația lor, dar trebuie adăugat că această nouă versiune (2013) a adus în plus posibilitatea de a analiza codul fără să fie nevoie să îl executăm. Acest lucru se putea mai mult sau mai puțin și în Visual Studio 2012.
Aceste tool-uri pot să fie rulate în diferite moduri, atât manual din meniul "Analyze" cât și în mod automat. Pentru a le putea rula în mod automat este nevoie să selectăm opțiunea de "Enable Code Alalysis on Build" pentru fiecare proiect pe care dorim să îl analizăm.
O altă opțiune destul de interesantă este să activăm din TFS un policy prin care dezvoltatorul să fie obligat să ruleze acest analizator înainte ca acesta să poată să facă check-in pe TFS. Această opțiune se poate activa din zona "Check-in Policy", unde este nevoie să adăugăm o nouă regulă de tip "Code Analysis".
Trebuie să conștientizăm că enforsarea unei astfel de reguli nu ne garantează că dezvoltatorul își va citi raportul care se generează și că va ține cont de el. Tot ceea ce ni se garantează este că acest raport a fost generat. De aceea fiecare echipă trebuie educată să valorifice aceste rapoarte și să le analizeze în momentul în care ne decidem să folosim astfel de tool-uri.
În momentul în care facem enforce la acestă regulă avem posibilitatea să selectăm ce reguli nu trebuie încălcate când se face un chec-in pe TFS. De exemplu, nu se va putea face check-in pe TFS la un cod ce foloseste o instanță a unui obiect ce implementează IDisposable fără să apeleze și metoda Dispose.
Când dezvoltatorul va încerca să facă check-in la un cod care nu respectă una dintre reguli, va primi o eroare care nu îi va permite să trimită pe TFS modificarea fără să rezolve problema.
La fel de bine, avem posibilitatea să rulăm acest tool și ca parte din buid. Pentru aceasta este nevoie să activăm această opțiune din Build Definition.
Rezultatul rulării acestui tool este un set de warning-uri. Cele mai importante informații pe care un warning le conține sunt:
Fiecare warning ne permite să navigăm exact la linia de cod unde este această problemă. În plus, pentru fiecare warning avem un link la MSDN care prezintă în detaliu cauza warning-ului și ceea ce putem face pentru a-l elimina.
Așa cum am menționat în rândurile de mai sus, crearea de reguli custom se poate face doar din Visual Studio Premium sau Ultimate. Apoi este nevoie să mergem în "New>File>General>Installed Templates>Code Analysis Rule Set".
Odată ce avem o regulă blank, putem să specificăm diferite proprietăți pe care noi dorim să le aibă.
Pe lângă acest tool în Visual Studio avem la dispoziție alte două tool-uri interesante.
Acest tool ne permite să detectăm automat codul care este duplicat. Important de precizat este că există mai multe tipuri de cod duplicat (clonat) pe care acesta poate să îl detecteze:
Pe lângă aceste informații, putem să știm pentru fiecare cod duplicat, în câte locații acesta este duplicat și putem naviga până la linia de cod unde acesta apare. O altă metrică eficientă este numărul total de linii duplicat (clonat). Apelând la această metrică ne putem da seama destul de ușor de câte linii de cod am putea să scăpăm.
Prin intermediul acestui tool analizăm fiecare proiect pe care îl avem în soluție și extragem diferite metrice. Fiind un tool integrat cu Visual Studio, putem să navigăm în fiecare proiect și să vedem valoarea fiecărei metrice de la nivel de proiect, până la nivel de namespace, de clasă și metodă.
Există cinci metrice analizabile folosind Code Metrics:
În acest articol am descoperit că și Visual Studio ne pune la dispoziție diferite metode pentru a verifica calitatea codului. Unele dintre aceste tool-uri sunt disponibile în versiuni normale de Visual Studio, iar altele doar în varianta Ultimate. În comparație cu Sonar, Visual Studio nu permite efectuarea de share la aceste metrice prin intermediul unui portal. În schimb, ne permite să le exportăm într-un Excel pentru a le putea trimite la echipă. Tool-urile din Visual Studio sunt un bun început pentru orice echipă sau dezvoltator care vrea să se informeze asupra calității codului scris de el sau de echipă.