Sonar und Continuous: So verbessern Sie die Code-Qualität in Softwareprojekten

9. August 2012Felix Müller und Dr. Halil-Cem Gürsoy

Es liegt in der Natur von Softwareentwicklungsprojekten, dass sich über die Entwicklung hinweg kleinere oder größere Fehler in den Code einschleichen. Zusätzlich wird der Code im Laufe der Zeit komplexer und damit nicht mehr überschaubar. Ein manueller Review-Prozess wird dadurch erschwert. Gerade in gewachsenen Softwareprojekten ist es daher nahezu unmöglich, alle problematischen Stellen im Code zu identifizieren und dann auch noch ad hoc zu beseitigen. Für die Lösung dieses Problems kann Sonar [Sonar] verwendet werden.

Sonar ist ein freies Werkzeug für das Management der Qualität in Softwareprojekten, welches unter der LGPL steht. Es integriert bekannte Tools wie Findbugs [FBugs], Checkstyle [CStyle] und PMD [PMD] und macht diese in einer Web-Anwendung zugänglich. Daneben werden verschiedene Code-Metriken gemessen und historisiert gespeichert. Diese Historisierung ermöglicht das Ablesen der Entwicklung der Qualität im Verlauf des Projektes. Alle gesammelten Daten werden in einem nach eigenen Wünschen gestaltbaren Dashboard angezeigt.

Sonar Dashboard am Beispiel der offiziellen Demo-Instanz, erreichbar unter http://nemo.sonarsource.org

Die integrierten Tools wie Findbugs betreiben eine statische Analyse des Codes. Mit Hilfe eines Regelsatzes kann festgelegt werden, nach welchen möglichen Problemen und Fehlerquellen der Code untersucht werden soll. Wird gegen eine Regel verstoßen, generiert Sonar eine sogenannte “Violation” für die jeweilige Stelle im Code, so dass die Entwickler auf diese problematischen Bereiche aufmerksam gemacht werden.

Beispiel von Violations im Code

Für die Nutzung von Sonar gibt es ein paar allgemeine Tipps:

  • Bevor das Team mit der Benutzung von Sonar beginnt, sollte jeder einen Blick auf die Metrik-Definitionen (http://docs.codehaus.org/display/SONAR/Java+Metric+Definitions) werfen. Es ist wichtig, dass verstanden wird, was bei der jeweiligen Metrik gemessen wird und wie die Werte zu interpretieren sind. Die Metriken sind dabei eher Indikatoren für einzuleitende Maßnahmen. Es muss immer gefragt werden, warum diese einen bestimmten Wert hat und ob dies im gegebenen Kontext tatsächlich ein Problem darstellt.
  • Eine Analyse pro Tag ist ausreichend, da Sonar die historisierten Daten nicht weiter als auf die zeitliche Spanne eines Tages auflöst. Es ist dafür üblich, Sonar an einen Nightly Build in einem Continuous Integration Server zu koppeln.
  • Sonar bietet die Möglichkeit, Grenzen für Metriken zu definieren. Wird gegen einen Grenzwert verstoßen, wird ein Alarm ausgelöst. Das ist ein sehr hilfreiches Feature, um schnell auf ein kritisches Anwachsen von Problemen zu reagieren.

Des Weiteren gibt es zahlreiche Plugins, die Sonar um Funktionalitäten erweitern. Um nur einige zu nennen: das Weighted Violations, das Build Breaker und das Security Rules Plugin. Ein absolutes Muss ist das SCM Activity Plugin [SCMPlugin]. Es ermöglicht das Verbinden von Sonar mit einem Versionsverwaltungstool. Dadurch können einzelnen Code-Zeilen der letzte Commit zugeordnet werden, was bei der Umsetzung des Continuous-Inspection-Paradigmas (siehe unten) benötigt wird.

Nach der Einführung von Sonar in einem Projekt stellt sich häufig die Frage, wie das Werkzeug  neben der technischen Integration auch organisatorisch in die Arbeitsabläufe nachhaltig integriert werden kann.

Seit der Version 2.6 unterstützt Sonar das Paradigma der Continuous Inspection. Mit Continuous Inspection wird ein Vorgehen beschrieben, bei dem die Violations regelmäßig vom Team gereviewed werden. Diese Idee ist nicht neu: Bereits in einem Artikel von Paul Duvall [PDuvall] aus dem Jahr 2006 wird ein solches Vorgehen beschrieben. Allerdings mussten damals mehrere Tools konfiguriert und aufeinander abstimmt werden; ein ganzheitliches Werkzeug gab es noch nicht. Mit Sonar liegt nun ein solches vor, wodurch die Umsetzung von Continuous Inspection enorm vereinfacht wird.

Um Continuous Inspection mit Sonar umzusetzen, muss jeder im Team regelmäßig Sonar nutzen, am besten einmal täglich. Die Idee ist, dass jeder Entwickler zu Beginn seines Arbeitstages die neuen Violations reviewed. Mit Hilfe von Differential Views können die Unterschiede zur letzten Analyse angezeigt werden.

Der Differential View für Violations

Gemäß des Gedanken der Code Ownership werden die Violations in einem ersten Schritt dem Verursacher zugewiesen. Dank eines installierten SCM Activity Plugins ist bei einem Review sofort ersichtlich, wer diesen Bereich eingebracht hat und somit verantwortlich ist. Durch das Zuweisen entsteht aus einer Violation ein Review. Nachdem alle Violations zugewiesen sind, kann in einem zweiten Schritt damit begonnen werden, die Reviews zu kommentieren, als “False Positive” zu kennzeichnen, sie im Code zu lösen oder neu zu zuzuweisen. Die Entwickler können sich die zugewiesenen Reviews in Sonar anzeigen lassen oder mit dem Sonar Eclipse Plugin in der IDE [SonarEclipse], falls Eclipse genutzt wird. Wird im Code eine Regelverletzung beseitigt, erkennt Sonar dies bei der nächsten Analyse und schließt das Review automatisch. Gelangt die Regelverletzung an einer Code-Stelle hingegen wieder in den Code, öffnet Sonar automatisch ein bereits geschlossenes Review. Mit Hilfe von sogenannten Action Plans können Reviews zusätzlich gruppiert und deren Lösung terminiert werden.

Übersichtsansicht über die Action Plans eines Projektes

Werden diese Schritte täglich wiederholt, erhöht sich zwangsläufig die interne Qualität eines Softwareprojektes, die mit Sonar zudem zu einem gewissen Grad messbar wird. Dabei ist es völlig ausreichend, täglich 5-15 Minuten darauf zu verwenden. Kommunizieren Sie Erreichtes im Team und motivieren Sie sich gegenseitig.

Setzen Sie Tools wie Sonar ein? Oder haben Sie noch Fragen zu Sonar und dem Continuous Inspection Paradigma? Wir freuen uns darauf, gegenseitig Erfahrungen auszutauschen.

Links:

[Sonar] – http://www.sonarsource.org/

[FBugs] – http://findbugs.sourceforge.net/

[CStyle] – http://checkstyle.sourceforge.net/

[PMD] – http://pmd.sourceforge.net

[PDuvall] – http://www.ibm.com/developerworks/java/library/jap08016/index.html

[SonarEclipse] – http://docs.codehaus.org/display/SONAR/Installing+Sonar+in+Eclipse

[SCMPlugin] – http://docs.codehaus.org/display/SONAR/SCM+Activity+Plugin

Felix Müller und Dr. Halil-Cem Gürsoy Felix Müller und Dr. Halil-Cem Gürsoy sind bei der adesso AG beschäftigt. Felix Müller ist als Software Engineer tätig und beschäftigt sich mit der Entwicklung von Web-Anwendungen im Java-Umfeld und mit dem firmeninternen Build Management. Dr. Halil-Cem Gürsoy ist als Software Architect tätig. Sein technologischer Schwerpunkt liegt dabei auf Java Enterprise (JEE, Spring). Er fokusiert sich aktuell auf verteilte Applikationen, vorzugsweise in "der Cloud", sowie die Herausforderungen, die im Zusammenhang mit der Persistenz in solchen Applikationen einhergehen.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Thomas Traude 9. August 2012

Hallo liebe Kollegen,

ein netter Artikel, danke dafür!

Ihr schreibt „Eine Analyse pro Tag ist ausreichend…“. Was spricht dagegen – dem Prinzip „Fail Fast“ folgend – die Analyse ebenfalls kontinuierlich auszuführen? Im Rahmen einer Continuous Delivery Pipeline verstehe ich das ohnehin als einen verpflichtenden Schritt.
Wird die die Analyse z.B. nur nachts ausgeführt, bekommt der/die Entwickler/in das Feedback zum eingecheckten Code erst am nächsten Tag und muss ggfs. die am Vortag geschlossene „Baustelle“ wieder öffnen und sich wieder einarbeiten (Kontext-Switch).
Inbesondere wenn man – wie ihr schreibt – einen Alarm bei „schlechtem“ Analyseergebnis versendet, würde ich das als Entwickler gern so zeitnah wie möglich erfahren, um weitere Schritte einzuleiten.

Ich habe schon das Argument gehört, die Analyse würde zu lange dauern, um bei jedem Check-In ausgeführt werden zu können. Das würde aus meiner Sicht aber nicht gelten, wenn man diesen Schritt von dem normalen Compile, Test etc. trennt.

Wie ist eure Meinung/Erfahrung dazu?

Viele Grüße
Thomas

Felix Müller 9. August 2012

Hallo Thomas,

dein Einwurf ist völlig berechtigt.

Allerdings sollte Sonar wirklich als Tool zum kontinuierlichen Monitoring eingesetzt werden. Wenn es um die Integration in die Commmit Stage (Kompilieren und Testen nach jedem Commit) geht, bedeutet die Sonar-Analyse viel Overhead. Eine Möglichkeit wäre es, die Einstellungen für FindBugs, PMD und Checkstyle aus Sonar zu exportieren, in den Continuous Integration Server zu importieren und dort nach jedem Commit bzw. nach der Commit Stage die statische Code Analyse durchzuführen. Gute Plugins für z.B. Jenkins gibt es viele (siehe: https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins).

Des Weiteren gibt es mit dem Sonar Plugin für Eclipse auch die Möglichkeit eine lokale Sonar-Analyse durchzuführen.

Das Konfigurieren von Alarmen ist mit Vorsicht zu betrachten. Beispielsweise würde ich keinen Alarm für Violations konfigurieren, sondern nur für bestimmte Metriken, die eine Aussage zur Architektur ermöglichen: z.B. Package tangle index, LCOM4, Response for class. Und wenn solche Metriken quer laufen, sind das keine Probleme, die ein Entwickler für sich alleine lösen kann, sondern Design-Entscheidungen, die im Team getroffen werden sollten.

Grüße,
Felix

Kommentar hinzufügen:

Ihr Kommentar: