Bunte, transparente Würfel auf einer digitalen, vernetzten Oberfläche.

Code-Visualisierung mit CodeCharta

4 Min

Autor: Dominik Ufer

Eine Einführung

In Audits und in Sanierungsprojekten ist es wichtig, den Austausch zwischen Entwicklern und Projektmanagern beziehungsweise Product Ownern zu fördern. Gern nutzen wir bei MaibornWolff bei der Visualisierung von Code eine Stadt-Metapher. Das bei uns entwickelte und als Open Source freigegebene Tool CodeCharta stellt Code genau so dar. Ich stelle es im Folgenden an einem Beispiel vor.

CodeCharta macht implizite Strukturen im Code sichtbar. Wie die alten Software-Karten zeigt es Komplexität von Klassen, Code-Abdeckung, Änderungshäufigkeit oder vieles mehr. In unserer Software-Stadt sehen wir im Vergleich mit älteren Karten Veränderungen, erkennen Brennpunkte und können Maßnahmen zum Refactoring ableiten. Im Vergleich zu den alten Software-Karten ist CodeCharta fokusierter auf die Bedürfnisse in Audits und Projekten, aber gleichzeitig besser erweiterbar und besser individualisierbar auf das jeweilige Projekt. CodeCharta erfindet das Rad nicht neu und benutzt Tools wie SonarQube und SourceMonitor, um Metrikdaten zum Code zu erhalten. Es spricht daher alle Sprachen, die auch diese Tools sprechen, unter anderem C, C++, C#, Java. CodeCharta besteht aus zwei Teilen: Analyse-Teil, mit Importern für diese Tools, und Visualisierungs-Engine, welche als Desktop oder Online-Version läuft, runterzuladen bei Github.

Ich zeige die Arbeit mit CodeCharta an einem Beispiel. Dafür habe ich mir mal den Code von Apache Tomcat herausgepickt. Zunächst benutzen wir den öffentlichen SonarQube-Server auf sonarqube.com um den Code von Apache Tomcat zu analysieren. Von GitHub habe ich die aktuelle Version der CodeCharta heruntergeladen, in meinem Fall Version 1.1.3, und wie auf der Projektseite beschrieben installiert. Danach hab ich mittels des Kommandos ./ccsh sonarimport https://sonarqube.com/ org.apache:tomcat > apache_tomcat.json eine json-Datei mit den Visualisierungsdaten für Apache Tomcat erzeugt. Diese lade ich jetzt in die Online-Demo (oder die Standalone-Version) von CodeCharta. Schon sehe ich eine Stadt mit vielen, vielen Gebäuden:

Eine 3D-Visualisierung von Gebäuden in verschiedenen Farben zeigt komplexe Flächen und Höhen, sowie Verstöße in der Dichte der Duplikatlinien.

Die Gebäude stellen Dateien mit Klassen dar, welche anhand ihrer Dateihierarchie in Häuserblocks eingeteilt sind. Die Fläche, die Höhe und die Farbe der Gebäude entsprechen Metriken aus Visualisierungsdaten.

Umfang des Source Code anzeigen

Um einen Eindruck über die Größe des Source Codes von Tomcat zu bekommen, stellen wir das Mapping der Gebäude um: unter Metrics wählen wir ncloc als Metrik für die Fläche (Area), Höhe (Height) und Farbe (Color). Zudem stellen wir unter Color Settings die Grenzen für die neutrale Farbe (Neutral color) auf 500 (start) und 2000 (end). Das Ergebnis sieht so aus:

Eine bunte 3D-Visualisierung von Gebäuden, die verschiedene Datenmetriken zeigt.

Wenn man das Bild dieser Stadt anschaut, fällt sofort auf, dass fast die Hälfte der Codezeilen in großen Klassen liegt und darunter Klassen wie StandardContext über 2000 Zeilen Code haben. „Warum hat der Context in Apache Tomcat so viele Zeilen?“, fragt man sich da. Die Antworten kann man vielleicht bei den Entwicklern erfragen oder im Code nachlesen.

Da ich die Entwickler nicht zur Hand habe, mache ich letzteres und sehe eine Klasse, welche zwei Interfaces implementiert, eine Klasse erweitert, mehr als 100 nicht-geerbte Felder und mehrere komplexe Methoden enthält, kurz eine Gott-Klasse. Definitiv schwer wartbar, testbar, weiterentwickelbar; aber andererseits, wer hätte etwas anderes von einem „Standard-Kontext“ erwartet.

Eine Einführung

3D-Visualisierung von verschiedenfarbigen und unterschiedlich hohen Blöcken, die Bereiche und Höhen der maximalen Komplexität darstellen.

In dieser Karte fällt besonders die Datei Request.java im Paket org.apache.catalina.connector auf, welche eine Funktion mit einer Komplexität über 300 hat und ansonsten mit über 1000 Statements auch nicht wirklich klein ist. In der Klasse findet man jede Menge recht komplexen Code, welchen man mindestens zum Teil auch hätte in spezialisierte Klassen auslagern können. Insgesamt hält sich die Anzahl an komplexen Klassen aber in Grenzen.

Richtig interessant wird es nun, wenn man jetzt noch Daten aus Git, zum Beispiel die Änderungshäufigkeit, hinzunimmt. Damit können wir dann beantworten, ob der Teil des Codes überhaupt noch in aktiver Entwicklung ist und es sich lohnt dort Sanierungsmaßnahmen durchzuführen.

Auch Aussagen über die Code-Coverage, die bei Fragen zum Risiko und Aufwand der Sanierungsmaßnahmen hilfreich sein können, lassen sich mit CodeCharta treffen. Das sind Geschichten für den nächsten Blog-Artikel.

Autor: Dominik Ufer

Dominik arbeitet seit 2013 bei MaibornWolff. Seine Schwerpunkte liegen in der Architektur und Entwicklung von Anwendungen und Plattformen in der Cloud. Am liebsten unterstützt er dabei, bestehende Systeme durch die Möglichkeiten der Cloud zu verbessern. Privat trifft Dominik sich gerne zu Brettspielabenden oder bewegt sich in der Natur.