Tools für Legacy-Code: Werkzeugkasten der Source-Code-Archäologie (2/5)

Legacy-Code läuft, aber niemand weiß mehr genau, warum die Systeme so gebaut sind, wie sie sind. Die Dokumentation fehlt, die ursprünglichen Entwickler sind weg. Die Source-Code-Archäologie macht dieses Wissen wieder zugänglich und schafft so die Grundlage für jede fundierte Modernisierung.

Nachdem wir in Teil 1 unserer Reihe die strategischen Grundlagen und den Business-Nutzen beleuchtet haben, widmet sich dieser Teil dem technischen Werkzeugkasten: Mit welchen Tools für Source-Code-Archäologie-Tools und Code-Analyse-Tools gewinnen Entwickler und Software-Architekten die nötigen Befunde aus ihren Legacy-Systemen?

Das nehmt ihr aus diesem Beitrag mit:

• Breites Einsatzgebiet: Source-Code-Archäologie hilft dabei, große Legacy-Systeme erfolgreich zu untersuchen und zentrale Fragen zu Architektur, Code-Beschaffenheit, Historie, Testabdeckung und Sicherheit zu beantworten.
• Vielfältiger Werkzeugkasten: Es gibt zahlreiche kommerzielle und Open-Source-Werkzeuge (z. B. Git, IntelliJ, SonarQube und CodeScene), die jeweils unterschiedliche Schwerpunkte abdecken.
• Bordmittel als Einstieg: Standardwerkzeuge wie Git und IntelliJ senken die Einstiegshürde erheblich, da sie meist bereits vorhanden sind und schnell erste Erkenntnisse liefern.
• Individuelle Werkzeugwahl: Es gibt kein universelles „perfektes“ Tool. Die Auswahl hängt von den spezifischen Fragestellungen, dem Integrationsaufwand und dem Projektfokus ab, wobei sich verschiedene Werkzeuge gut ergänzen.

Wie im vorherigen Teil bereits erläutert, unterstützt die Source-Code-Archäologie bei der Beantwortung zentraler Fragen: Wie ist die Architektur beschaffen, wie steht es um die Code-Qualität, wie hat sich der Code im Laufe der Zeit entwickelt, wie zuverlässig sind die Tests, und wo bestehen Sicherheitsrisiken?

Für jede dieser Fragen gibt es zahlreiche Werkzeuge. Die meisten beantworten mehrere Fragen zugleich, manche sind Open Source, andere proprietär, und der Aufwand für die Integration in eine bestehende Systemlandschaft unterscheidet sich stark. Unsere Übersicht soll bei der gezielten Auswahl in euren Projekten helfen. Dafür stellen wir häufig eingesetzte, etablierte Werkzeuge vor und geben in eckigen Klammern an, auf welche Fragen sie jeweils einzahlen. Sie ist bewusst kein vollständiger Katalog, den man Punkt für Punkt abarbeitet: Entscheidend ist, welche Frage ihr beantworten wollt und welcher Aufwand dafür angemessen ist. Deshalb vertiefen wir in den folgenden Beiträgen nur ausgewählte Werkzeuge.

Bewusst ausgeklammert haben wir die künstliche Intelligenz. Sie erweitert die Source-Code-Archäologie um neue Analysemöglichkeiten und bekommt deshalb einen eigenen Post in den späteren Teilen der Reihe. Bleibt gespannt!

Welche Tools eignen sich für die Source-Code-Archäologie?

Für eine wirksame Source-Code-Archäologie empfiehlt sich ein mehrstufiger Werkzeugkasten: Bordmittel wie Git und IntelliJ IDEA für den schnellen Einstieg in Historie und Code-Struktur, ergänzt durch statische Code-Analyse-Tools (z. B. SonarQube, CodeScene, Teamscale) für Qualitätsmetriken und Hotspots, Architektur-Werkzeuge für Strukturregeln sowie spezialisierte Sicherheits-Tools für Schwachstellen im Code.

Der Markt im Überblick: Bordmittel und Analyse-Werkzeuge

Bordmittel für Historie & Code-Beschaffenheit

Git [Architektur, Verhaltensanalyse] gilt als das Bordmittel, da es bereits vor der Archäologie-Analyse sehr häufig in Verwendung ist und man daher keinen zusätzlichen Integrationsaufwand hat. Die Stärken liegen klar auf der ersten historischen Analyse, da man mit einfachen Befehlen wie git log einen umfangreichen Einblick in die Commits über die Zeit erhält. Außerdem gibt es Hinweise auf architektonische Probleme, da eine starke Kopplung zweier Komponenten meist in der gleichzeitigen Änderung dieser Komponenten zu erkennen ist. Was sich mit Git noch alles aufdecken lässt, zeigen wir in einem unserer nächsten Teile unserer Reihe, wo wir Git als Werkzeug genauer unter die Lupe nehmen.

IntelliJ IDEA [Architektur, Code-Beschaffenheit] als zweites Bordmittel, welches bereits häufig vor der Analyse im Gebrauch ist, bietet durch sein Highlighting (Unterstreichungen im Code, Lämpchen-Icons) eine sehr gute Übersicht über die Code-Beschaffenheit pro Datei und identifiziert dadurch schnell Code-Smells, Anti-Patterns, toten Code uvm. Der eher mikroskopische Blick auf die einzelnen Dateien wird zusätzlich durch zwei Architektur-relevante Features ergänzt: Dependency Structure Matrix (DSM) und UML-Diagramme. Hiermit werden Abhängigkeiten visualisiert und Architekturverletzungen sofort sichtbar gemacht. Hier ahnt man bereits, dass IntelliJ mehr Power mitbringt, als man auf den ersten Blick vermutet. Wie ihr sie konkret nutzen könnt, zeigen wir in einem eigenen Teil unserer Reihe detaillierter.

Generalisten für Code-Beschaffenheit & Technical Debt

SonarQube [Code-Beschaffenheit, Testabdeckung, Sicherheit] (sehr eingeschränktes Open Core, kommerziell für Team- und Enterprise-Features) ist eines der weitverbreitetsten Werkzeuge, mit dem mittels statischer Code-Analyse die Qualität des Quellcodes beurteilt werden kann und das einen Vergleich nach jeder vorgenommenen Änderung bietet. Es zahlt zudem auch indirekt auf die Testabdeckung ein, da es die Coverage Reports von anderen Werkzeugen visualisiert. Mittels Schwachstellenanalyse im Code fungiert es bereits als Basis-Static Application Security Testing (SAST) Tool, da es SQL-Injections, hardcoded Credentials etc. aufdecken kann. Hier sei allerdings angemerkt, dass sich dieser Teil der Analyse in der Standardausstattung nur auf den eigenen Quellcode bezieht. Schwachstellen in Drittbibliotheken erkennt SonarQube erst mit dem kostenpflichtigen Zusatzpaket Advanced Security (ab Enterprise Edition). Wer dieses Paket nicht nutzt, sollte dafür spezialisierte Werkzeuge hinzunehmen

CodeScene [Architektur, Code-Beschaffenheit, Verhaltensanalyse] (kommerziell mit Ausnahme von Open-Source-Projekten) ermöglicht unter anderem die statische Code-Analyse unter Berücksichtigung der Versionskontrolle. So lassen sich oft veränderte Hotspots identifizieren, die entweder auf besonders fachlich vulnerable oder fehleranfällige Stellen hinweisen. Durch den CodeHealth besitzt CodeScene eine Qualitätsmetrik, um bspw. Gott-Klassen oder duplizierten Code zu identifizieren und stellt dies als numerischen Wert dar. CodeScene selbst belegt mit einem Benchmark, dass CodeHealth die Wartbarkeit genauer vorhersagt als das Maintainability Rating von SonarQube. Zudem besitzt dieses Werkzeug durch seine Change-Coupling-Graphen die Möglichkeit, versteckte logische Abhängigkeiten aufzudecken und zahlt somit in Ansätzen auf den Aspekt der Architektur ein.

Teamscale [Architektur, Code-Beschaffenheit, Verhaltensanalyse, Testabdeckung] (rein kommerziell) ist spezialisiert auf die Kombination statischer Analyse mit dynamischen Daten, um beispielsweise Testlücken bereits während der Entwicklung zu identifizieren und punktet bei der breiten Sprach- und Systemintegration. Durch die Architecture-Conformance-Analyse ist es möglich, Architekturen als hierarchisch verschachtelte Komponenten zu spezifizieren. Architekten können darüber hinaus Policies definieren und die Überwachung schlägt an, wenn gegen diese Policies verstoßen wird. Ebenso vertreten sind Metriken zur Code-Beschaffenheit (Methodenlänge, Komplexität, duplizierter Code), sodass auch hier Code-Smells etc. entdeckt werden. Durch eine Evolution- und Code-Ownership-Analyse hat dieses Werkzeug auch einen wertvollen Einfluss auf die historische Analyse und gibt Auskunft darüber, wer welchen Code besitzt und wie sich dies über die Zeit verschiebt.

CodeCharta [Architektur, Code-Beschaffenheit, Verhaltensanalyse, Testabdeckung] (Open Source) bietet eine besonders management-taugliche Übersicht über problematische Stellen in der Code-Basis. Dort werden in Form einer 3D-Stadtkarte zusammenhängende Teile im Code zu Gebäudesiedlungen geclustert. Manche Metriken werden auch durch die Höhe und Farbe visualisiert. Die Metriken können mittels des Werkzeugs erhoben oder aus Werkzeugen wie SonarQube importiert werden. Die Bandbreite der Metriken umfasst mehrere Aspekte und beinhaltet z. B. Komplexität, Line Coverage, Code Churn (Häufigkeit der Änderungen), Code Smells oder die Anzahl der Autoren. Damit eignet es sich besonders, Befunde aus mehreren Quellen zusammenzuführen und im Team oder gegenüber dem Management zu kommunizieren.

Spezialisten für Architektur

jQAssistant [Architektur, Code-Beschaffenheit] (Open Source) speichert die Struktur von Softwaresystemen in einer Neo4j-Graphdatenbank und ermöglicht es, diese anhand individuell definierbarer Regeln zu analysieren und zu validieren. Beispielsweise können dadurch Architekturverletzungen sichtbar gemacht werden. Wie ihr mit jQAssistant Architekturregeln automatisiert absichert und Gott-Klassen oder tiefe Vererbungshierarchien aufspürt, zeigen wir in den nächsten Teilen unserer Reihe.

Sonargraph [Architektur, Code-Beschaffenheit] (kommerziell) hat einen starken Fokus auf Architektur-Erosion und zyklische Abhängigkeiten, deckt aber auch die interne Qualität des Codes durch Komplexitätsbewertung ab. Es bietet zwar auch eine Möglichkeit des Imports von Coverage Reporting anderer Werkzeuge ähnlich wie SonarQube, die Darstellung dieser Metriken ist allerdings sehr eingeschränkt, daher zahlt es eher nicht auf die Testabdeckung ein.

Sicherheit: SAST Tools & Software Composition Analysis

PrismaScan [Sicherheit] (rein kommerziell, Teil von Palo Alto Prisma Cloud) ist ein spezialisiertes Werkzeug für Software Composition Analysis (SCA), das Open-Source-Abhängigkeiten auf bekannte Schwachstellen und Lizenzprobleme scannt. PrismaScan ist ein starker Vertreter der Sicherheit, da dieses Werkzeug über die reine Code-Sicherheit hinausgeht. Neben Fehlkonfigurationen schützt es auch Container zur Laufzeit und zeigt Identitäts- und Berechtigungsrisiken in der Cloud. Obwohl es über den engeren Kernbereich der Source-Code-Archäologie hinausgeht, ist es durch seinen starken Sicherheitsfokus eine wichtige Ergänzung.

Veracode [Sicherheit] (rein kommerziell) kombiniert Software Composition Analysis mit einer breiten Palette an SAST Tools (Static Application Security Testing), DAST (Dynamic Application Security Testing) und IAST (Interactive Application Security Testing). Per Reachability-Analyse wird geprüft, ob verwundbare Bibliotheksmethoden überhaupt aufgerufen werden, was False Positives drastisch reduziert. Policy-Gates in CI/CD können das Beheben von Findings vor dem Merge erzwingen. Der Schwerpunkt liegt im Vergleich zu PrismaScan primär auf AppSec und ist je nach Umgebungsanforderung eine hervorragende Wahl.

Werkzeuge für die verschiedenen Aspekte der Source-Code-Archäologie

Diese Tabelle gibt eine Übersicht über die Tools.
 

	Architektur	Code Beschaffenheit	Historische/ Verhaltensanalyse	Testabdeckung	Sicherheit
Git	✔		✔
IntelliJ	✔	✔
SonarQube		✔		✔	✔
CodeScene	✔	✔	✔
TeamScale	✔	✔	✔	✔
PrismaScan					✔
Veracode					✔
CodeCharta	✔	✔	✔	✔
jQAssistant	✔	✔
Sonargraph	✔	✔

 

Wie bereits erwähnt, bildet diese Tabelle nicht das Gesamtbild aller Werkzeuge oder Nischenthemen ab, bietet aber einen soliden Überblick über die gängigsten konventionellen Werkzeuge und wie man sie für verschiedene Fragestellungen in der Source-Code-Archäologie verwenden kann.
 

Fazit & Ausblick: Das richtige Toolset für Legacy-Code wählen

Es gibt nicht das eine „perfekte“ Tool – nur die passenden Werkzeuge für eure jeweilige Fragestellung. Wie die Übersicht zeigt, haben alle vorgestellten Lösungen ihre Daseinsberechtigung. Am Ende entscheiden Faktoren wie Integrationsaufwand, Kosten und der Fokus eures aktuellen Projekts, welches Tool die richtige Wahl ist.

Bordmittel wie Git und IntelliJ senken die Einstiegshürde für eine erste Analyse enorm. Sie sind meist schon vorhanden und liefern schnell erste Erkenntnisse. Für tiefergehende Sicherheitsanalysen oder Architektur-Reviews sind dagegen spezialisierte Werkzeuge wie Veracode oder Teamscale oft die bessere Wahl. Entscheidend ist, sich von der Vielfalt an Werkzeugen nicht erschlagen zu lassen, sondern die eigenen Ziele klar zu definieren und das passende Besteck dafür auszuwählen. Häufig ergänzen sich verschiedene Werkzeuge dabei sogar sehr gut.

Wie sich einige dieser Werkzeuge in der Praxis konkret anwenden lassen, schauen wir uns in den nächsten Teilen dieser Reihe an. Dort beantworten wir Fragen wie: Welche Datei sollte man sich zuerst ansehen? Wer trägt das meiste Wissen zu einem Modul? Und wie hängen Komponenten strukturell zusammen?

Hierfür nehmen wir Git – mit Fokus auf häufig geänderte Dateien, Wissenssilos und den Blick in die Vergangenheit – sowie IntelliJ IDEA mit einigen interessanten Features, u. a. der Dependency Matrix, aber auch jQAssistant noch einmal ganz genau unter die Lupe.

Warum gerade diese Werkzeuge?

Alle Werkzeuge im Detail zu behandeln, wäre schlicht zu umfangreich. Spezialisierte Lösungen wie Security-Scanner richten sich an sehr konkrete Fragestellungen und lohnen sich meist erst, wenn die Grundlagen geklärt sind. Wir möchten aber vor allem Einsteigern in die Source-Code-Archäologie ein solides Repertoire an die Hand geben, mit dem sich die grundlegendsten Fragen bereits beantworten lassen. Git, IntelliJ und jQAssistant sind dafür ideal: Git und IntelliJ sind in den meisten Teams ohnehin im Einsatz, jQAssistant ist Open Source. Zusammen decken sie Historie, Wissenssilos und Architektur ab. So kannst du direkt loslegen, ohne erst Lizenzen zu beschaffen oder Infrastruktur aufzubauen. Und wenn ihr später tiefer in Themen wie Sicherheit einsteigen wollt, zeigt euch die Werkzeugübersicht oben, welche Spezialisten dafür infrage kommen.

---

Die Blogreihe zu „Source-Code-Archäologie”

• Teil 1: Grundlagen & Business-Sicht – Was Source-Code-Archäologie leistet und warum der verlässlichste Weg, um Legacy-Systeme zu modernisieren, beim Verstehen der bestehenden Fachlogik und des technischen Zustands der Anwendung beginnt.
• Teil 2: Der Tool-Markt – Welche Werkzeuge im Bereich der Source-Code-Archäologie existieren und welches Tool für welches Problem geeignet ist.
• Teil 3: Analyse mit Bordmitteln – Wie Entwicklungsteams mit vorhandenen Standard-Werkzeugen ohne Zusatzbudget wertvolles Systemwissen freilegen.
  (Erscheint am 17.11.2026)
• Teil 4: Graphenbasierte Code-Analyse – Konventionelle Werkzeuge im Vergleich mit KI-gestützten Code-Graphen und wie sich beide Ansätze kombinieren lassen.
  (Erscheint am 24.11.2026)
• Teil 5: Künstliche Intelligenz & Autonomie – Von MCP-Servern bis zu KI-Agenten: Kann generative KI die Source-Code-Archäologie bald vollständig übernehmen?
  (Erscheint am 01.12.2026)