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.
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.
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.
Sonar rulz! Csak sajnos meg sem szeretik nezegetni az emberek, mert tul realis kepet fest :)
VálaszTörlésA probléma nekem is ismerős!
TörlésAzt 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! :)
Nemrég felvetettem a melóhelyen, hogy használjuk a Sonart CI-ben. Élesen kétféle táborba csoportosultak az emberek:
VálaszTörlés1. 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!
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!
TörlésEgyé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...