CodeCharta: Software-Qualität sichtbar machen durch Stadtvisualisierung

Das Open-Source-Tool CodeCharta macht die komplexen Strukturen in Softwareprojekten greifbar und hilft bei der Sanierung.

vorlesen Druckansicht 3 Kommentare lesen
Skyline von New York mit untergehender Sonne

(Bild: dibrova/Shutterstock.com)

Lesezeit: 9 Min.
Von
  • Andreas Blunk
Inhaltsverzeichnis
close notice

This article is also available in English. It was translated with technical assistance and editorially reviewed before publication.

Andreas Blunk
Andreas Blunk

Dr. Andreas Blunk ist Softwarearchitekt und arbeitet seit 2015 für den Bereich IT-Sanierung bei MaibornWolff. Seine Schwerpunkte sind die Architektur und Entwicklung komplexer IT-Systeme durch ausdrucksstarke und eindeutige Modellierung einer Domäne in Code.

Die Qualität und Änderbarkeit von Software zu verbessern, ist oft eine Mammutaufgabe. Um sich die Arbeit zu erleichtern, können Entwicklerinnen und Entwickler auf Code-spezialisierte Tools für Code-Analyse und Visualisierung wie CrocoCosmos und Seerene zurückgreifen. Diese sind aber meist kostenpflichtig. Das Open-Source-Tool CodeCharta macht Fortschritte bei der Sanierung anschaulich sichtbar – durch eine Darstellung als Stadtlandschaft. Große Gebäude stehen für komplexen Code, rote für fehlende Tests.

CodeCharta wurde von dem IT-Dienstleister MaibornWolff entwickelt, damit sich Menschen, die kein Wissen über Code besitzen, leicht vorstellen können, in welchem Zustand sich ihre Code-Basis befindet. Das Unternehmen verwendet CodeCharta beispielsweise bei Software Health Checks und Modernisierungen, um den Auftraggebern ein schnell verständliches Bild zu vermitteln.

Der folgende Artikel zeigt, wie dieses Werkzeug Entwicklerinnen und Entwicklern sowie Stakeholdern gleichermaßen helfen kann, Probleme zu erkennen, Lösungen zu planen und den Erfolg der Maßnahmen zu bewerten. Ein Blick hinter die Kulissen eines realen Sanierungsprojekts bei der Deutschen Bahn macht deutlich: Mit visuellen Metriken wird Software-Modernisierung verständlicher und teamübergreifend steuerbar.

Eine Software braucht eine Sanierung, wenn es schwierig bis unmöglich wird, neue Features zu ergänzen oder bestehende zu ändern, weil dabei immer wieder neue Fehler auftreten.

Stakeholder erkennen erste Anzeichen, wenn Features regelmäßig ausfallen und eine Planbarkeit nicht mehr möglich ist. Das Einbauen der Features dauert entweder unplanbar lange oder sie benötigen sehr viel Bugfixing nach dem Einbauen. Diese Situation tritt ein, wenn es

  • keine automatisierten Tests gibt,
  • die Software keine modulare Struktur aufweist oder
  • der Code von schlechter Qualität ist.

Das Ziel einer Sanierung ist es, die Software so zu verbessern, dass Änderungen einfacher und weniger fehleranfällig sind. Denn im Laufe der Zeit ergeben sich immer wieder neue Anforderungen, die Anpassungen erforderlich machen. Die Qualität einer Software ist daher hoch, wenn Developer die Software mit überschaubarem Aufwand anpassen können und dabei keine Fehler auftreten.

Videos by heise

Das Besondere an CodeCharta ist die Darstellung der Metriken mit den Elementen einer Stadt, die vielen Menschen, auch ohne Entwicklerhintergrund, vertraut sind. Jede Datei der Code-Basis entspricht dabei einem Gebäude. Die Gebäude, die sich im gleichen Verzeichnis befinden, werden als Stadtviertel dargestellt, das durch Straßen von anderen Stadtvierteln abgegrenzt ist.

Ăśblicherweise beginnt die Visualisierung einer Software mit der Betrachtung folgender Metriken:

  • Die Grundfläche fĂĽr die Größe einer Datei (Code-Zeilen),
  • die Höhe fĂĽr die Komplexität des Codes
  • und die Farbe fĂĽr den Umfang der Testabdeckung.

Mit dieser Visualisierung lassen sich auf einen Blick verschiedene Metriken zur Bewertung der Softwarequalität erkennen.

Zur Veranschaulichung soll als Beispielprojekt die Deutsche Bahn dienen, deren Software durch MainbornWolff saniert wurde. Abbildung 1 zeigt den Fortschritt der Sanierung in mehreren Schritten:

Der Fortschritt der Softwaresanierung im Verlauf von drei Jahren: von groĂźen, komplexen und schlecht getesteten (roten) Strukturen hin zu modularer und gut getesteter (grĂĽner) Software (Abb. 1).

(Bild: MaibornWolff)

21/04: Die Stadt ist sehr grob strukturiert: Es gibt wenige Gebäude, die zudem hoch und breit sind. Viele davon sind rot. Die Farbe signalisiert fehlende Tests und die Höhe der Gebäude eine hohe Code-Komplexität.

22/06: Im Verlauf der Sanierung hat der Anteil gelber und grüner Gebäude zugenommen. Es sind also mehr Tests dazugekommen. An der groben Strukturierung der Stadt und der Höhe der Gebäude hat sich wenig verändert.

23/07: Etwas mehr als ein Jahr später ist fast überall eine gute Testabdeckung vorhanden (grüne Gebäude). Es sind auch viel mehr einzelne Gebäude zu erkennen, und sie sind nicht mehr so hoch wie zu Beginn. Der Code wurde also auf mehr Dateien aufgeteilt, was die Komplexität der Software reduziert hat.

24/01 bis 24/07: Dieser Trend setzt sich in den folgenden Monaten (Januar, April und Juli 2024) fort. Im Vergleich von April 2024 zu Juli 2024 sind kaum noch Unterschiede erkennbar.

Die Stadt ist hauptsächlich grün und weist eine feinere Granularität auf. Nur an einigen Stellen gibt es noch hohe Gebäude. Diese müssen für eine vollständige Sanierung noch abgebaut werden. Sie sind hier noch vorhanden, weil sich der Code an dieser Stelle aktuell nicht ändert und die Sanierung zu einem späteren Zeitpunkt erfolgen soll.

Abgesehen von den wenigen hohen Gebäuden ist die Sanierung fast abgeschlossen. Es bleibt die Frage, ob die Aufteilung der Stadt in die Struktur, die sich aus Gebäuden und Straßen ergibt, gut ist, das heißt ob dabei eine nachvollziehbare modulare Struktur entstanden ist. Diese Frage lässt sich jedoch mit dieser Code-Karte nicht beantworten. Dazu muss eine Möglichkeit gefunden werden, die Architekturqualität der Software darzustellen. Die Basis hierfür bieten Architekturregeln.