4Max/shutterstock.com

21. August 2015 / von Michal Zyla

Nicht nur
Europa
hat eine
Schuldenkrise!

Technische Schulden zurückzahlen mit Hilfe von SonarQube

Jeder Entwickler kennt das: Ein neues Feature muss in eine Anwendung eingebaut werden, aber der alte Code macht es nicht einfach. Im Laufe der Zeit kostet die Umsetzung neuer Anforderungen mehr und dauert länger. Niemand kann das ganz genau erklären oder sich an den Moment erinnern, ab wann es schief läuft. Vielleicht war das der Moment, als mal etwas schnell umgesetzt werden musste … oder als mal jemand ein paar Klassen kopiert hat, um sich das Leben einfacher zu machen … oder als mal jemand die fehlgeschlagenen Tests ausgeschaltet hat?

Am Ende macht es keinen Unterschied – wir müssen die Konsequenzen der technisch schlechten Umsetzung von Software erleben und damit leben. Um dieses „Phänomen“ zu beschreiben, nutzt man den Begriff „Technische Schulden“.

Es ist eine Metapher aus der realen Welt, um klarzumachen, dass die Einsparungen an geringerer Software Qualität (später) tiefgehende Konsequenzen haben. Für Schulden bezahlt man Zinsen und in der Softwareentwicklung sind das erhöhte Aufwände für die Wartung und Weiterentwicklung. Technische Schulden können bewusst oder unbewusst angesammelt werden. Die Schulden sollten so schnell wie möglich getilgt werden. Nicht bezahlte Schulden sammeln sich an und können ganze Software Projekte zum Stillstand bringen. Softwarezerfall ist ein natürlicher Prozess. Wenn keine aktiven Maßnahmen im Laufe der Entwicklung getroffen werden, wächst die Komplexität und der Zerfall stetig an.

Auf dem SonarQube-Dashboard werden die wichtigsten Qualitätsmerkmale angezeigt
Abbildung 1 Auf dem SonarQube-Dashboard werden die wichtigsten Qualitätsmerkmale angezeigt

„Was man nicht messen kann, kann man nicht kontrollieren“ (Tom DeMarco)

Wir wollen Technische Schulden bekämpfen, aber woher wissen wir, dass und welche Technische Schulden wir überhaupt haben? Wir möchten nach Demingkreis unsere Prozesse optimieren, aber wie überprüft man dabei Technische Schulden? Bis jetzt wir haben nur die Auswirkungen in Form verlängerter Entwicklungszeiten beobachtet und das Meckern der Entwickler gehört… Wir brauchen also eine Methode, um die Qualität unserer Software messen zu können und das kontinuierlich. Hier kommt SonarQube zu Hilfe (Webseite: http://www.sonarqube.org/ . Open-Source unter der LGPL v3). Eine mögliche Methode, um Software-Qualität messen zu können, ist die statische Code-Analyse. Es gibt jede Menge Werkzeuge, um Software-Qualität zu bestimmen: Tools wie Checkstyle, PMD oder Findbugs kommen seit vielen Jahren in vielen Projekten zum Einsatz. SonarQube ist meiner Meinung nach kein Ersatz für diese Werkzeuge. Für mich ist SonarQube vielmehr ein sehr gutes Supplement, das auch dann, wenn andere Tools nicht verfügbar sind, selbständig zur Software-Qualitäts-Analyse eingesetzt werden kann.

SonarQube analysiert Quellen hinsichtlich Architektur, Duplikate, Unit-Tests, Komplexität, potentiellen Fehlern, Entwicklungsregeln und Kommentaren. Die zu prüfenden Eigenschaften werden über Regeln konfiguriert. Die Einstellungen können aus anderen Tools übernommen werden oder es kann ein Default-Profile ausgewählt werden.

SonarQube besteht aus drei Komponenten:

  1. einer Datenbank
  2. einem Runner, der die Analyse ausführt und die Ergebnisse in die Datenbank schreibt
  3. einer Web-Anwendung, die die Analyse-Ergebnisse anzeigt.

Der Runner existiert auch als Plug-In für Continuous-Integration-Systeme. Damit lässt sich eine kontinuierliche Überwachung und Auswertung erstellen. Jede Regel kann einzeln konfiguriert und priorisiert werden und es gibt auch Plug-Ins, die aus gefundenen Regel-Verletzungen automatisch JIRA-Issues erstellen können. Am Ende des Tages haben wir eine Menge priorisierter Issues, die unterschiedliche Qualitätsaspekte von Software-Eigenschaften betreffen.

„Die sogenannte Wirklichkeit ist das Ergebnis von Kommunikation.“ (Paul Watzlawick)

Die große Stärke von SonarQube ist die Art und Weise der Anzeige von Ergebnissen. Um die Analyse-Ergebnisse besser auswerten zu können, wird die SQALE-Methodik (Software Quality Assessment based on Lifecycle Expectations) benutzt. Angewandte Regeln werden als nicht-funktionale Anforderungen betrachtet. Für jede Regel wird ein Behebungsaufwand definiert. Anhand dieser Daten wird die gesamte Technische Schuld in Personentage gemessen.

SonarQube: Entwicklung der Technischen Schulden im Laufe der Zeit
Abbildung 2 SonarQube: Entwicklung der Technischen Schulden im Laufe der Zeit

Dadurch, dass die Qualitätsprobleme in einem sehr Management-tauglichen Maß quantifiziert werden, schafft man einen sehr guten Ausgangspunkt, um über den oft vernachlässigten Aspekt der Softwareentwicklung zu sprechen. Zusätzlich sind die SQALE-Ergebnisse mit ISO/IEC 9126-1 konform. Die einzelne Issues werden kategorisiert in unterschiedliche Qualitätsmerkmale, so dass man schnell einen Überblick erhält, wo man am meisten / ehesten investieren muss, wenn man die Schulden zurückzahlen will.

SonarQube: Technische Schulden kategorisiert dargestellt
Abbildung 3 SonarQube: Technische Schulden kategorisiert dargestellt

Weitere Möglichkeiten eröffnen SonarQube Plug-ins. Außer der Möglichkeit unterschiedliche Programmiersprachen zu analysieren, erlauben sie, Ergebnisse auf interessante Art und Weise zu zeigen. Mit der Benutzung von Google Motion Chart lassen sich gut die Änderungen über die Zeit darstellen. Das SoftVis3D Plug-in fügt die CodeCity-Ansicht ein. Der Quellcode wird als eine Stadt gerendert, in der die Höhe und Breite der einzelnen Gebäude Qualitätsmerkmale anzeigen. Die Stadt-Analogie ist für nicht technisch versierte Personen sehr gut verständlich.

 SonarQube mit CodeCity-Plugin - Stadt Ansicht: Gebäude sind Klassen, ihre Höhe deren Komplexität
Abbildung 4 SonarQube mit CodeCity-Plugin – Stadt Ansicht: Gebäude sind Klassen, ihre Höhe deren Komplexität

Softwarezerfall stoppen!

Qualitätsaspekte von Software sind nur schwer darzustellen. Mit dem Einsatz von Werkzeugen lässt sich Code-Qualität messen und gut darstellen. Konkrete Ergebnisse lassen sich dann nicht „abtun“ und können nicht (so einfach) ignoriert werden. Das gesamte Team kann sich den Bedarf an Qualitätsverbesserungen ständig bewusst machen und die Qualität so weiterentwickeln. Mit Hilfe von Werkzeugen vereinfacht sich also die Kommunikation und ständige Verbesserungen werden ermöglicht. Lasst uns den Softwarezerfall stoppen.

Autor

Michal Zyla
Michal Zyla
Weitere Artikel

Das könnte Sie auch interessieren