What is your code saying?

We hebben hard gewerkt met ons developmentteam. Het product is af en voldoet (volgens de klant) aan de gestelde requirements. Daarnaast is het binnen de geplande tijd opgeleverd. Kortom de klant is tevreden. Maar heeft de onderliggende code nu ook de kwaliteit die ik graag wil hebben? Heeft mijn collega ontwikkelaar de kwaliteit geleverd die ik verwacht? We hebben een aantal codingstandards afgesproken en er zijn een aantal unittests gebouwd, maar zijn het wel genoeg testen en is er voldaan aan de gestelde standards?

Als teamleider van mijn development team wil ik graag dat deadlines gehaald worden. Via ons ticket systeem worden de requirements netjes een voor een afgetikt. Om een aantal weken wordt er een oplevering gedaan, de klant is tevreden, de gewenste functionaliteit is aanwezig en werkt zonder fouten. Maar wat gebeurt er als het geheel naar beheer gaat, of als er andere ontwikkelaars in mijn team komen. Is de code wel leesbaar, goed te onderhouden, goed gedocumenteerd?
Kwaliteit van code is op een aantal punten meetbaar en wel op de volgende:

● Hoeveel code is er?
● Hoeveel van deze code is gedocumenteerd?
● Hoe groot is de complexiteit van de code?
● Wat is de coverage van de code t.o.v. de unittests?
● Wat is het unittests slagingspercentage?
● Voldoet de code aan de gekozen codingstandard?
● Zitten er mogelijk bugs of anti-patterns in mijn code? (op te sporen met bugpatterns)

Heden te dage is er een aantal goede tooling beschikbaar om dit soort kwaliteitsmetingen uit te voeren: PMD, Checkstyle, FindBugs. Het probleem met deze tooling is echter dat ze allemaal los van elkaar werken, en ze dus op verschillende manieren te integreren zijn in je ontwikkelomgeving(en). Ook de rapportagemogelijkheden verschillen (of voldoen niet helemaal aan de verwachting). De oplossing voor dit probleem is de tool Sonar van Codehaus.
Deze tool biedt de mogelijkheid om al deze kwaliteitsmetingen samen te nemen, ze op een laagdrempelige manier (m.b.v. Maven) te verzamelen en dit alles via een gebruikersvriendelijke webinterface in overzichtelijke dashboards aan te bieden. Dit alles ook nog voor meerdere projecten. Het configureren van de nodige settings voor de verschillende tooling, juiste codestyle, beperkt aantal PMD violations, etc. is per project in te stellen. Daarnaast is het mogelijk om met de timemachine optie terug te kijken in de tijd en te zien of de gestelde kwaliteitseisen van de code vooruit of juist achteruit zijn gegaan.

Persoonlijk gebruik ik Sonar bij mijn eigen projecten en heb het gebruik van Sonar geintroduceerd bij een grote verzekeraar en hiermee de kwaliteit van code op een hoger niveau gebracht.

Niveau: Beginner

Track: Tools

Voorkennis: Ervaring met ontwikkelen in Java, ervaring met de werking van Maven (wordt ook kort uitgelegd).
 

Albert-Jan de Vries  Peak IT Albert-Jan de Vries is in 2003 afgestudeerd aan de HIO te Enschede. Sindsdien actief als Java Developer bij verschillende bedrijven en nu in dienst als Lead Software Engineer bij Peak-IT. Albert-Jan ontwikkelt veelal aan JEE applicaties en is daarbij geinteresseerd in nieuwe technologie en frameworks, o.a. Wicket en Guice. Ook het creeren van een goede ontwikkelomgeving heeft zijn interesse en dit op een Agile wijze m.b.v. Scrum en goede tooling: vb. Maven, JUnit, Hudson en Sonar.