Sonar-Open Source-projekt och Kodkvalitetsövervakning
Olivier Gaudin, Freddy Mallet, SonarSource, http://www.sonarsource.com
Vad är Sonar ?
Sonar (nu kallad SonarQube) är en öppen källkodsplattform som används av utvecklingsteam för att hantera källkodskvalitet. Sonar har utvecklats med ett huvudmål i åtanke: gör kodkvalitetshantering tillgänglig för alla med minimal ansträngning.
som sådan tillhandahåller Sonar kodanalysatorer, rapporteringsverktyg, defektjaktmoduler och TimeMachine som kärnfunktionalitet. Men det inleder också en plugin mekanism som gör det möjligt för samhället att utöka funktionaliteten (mer än 35 plugins tillgängliga), vilket gör Sonar one-stop-shop för källkod kvalitet genom att ta itu med inte bara utvecklare utan även chefer behov.
när det gäller språk Stöder Sonar analys av Java i kärnan, men också av JavaScript, PHP, PL/SQL och Cobol genom plugins (öppen källkod eller kommersiell) eftersom rapporteringsmotorn är språk agnostisk.
sedan version 2.0, ekolod gör det möjligt att täcka kvalitet på 7 axlar och så att rapportera om:
- duplicerad kod
- kodningsstandarder
- enhetstester
- komplex kod
- potentiella buggar
- Design och arkitektur
Sonar kan användas för engångsrevisioner, men har utformats för att stödja global kontinuerlig förbättringsstrategi för kodkvalitet i ett företag och kan därför användas som en delad centralt arkiv för kvalitetsstyrning.
webbplats: https://www.sonarqube.org/
Produktversion: Sonar 2.0
licens: LGPL V3
stöd: https://www.sonarsource.com/support/
Plugins: https://docs.sonarqube.org/display/PLUG/Plugin+Library
varför ska du hantera källkodskvalitet?
ett välskrivet program är ett program där kostnaden för att implementera en funktion är konstant under hela programmets livstid-Itay Maman
som en snabb intro är detta den bästa definitionen av källkodskvalitet jag kunde hitta. Det blir ännu starkare när man sätter tvärtom: abadly written program är ett program där kostnaden för att implementera en funktion växer genom tiden.
det låter dåligt, eller hur?
vi har alla sett situationer där ett nytt projekt startar vars mål är att utveckla från grunden en applikation i en ledande edgetechnology. Allt går väldigt snabbt; första, andra, tredje utgåvan och sedan plötsligt börjar lagets hastighet minska. Fjärde utgåvan är uppskjutenför tredje gången, fixar något bryter något annat…
vad händer här? Med tanke på symtomen kan vi anta att teamet bland annat lider av teknisk skuld och att intressenterna inte är medvetna om det och därför inte kan hantera det.
men det här kommer troligen att lösas eftersom projektet är nytt, har synlighet och därför kommer någon att ta hand om det (åtminstone kan vi hoppas det).
men det här exemplet var bara en starter, eftersom vi, IT-folk, inte arbetar mest av vår tid på applikationer vars utveckling började mindre än 6 månader sedan! Vårt jobb består huvudsakligen av uppgraderingar till befintliga applikationer. Det är där det mesta av pengarna spenderas i det, där det är mindre synlighet, där det ofta finns ett stort årligt kuvert för att göra så mycket vi kan,där det finns människor som är viktiga eftersom de är de enda som kan förstå koden, där vi inte har någon aning om hur lång tid en förändring kommer att ta, där regressioner är frekventa och människor är rädda för att göra förändringar. Och det finns i princip ingen uppmärksamhet alls från verksamheten på det, bara gör det!
hantera källkod kvalitet handlar om att optimera ROI eftersom det kommer att ge dig synlighet och därmed mer kontroll på:
- hur hårt underhåll kommer att bli, vad kan vi förvänta oss
- det faktum att saker inte blir värre
- det faktum att viss uppmärksamhet bör ägnas åt kritisk del av systemet, för att öka till exempel täckning av enhetstester, undertrycka cykler, ta bort dubbletter
vidare ger det en säkerhetskopia för utvecklare att höja sin hand när de tror refactoring krävs som skulle lägga lite till achange men skulle ha bra avkastning.
hur hanterar jag källkodskvaliteten?
det finns sju tekniska axlar som bör ses när man gör källkodsanalys av ett projekt och Sonar kan stödja hanteringen av alla sju. I Sonar-teamet gillar vi att kalla dem utvecklarens 7 dödliga synder:
- icke-respekt för kodningsstandarder och bästa praxis
- saknar kommentarer i källkoden, särskilt i offentliga API: er
- har duplicerade kodrader
- har komplex komponent eller/och en dålig fördelning av komplexitet bland komponenter
- har ingen eller låg kodtäckning genom enhetstester, särskilt i komplex del av programmet
- lämnar potentiella buggar
- med en spaghetti design (paketcykler…)
det första steget när du gör källkodshantering är verkligen att definiera vilka av dessa axlar som är viktiga för dig och i vilken utsträckning.Baserat på den nuvarande situationen bör en plan upprättas för att nå målnivån (det kan helt enkelt vara att hålla en hög kvalitetsnivå). Veryimportant är att börja smått och gå större när det blir fullt antagen av hela utvecklingsteamet.
låt oss nu titta på hur man använder Sonar i detta tillvägagångssätt.
kvalitetsprofiler
ekolod gör det möjligt att hantera flera kvalitetsprofiler för att anpassa den nivå som krävs för att den typ av projekt (endast stöd, nytt projekt,kritisk tillämpning, teknisk lib…). Hantering av en profil består av:
aktivera / inaktivera / viktkodningsregler
definiera tröskelvärden för mätvärden för automatisk varning
definiera projekt / profilförening
instrumentpaneler
Sonar innehåller 2 instrumentpaneler som ger den stora bilden för att få tips där det kan finnas problem och att jämföra projekt:
- en konsoliderad vy som visar alla projekt
- en projektpanel finns också på modul-och paketnivå
jaktverktyg
för att bekräfta att det som verkar vara ett problem verkligen är ett problem, erbjuder Sonar en jaktverktygsuppsättning som gör det möjligt att gå från översikt till smallestdetails:
- borra ner på varje åtgärd som visas för att se vad som ligger bakom
- klasser moln för att hitta mindre täckta klasser av enhetstester
- hotspots att ha på en sida mest och minst filer
- och en multi-entry (dubbelarbete, täckning, kränkningar, tester framgång…) källvisare för att bekräfta resultaten med jaktverktygen
TimeMachine
ingen tvekan om att det är mycket viktigt att veta var en applikation står. Men ännu viktigare är att känna till och förstå dess utveckling.Faktum är att det är värt att veta att det finns 20% av kodtäckningen av unittests? Är det bra eller dåligt? Är svaret annorlunda om det för två månader sedan var 15%eller 25%? TimeMachine gör det möjligt att titta på utvecklingen och spela upp det förflutna, särskilt eftersom det spelar in versioner av projektet
Hur fungerar Sonar?
Sonar är gjord av en ganska enkel och flexibel arkitektur som består av tre komponenter:
- en uppsättning av källkod analysatorer som är grupperade i en Maven plugin och utlöses på begäran. Analysatorerna använder konfiguration lagrad i databasen. Även Sonar förlitar sig på Maven att köra analys, Det är kapabel att analysera Maven och icke-Maven projekt.
- en databas för att inte bara fortsätta resultaten av analysen, projekten och den globala konfigurationen utan också för att hålla historisk analys för TimeMachine. 5 databasmotorer stöds för närvarande: Oracle, MySQL, Derby (endast demo), PostgreSQL och MS SQLServer
- ett webbrapporteringsverktyg för att visa kodkvalitetspaneler på projekt, jaga efter defekter, kontrollera TimeMachine och konfigurera analys.
som en del av sina analysatorer inleder Sonar core Best of breed-verktyg för att hitta kodningsregler (PMD, Checkstyle), upptäcka potentiella buggar(Findbugs) och mäta täckning genom enhetstester (Cobertura, Clover). Men whatmakes Sonar verkligen unik är Squid, sin egen kodanalysator som inte bara tolkar källkoden utan också byte-kod och blandar resultaten.
eftersom analysen körs genom ett Maven-plugin kan Sonar enkelt startas i” Continuous Integration ” – miljöer.
användningsfall på Apache commons-collection project
en förutsättning för att köra Sonar är att ha Java och Maven installerat på lådan. När så är fallet kan du köra Sonar i 5 enkla steg:
1. Ladda ner distributionen från https://www.sonarqube.org/nedladdningar / och packa upp den
2. Öppna en konsol och starta servern:
> $SONAR_HOME \ bin \ windows-x86-32\StartSonar.bat på windows
> $SONAR_HOME/bin//sonar.sh på andra plattformar
3. Öppna en konsol där du vill kolla källan och kör:
svn co http://svn.apache.org/viewvc/commons/proper/collections/trunk/.
4. Kör MVN installera ekolod: ekolod i samma katalog
5. Bläddra http://localhost:9000
programmets hemsida visar listan över projektunder kvalitetskontroll med några konfigurerbara mätvärden.
för att zooma in kan du helt enkelt klicka på projektet och få dess instrumentpanel
därifrån har du tillgång till en serie jaktverktyg bland vilka:
hotspot för att ta reda på de filer som har ”mest” eller ”minst” …
men också, någon metrisk i instrumentpanelen är klickbar för att hoppa tillbakom scenen och få en bild av metriska av underliggande komponent
varje jaktverktyg tar så småningom jägaren till källkoden där byten markeras
Ekolodsekosystemet
det finns ett mycket dynamiskt ekosystem runt ekolod
- ett aktivt samhälle som består av 300+ personer på användarpostlistan och 150+ personer på utvecklingspostlistan
- 35+ plugins på forge (http://docs.codehaus.org/display/SONAR/Sonar+Plugin+Library/) som är uppdelade i fyra kategorier
- Integration med externa verktyg som Jira, Hudson, Bamboo, GateIn, AnthillPro, Crowd
- direkt förlängning av kärnfunktionalitet genom att lägga till nytt beteende, beräkna avancerade mätvärden eller konsolidera projekt, Lägg till nya mätvärden
- Lägg till täckning av språk som PL/SQL, ActionScript3
- Integration med IDEs för att få felinformation om koden när den redigeras
- 3,000+ nedladdningar per månad
- ett kärnutvecklingsteam ledt av Sonarsource (http://www.sonarsource.com)
slutsats
efter det massiva antagandet av kontinuerliga integrationsmotorer och Testdrivna utvecklingsmetoder, hantering av källkvalitet ser ut somnaturligt nästa steg för utvecklingsteam i deras ansträngningar för industrialisering. Ekolod gör det möjligt att nå detta mål med få ansträngningar och med roliga.
under 2010 kommer Sonarplattformen att fortsätta att utvecklas, de viktigaste utvecklingsaxlarna täcker nya språk och förbättrar integrationen med IDEs.