Sonar-nyílt forráskódú projekt és a kód minőségének ellenőrzése
Olivier Gaudin, Freddy Mallet, SonarSource, http://www.sonarsource.com
mi az a szonár ?
a Sonar (ma SonarQube) egy nyílt forráskódú platform, amelyet a fejlesztőcsapatok használnak a forráskód minőségének kezelésére. A Sonar-t egy fő cél szem előtt tartásával fejlesztették ki: a kódminőség-menedzsment mindenki számára elérhetővé tétele minimális erőfeszítéssel.
mint ilyen, a Sonar kódelemzőket, jelentési eszközöket, hibakereső modulokat és TimeMachine-t biztosít alapvető funkcióként. De egy plugin mechanizmust is elindít, amely lehetővé teszi a közösség számára a funkcionalitás kiterjesztését (több mint 35 plugin áll rendelkezésre), így a Sonar a forráskód minőségének egyablakos ügyintézésévé válik, nemcsak a fejlesztők, hanem a vezetők igényeinek kielégítésével is.
a nyelvek szempontjából a szonár támogatja a Java elemzését a magban, de a JavaScript, a PHP, a PL/SQL és a Cobol plugineken keresztül (nyílt forráskódú vagy kereskedelmi), mivel a jelentési motor nyelvi agnosztikus.
a 2.0 verzió óta a szonár lehetővé teszi a minőség lefedését 7 tengelyen, és így jelentést tesz:
- duplikált kód
- kódolási szabványok
- egység tesztek
- komplex kód
- lehetséges hibák
- tervezés és Építészet
szonár lehet használni egyszeri ellenőrzések, de úgy tervezték, hogy támogassa a globális folyamatos fejlesztési stratégia kód minősége a vállalat, ezért lehet használni, mint egy közös központi adattár a minőségirányításhoz.
weboldal: https://www.sonarqube.org/
Termékverzió: Sonar 2.0
licenc: LGPL V3
támogatás: https://www.sonarsource.com/support/
Plugins: https://docs.sonarqube.org/display/PLUG/Plugin+Library
miért kell kezelni a forráskód minőségét?
egy jól megírt program egy olyan program, ahol a költség végrehajtási funkció állandó az egész program élettartama — Itay Maman
mint egy gyors intro, ez a legjobb meghatározása forráskód minősége találtam. Ez lesz még erősebb, ha fel a másik irányba: abadly írásbeli program egy olyan program, ahol a költségek végrehajtási funkció növekszik az egész idő alatt.
ez rosszul hangzik, nem?
mindannyian láttunk olyan helyzeteket, amikor egy új projekt indul, amelynek célja az, hogy a semmiből dolgozzon ki egy alkalmazást egy vezető edgetechnológiában. Minden nagyon gyorsan megy; első, második, harmadik kiadás, majd minden hirtelen, a csapat sebessége csökkenni kezd. A negyedik kiadás elhalasztódikharmadik alkalommal, valami rögzítése valami mást tör…
mi történik itt? Tekintettel a tünetekre, feltételezhetjük, hogy a csapat többek között technikai adósságtól szenved, és hogy az érdekelt felek nem tudnak róla, ezért nem tudnak foglalkozni vele.
de ez valószínűleg megoldódik, mivel a projekt Új, látható, ezért valaki gondoskodni fog róla (Legalábbis reméljük).
de ez a példa csak kezdő volt, mivel mi, informatikai emberek, időnk nagy részében nem dolgozunk olyan alkalmazásokon, amelyek fejlesztése kevesebb, mint 6 hónapja kezdődött! Munkánk elsősorban a meglévő alkalmazások frissítéséből áll. Ez az, ahol a legtöbb pénzt költik el benne, ahol kevésbé látható, ahol gyakran van egy nagy éves boríték, hogy annyit tegyünk, amennyit csak tudunk,ahol vannak olyan emberek, akik kulcsfontosságúak, mert ők az egyetlenek, akik képesek megérteni a kódot, ahol fogalmunk sincs, mennyi ideig tart a változás, ahol a regressziók gyakoriak, és az emberek félnek változtatni. És alapvetően nincs semmiféle figyelem az üzletről, csak csináld!
a forráskód minőségének kezelése a ROI optimalizálásáról szól, mivel láthatóságot és ezért nagyobb ellenőrzést biztosít:
- milyen nehéz karbantartás lesz, mit várhatunk
- az a tény, hogy a dolgok nem egyre rosszabb
- az a tény, hogy némi figyelmet kell fordítani a kritikus része a rendszer, hogy növelje például lefedettség egység tesztek, elnyomja ciklusok, távolítsa duplikációk
további több ez ad egy biztonsági mentés a fejlesztők, hogy emelje fel a kezét, ha úgy vélik, néhány refaktorálásra van szükség, amely egy kicsit megváltoztatná a változást, de jó megtérüléssel járna.
hogyan kezeljük a forráskód minőségét?
hét technikai tengelyt kell megvizsgálni egy projekt forráskódelemzésekor, és a szonár képes mind a hét irányítására. A Sonar csapatban szeretjük őket a fejlesztő 7 halálos bűnének nevezni:
- a kódolási szabványok és a legjobb gyakorlatok be nem tartása
- a forráskód megjegyzéseinek hiánya, különösen a nyilvános API-kban
- a kódsorok duplikálása
- összetett összetevővel vagy/és a komplexitás rossz eloszlása az összetevők között
- az egységtesztek nem vagy alacsony kóddal rendelkeznek, különösen a Program összetett részében
- potenciális hibák elhagyása
- spagetti tervezéssel (csomagciklusok…)
a forráskód minőségirányításának első lépése az, hogy meghatározzuk, melyik tengely fontos az Ön számára,és milyen mértékben.Ezután a jelenlegi helyzet alapján tervet kell kidolgozni a célszint elérésére (ez lehet egyszerűen a magas minőségi szint fenntartása). Nagyon fontos, hogy kicsi legyen, és nagyobb legyen, amikor az egész fejlesztői csapat teljes mértékben elfogadja.
most nézzük meg, hogyan kell használni a Szonárt ebben a megközelítésben.
minőségi profilok
a Sonar lehetővé teszi több minőségi profil kezelését annak érdekében, hogy a szükséges szintet a projekt típusához igazítsa (csak támogatás,új projekt, kritikus alkalmazás, MŰSZAKI lib…). A profil kezelése a következőkből áll:
aktiválás / deaktiválás / súlykódolási szabályok
határozza meg az automatikus riasztáshoz szükséges mutatók küszöbértékeit
határozza meg a projekt / profil társítást
irányítópultok
a szonár 2 irányítópultot tartalmaz, amelyek a teljes képet adják, hogy tippeket kapjanak, ahol problémák merülhetnek fel, és összehasonlítsák a projekteket:
- összevont nézet, amely az összes projektet mutatja
- a projekt irányítópultja modulok és csomagok szintjén is elérhető
Vadászeszközök
annak megerősítésére, hogy ami problémának tűnik, az valóban probléma, a Sonar egy vadászati eszközkészletet kínál, amely lehetővé teszi, hogy az áttekintésből a legkisebb részletekbe menjen:
- fúrjon le minden megjelenített intézkedést, hogy megnézze, mi van a
- osztályok felhők, hogy megtalálja a kevésbé lefedett osztályokat az egységtesztek szerint
- hotspotok, hogy egy oldalon a legtöbb és a legkevesebb fájl
- és egy többszörös bejegyzés (duplikáció, lefedettség, jogsértések, tesztek sikere…) forrás nézőt, hogy erősítse meg a megállapításokat tett a vadászati eszközök
TimeMachine
nem kétséges, hogy tudta, hol egy alkalmazás áll nagyon fontos. De még ennél is fontosabb, hogy megismerjük és megértsük a fejlődését.Valóban, mit érdemes tudni, hogy a unittests kódfedettségének 20% – a van? Jó vagy rossz? Más a válasz, ha két hónappal ezelőtt 15 vagy 25% volt? A TimeMachine lehetővé teszi az evolúció megfigyelését és a múlt visszajátszását, különösen mivel a projekt verzióit rögzíti
hogyan működik a Sonar?
a szonár meglehetősen egyszerű és rugalmas architektúrából készül, amely három összetevőből áll:
- egy sor forráskód elemző, hogy vannak csoportosítva egy Maven plugin és váltja igény. Az analizátorok az adatbázisban tárolt konfigurációt használják. Bár a Sonar a Maven-re támaszkodik az elemzés futtatásához, képes elemezni a Maven és a nem Maven projekteket.
- egy adatbázis, amely nemcsak az elemzés eredményeit, a projekteket és a globális konfigurációt tartja fenn, hanem a TimeMachine történeti elemzését is. Jelenleg 5 adatbázis-motor támogatott: Oracle, MySQL, Derby (csak demo), PostgreSQL és MS SQLServer
- webes jelentéskészítő eszköz a projektek kódminőség-irányítópultjainak megjelenítéséhez, hibák kereséséhez, TimeMachine ellenőrzéséhez és az elemzés konfigurálásához.
az analizátorok részeként a Sonar core elindítja a legjobb fajta eszközöket, hogy megtalálja a kódolási szabályok megsértését (PMD, Checkstyle), észlelje a lehetséges hibákat(Findbugs) és mérje a lefedettséget az egységtesztekkel (Cobertura, Clover). De ami igazán egyedivé teszi a Sonar-t, az a Squid, a saját kódelemzője, amely nemcsak a forráskódot, hanem a bájtkódot is elemzi, és összekeveri az eredményeket.
mivel az elemzés egy Maven pluginon keresztül történik, a Sonar könnyen elindítható “folyamatos integráció” környezetben.
Use case on Apache commons-collection project
a Sonar futtatásának előfeltétele, hogy a Java és a Maven telepítve legyen a dobozon. Ha ez a helyzet, 5 egyszerű lépésben futtathatja a Szonárt:
1. Töltse le a terjesztést a https://www.sonarqube.org/letöltések/ és csomagolja ki
2. Nyisson meg egy konzolt, és indítsa el a kiszolgálót:
> $SONAR_HOME kuka windows-x86-32 StartSonar.bat windows
> $SONAR_HOME/bin//sonar.sh más platformokon
3. Nyisson meg egy konzolt, ahol ellenőrizni szeretné a forrást, és futtassa:
svn co http://svn.apache.org/viewvc/commons/proper/collections/trunk/.
4. Futtassa az mvn install sonar:sonar programot ugyanabban a könyvtárban
5. Tallózás http://localhost:9000
az alkalmazás kezdőlapja a minőségellenőrzés alatt álló projektek listáját mutatja néhány konfigurálható mutatóval.
a nagyításhoz egyszerűen kattintson a projektre, és megkapja az Irányítópultot
innen Van hozzáférése egy sor vadászati eszközök, amelyek között:
a hotspot, hogy megtudja, a fájlokat, amelyek “a legtöbb” vagy “a legkevésbé” …
de az irányítópult bármely mutatójára kattinthat, hogy a jelenet mögé ugorjon, és képet kapjon a mutatóról az alapul szolgáló komponens alapján
minden vadászati eszköz végül eljuttatja a vadászt a forráskódhoz, ahol a zsákmányokat kiemelik
a szonár ökoszisztéma
nagyon dinamikus ökoszisztéma van a szonár körül
- egy aktív közösség, amely 300+ emberből áll a felhasználói levelezőlistán és 150 + emberből a fejlesztési levelezőlistán
- 35 + plugin a forge-on (http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/), amelyek megosztottak négy kategóriába
- integráció külső eszközökkel, például Jira, Hudson, Bamboo, GateIn, AnthillPro, Crowd
- az alapvető funkciók közvetlen kiterjesztése új viselkedés hozzáadásával, fejlett metrikák kiszámításával vagy projektek konszolidálásával, új metrikák hozzáadásával
- adjon hozzá lefedettséget olyan nyelvekhez, mint PL/SQL, ActionScript3
- integráció az ide-kkel, hogy hibákat kapjon a kódról, amikor szerkesztésre kerül
- 3000+ letöltés havonta
- a Sonarsource által vezetett központi fejlesztőcsapat (http://www.sonarsource.com)
következtetés
tömeges elfogadása után a folyamatos integrációs motorok és a tesztek által vezérelt fejlesztési gyakorlatok, a forrásminőség kezelése természetes következő lépésnek tűnik a fejlesztőcsapatok számára az iparosítás érdekében. A szonár lehetővé teszi, hogy ezt a célt kevés erőfeszítéssel és szórakozással érje el.
2010-ben a Sonar platform tovább fog fejlődni, a fejlesztés fő tengelyei az új nyelvek lefedése és az ide-kkel való integráció javítása.