Regelmäßige Analyse der Codequalität mit Sonar

Mit der Plattform Sonar können unterschiedliche Projekte einer statischen Codeanalyse unterzogen und die Ergebnisse in einer einheitlichen Form präsentiert werden. Sonar selbst verfügt über eigene Prüfregeln, ergänzt diese jedoch durch Integration zusätzlicher Analysetools wie (in der Java-Welt) FindBugs, Checkstyle oder PMD.

Die Erfahrungen mit dem Einsatz in einem großen Portfolio unterschiedlicher Anwendungen sind gut. Die für Java mehr als 800 verfügbaren Regeln sind gut beschrieben, lassen sich aktivieren und deaktivieren und können bezüglich der Schwere von Regelverletzungen (Blocker, Critical, usw.) sowie Parametern konfiguriert werden. Die Erfahrung hat gezeigt, dass es sich lohnt, nicht die Standardeinstellungen zu verwenden sondern diese Konfiguration mit erfahrenen Entwicklern durchzusprechen und eher weniger als mehr Regeln als kritisch einzustufen (Blocker). Dafür sollte im Vorgehensmodell bzw. in den Quality Gates für die Softwareentwicklung klar festgelegt sein, dass beispielsweise ein Release nicht eingesetzt werden darf, solange es Blocker enthält. Immerhin handelt es sich dabei mit hoher Wahrscheinlichkeit um potentielle Laufzeitfehler.

Zusammenfassung der Ergebnisse einer Codeanalyse mit Sonar (Beispiel)

Zusätzlich zu diesen Regeln misst Sonar die Kommentardichte, den Anteil auskommentierten oder duplizierten Codes, die zyklomatische Komplexität, den Grad des Methoden-Zusammenhalts (LCOM4) und die Klassen-Komplexität (RFC), die sich als Indikatoren für die Code-Qualität bewährt haben. Basierend auf den eigenen Programmierrichtlinien, in denen unter Anderem Richtwerte für diese Metriken festgelegt sein sollten, kann in einem Profl definiert werden, ab welchem Schwellenwert für eine Metrik die Über-/Unterschreitung in Sonar als Warning oder als Error angezeigt wird. So kann man sicherstellen, dass alle mit diesem Profil analysierten Anwendungen nach dem gleichen Maßstab gemessen werden.

Die Codeanalyse kann gut in den Build-Prozess einer Anwendungen integriert werden, so dass nach jedem neuen Build, je nach Konfiguration also beispielsweise jede Nacht oder auch kontinuierlich, auch ein neues Analyseergebnis zur Verfügung steht.

Ein Webclient stellt die Analyseergebnisse in Dashboards dar. Die Möglichkeiten zur Strukturierung auch großer Anwendungsportfolios sind sehr gut. Es stehen zahlreiche Werkzeuge zur Verfügung um beispielsweise Zeitverläufe zu analysieren oder Hotspots zu erkennen. Per Drill-down kann man jede Regelverletzung bis auf Code-Ebene verfolgen und diese, je nach Berechtigung, ggf. als „false positive“ deklarieren.

Mit einem Werkzeug wie Sonar können Programmierrichtlinien nicht nur festgelegt sondern auch überprüft werden. Und dies ohne großen Zeitaufwand und in kurzen Zyklen.

Informationen zu Sonar findet man unter http://www.sonarqube.org/ oder http://docs.codehaus.org/display/SONAR/Documentation.