2013. február 21., csütörtök

Sonar - A metrikák értelmezése 1.

A múltkori Sonar bevezető után a következő néhány bejegyzésemben a Sonar által mért jellemzőkről és azok értelmezéséről fogok írni. Az analizálások során begyűjtött információk alapján nemcsak az aktuális állapotot, hanem a korábban mért adatokat is megtekinthetjük, így lehetőség adódik a jellemzők alakulásának, a trendeknek a követésére!

Ha a Projects Dashboard-on ráklikkelünk valamelyik projektre, akkor eljuthatunk a kiválasztott projekt alapértelmezett dashboard-jához, aminél a megjelenő widget-eket a Configure widgets menüponton keresztül állíthatjuk be. Érdemes megemlíteni, hogy a widget-ek módosításával nemcsak az aktuális projekt dashboard-ját, hanem az összes ugyanilyen típusú projekt dashboard-ját is módosítjuk! A felmerült igényeink szerint akár újabb dashboard-okat is létrehozhatunk és megoszthatunk másokkal is.


Lines Of Code, Classes

A Lines Of Code/Classes widget segítségével megtudhatjuk, hogy a kiválasztott projekt hány forrás fájlt, kódsort, osztályt, csomagot, vezérlési szerkezetet és metódust tartalmaz. Ezek a metrikák jól mutatják a projekt méretét, ami legtöbbször arányos a projektben előforduló hibák számával is. A méret metrika magasabb értékei tehát összetettebb projektet jelölnek! A tapasztalat azt mutatja, hogy a giga projektekkel szinte mindig komoly problémák vannak, így ezek külön odafigyelést igényelnek!

Violations, Violation Density

Talán ez az egyik leggyakrabban használt widget, amellyel 5 prioritási szintbe sorolva megtekinthetjük a projekthez rendelt Quality Profile-ban rögzített kódolási szabályok sértéseit. A prioritási szintekre kattintva esetleg a Violations Drilldown menüpontot kiválasztva az egyes szabálysértések szerint lefúrhatunk a forráskód szintjéig is, sőt ajánlásokat is kapunk a hibák kijavításához. A kódolási szabályoknál nem feltétlenül a kijelzett hibák számát kell mérvadónak tekinteni, hanem a blokkoló és kritikus szintű hibák típusait és mennyiségét, mivel ezek bírnak nagyobb jelentőséggel. Ebből következik, hogy a szabályok priorizálására mindig szánjunk időt!

Comments and Duplications

A Comments and Duplication widget komment oszlopa megmutatja a kommentezett sorok számát és a java dokumentációval ellátott API-k arányát, a duplikátum oszlop pedig nemcsak egy adott forráskódon belüli duplikált kódrészeket jelzi ki, hanem az adott projekt fájljai és más projektek fájljai közötti duplikációkat is!

A Sonar korábbi verziói a PMD-CPD (Copy Past Detector) –t használták a duplikációk kijelzésére, azonban a magas memória használat és a projektek közötti duplikátum keresés hiánya miatt egy Sonar-CPD modul kifejlesztése mellett döntöttek a Sonar fejlesztői, így a legfrissebb Sonar verzióban már ez az engine dolgozik.

A kommentek magas száma általában negatívumnak tekinthető (lásd Clean Coding Technikák írásomat) mivel a sok magyarázat arra utal, hogy a forráskód nem önleíró, annak megértéséhez további információk szükségesek. Mivel a kódok módosításával a kommenteket is mindig aktualizálni kellene (ami rendszerint elszokott maradni) ez a fejlesztőktől plusz munkát is igényel. A java dokumentációk megléte viszont pozitívumnak tekinthetők, mivel más fejlesztők gyorsabban megérthetik az API felhasználását. A kódbeli duplikációkat pedig mindenféleképpen érdemes megszüntetni, mivel ez a rossz kódolási szokás nagyon megnehezítheti a forráskód későbbi aktualizálását, ugyanis azt több helyen is végre kellene hajtani. A Sonar képes rámutatni a projekten belüli és a projektek közötti duplikációkra is, ami egy kifejezetten hasznos feature.

4 megjegyzés:

  1. Sonar rulz! Csak sajnos meg sem szeretik nezegetni az emberek, mert tul realis kepet fest :)

    VálaszTörlés
    Válaszok
    1. A probléma nekem is ismerős!

      Azt szoktam javasolni, hogy egy jó nagy kijelzőre ki kell tenni a projekteket a fontosabb minőségi jellemzők (blokkoló hibák száma, kód duplikációk száma,...) szerint csökkenő sorrendben a fejlesztő cég/vezető fejlesztő nevével együtt!

      Mivel ezt mindenki látja, és ugye az 1. helyen senki sem szeretne lenni hamarosan oda fognak rá figyelni! :)

      Törlés
  2. Nemrég felvetettem a melóhelyen, hogy használjuk a Sonart CI-ben. Élesen kétféle táborba csoportosultak az emberek:
    1. Király, csináljuk. Már tegnap el kellett volna kezdeni.
    2. Minekaz, úgyis tudjuk hogy gáz a kódunk, ki nézné a riportokat?
    Persze ez nem gátol meg engem és mást sem a lokális futtatásban. Szerintem egy architect Sonar nélkül vak. Képtelenség átlátni egy több ezer vagy millió soros kódbázist egy ilyen eszköz nélkül.
    Kösz a posztokat!

    VálaszTörlés
    Válaszok
    1. Nagyon ismerős a helyzet! A minőségi követelmények kikényszerítése alapvetően a vezető fejlesztő feladata, de érdemes az átadás-átvételi folyamat részeként is alkalmazni a Sonar-t! Ha (súlyos) hibát dob ki, a megrendelő egyszerűen nem veszi át a szoftvert!

      Egyébként pont itt jön a képbe a dynaTrace Test edition-ja is, mert amíg a Sonar a kód statikus jellemzőit tudja kijelezni, addig a dynaTrace a dinamikus metrikákra fókuszál, pl. a legfrisebb release-ben megnövekedett a lekérdezések ideje és a kivételek száma, de az új JQuery verzió nagyban lecsökkentette a kliens oldalon eltöltött időt, a JS-ek gyorsabb végrehajtásával...

      Törlés

Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.