A stabilizációs projekt során feltárt hibákból jól látszott, hogy a problémák nagy része olyan programozói hibákra vezethetők vissza, amelyek manuális kód review-k nélkül is, statikus kód ellenőrzők használatával kimutathatóak lettek volna. Csak néhányat említve: System.gc() és Runtime.exec() hívások, túl szinkronizált metódusok, elfelejtett timeout-ok, tipikus naplózási problémák.
Az ehhez hasonló problémák elkerülésére az automatizált kód ellenőrzés bevezetését és néhány környezetspecifikus kódellenőrző plugin elkészítését javasoltam. Mivel hatalmas a kódbázis és sok projekt kezelésére kellet megoldást találnom egy olyan eszközt kerestem, ami biztosítja az egységes konfigurációt és nézetet, lehetőséget ad a hibákhoz való lefúráshoz a kódban, biztosítja a hibák időbeli követését és persze nyílt forráskódú. A választásom egyértelműen a Sonar platformra esett, a statikus kód ellenőrzések automatizált meghajtásához pedig a Jenkins-t javasoltam.
A Jenkins-ről már korábban blogoltam, most pedig a Sonar következik! A Sonar egy nyílt platform a forráskód minőségének vizsgálatához, ami összefogja a legfontosabb kódanalizáló eszközök használatát (FindBugs, PMD, CheckStyle) és egy egységes felületet biztosít a használatukhoz. A külső kódanalizálók mellett a Sonar egy saját fejlesztésű Squid analizátort is használ, aminek a feladata az standard metrikák pl.: RFC, LCOM4, NOC meghatározása.
Az analizálások eredményét és azok alakulását a webes felületen időben is nyomon követhetjük, ami kifejezetten hasznos amikor bizonyos metrikákra vonatkozó trend-eket akarunk vizsgálni. A rengeteg hasznos feature-ből érdemes kiemelni a projektekhez való szerep alapú hozzáférést, a projekten belüli és a projektek közötti kód duplikáció vizsgálatot, az eltérő kódanalizáló eszközök standardizált prioritási szint kezelését és a saját fejlesztésű komponensekkel történő kiegészíthetőséget is.
A Sonar az alapértelmezett Java mellett többféle nyelv analizálását is támogatja (XML, JavaScript, C, C#, PHP, Python, PL/SQL, COBOL, VB6), valamint lehetőséget ad saját nyelvekkel való bővítésre is. A forráskódok elemzése kiterjed az architektúra és tervezés, kommentek, kódolási szabályok, potenciális bug-ok, kód duplikációk (akár projektek között is), unit tesztek, teszt lefedettség és a kód komplexitás követelményeire is.
Működését tekintve a Sonar egy konténerben futó java web-alkalmazás, amit a Jenkins-hez hasonlóan standalone alkalmazásként is elindíthatunk. A webes felületen keresztül nincs lehetőség új projektek felvételére, azok a legelső analizálás lefuttatásakor kerülnek rögzítésre. A webes felület mellett a Sonar Eclipse plugin segítségével a fejlesztői gépeken is végrehajthatjuk a kódellenőrzést (távoli vagy lokális módban) így akár az IDE-ben is ráugorhatunk a hibás kódrészletre.
A kódanalizálást a Sonar Runner modullal (maven plugin, ant vagy java runner) indíthatjuk el felparaméterezve az adott típusú analizáláshoz szükséges információkkal. (1. lépés) A webes felületen definiált Quality Profile-ban előírt szabályokat felhasználva a 2. lépésben végrehajtódik a forráskódok analizálása, majd a 3. lépésben az analizálás eredménye beíródik a Sonar saját adatbázisába. Miután lefutott az analizálás, a Sonar webes felületén keresztül elérhetjük az analizálás eredményét, amit a Sonar a 4. lépésnél is jelzett adatbázisából fog kinyerni. Az aktuális analizálás eredményeit az Eclipse felületéről is elérhetjük a Sonar Eclipse plugin segítségével. (5.)
A Sonar részletesebb megismeréséhez érdemes átolvasni a dokumentációt, körbenézni a demo oldalon és az elérhető Sonar kiegészítők között!
Szokás szerint nagyon jó cikk!
VálaszTörlésAmit még érdemes megemlíteni a Sonar-ral kapcsolatban, hogy képes a CI-ben futó build-et megakasztani. Így egy commit után, ha bizonyos értékek túllépnek egy thresholdot (pl. a copy-paste, vagy túl kevés comment), a build nem fog lefutni, hibát dob.
Pl. két klikkből be lehet állítani, hogy hibát jelezzen, ha a kódban System.out van, és így tovább. Ekkor a fejlesztőnek azonnal megy az e-mail, hogy a commit-jában hiba van.
Köszi!
TörlésIgen, a Build Breaker plugin valóban hasznos lehet az általad is említett általános jellemzők esetén, bár amikor legutóbb néztem, konkrét szabályokhoz még nem lehetett olyan alert-eket rendelni amik a build-et megakasztanák!
Nekem egy apro problemam van a sonar-ral, az hogy keptelen vagyok ravenni a munkatarsaimat hogy ranezzenek :-(
VálaszTörlésEzzel a problémával nem vagy egyedül, amíg nem kötelező ezeket betartani (mint pl. átvételi követelmény) sajnos sokan nem foglalkoznak vele.
TörlésA Sonar altal minor/major/akarmi hibakat alaposabban megnezve pedig nagyon sok érdekes-hasznos dolgot lehet felszedni. Pontosan elmagyarázza, hogy miért gondolja rossznak azt, amit rossznak jelöl meg.
VálaszTörlésEgyetértek, jómagam is sokat tanultam a felderített hibákból!
TörlésA legszebb az egészben, hogy a saját best/worst practice-k implementálhatók plugin-ként, így ezek is betarthatók ill. kimutathatók lesznek a Sonar-ral.