DeepQuali: Softwarequalität mit KI bestimmen

"Von Entwickler zu Entwickler: Was geht dir durch den Kopf, wenn du den Begriff „Softwarequalität“ hörst?

Du denkst wahrscheinlich an Dinge wie „Clean Code“, „Unit-Tests“, „Modularität“ oder „Architektur“. Und vermutlich auch an die Erkenntnis, dass man trotz all dieser Prinzipien oft ziemlich im Nebel steht, wenn man ein großes oder unbekanntes Projekt übernimmt.

• Wo liegen die Schwachstellen?
• Welche Teile sind solide aufgebaut?
• Und wo verstecken sich technische Schulden, die uns früher oder später auf die Füße fallen?

Klassische Qualitätsmetriken wie „zyklomatische Komplexität“ oder „Lines of Code“ liefern zwar erste Anhaltspunkte, bleiben aber meist abstrakt. Über den tatsächlichen Kontext sagen sie nur wenig aus:

• Warum ist eine Klasse so komplex?
• Ist das wirklich problematisch – oder in diesem Fall schlicht unvermeidbar?
• Und wie fügt sich das Ganze ins Gesamtbild ein?

Genau hier setzt DeepQuali an. Es ist kein Zaubertool, das dir Entscheidungen abnimmt, sondern eher ein Kollege, der dir schnell ein klares Bild von einer Codebasis vermittelt. Wir bei QAware haben DeepQuali gemeinsam mit Partnern wie dem Fraunhofer IESE im Rahmen eines BMBF-Forschungsprojekts entwickelt und dabei vor allem das Backend beigesteuert. DeepQuali ist ein Baustein, um Softwarequalität besser einschätzen und gezielt verbessern zu können. Es ist unser Beitrag dazu, Softwarequalität ein Stück weit transparenter und greifbarer zu machen – von Entwicklern, für Entwickler.

Was klassische Qualitätsmetriken übersehen

Viele Ansätze zur Softwarequalität stützen sich noch immer auf statische Metriken: Anzahl der Codezeilen, Komplexitätswerte, Testabdeckung. Das sind nützliche Anhaltspunkte. Aber Hand aufs Herz: Wir alle kennen Projekte, bei denen auf dem Papier alles im grünen Bereich war – und die trotzdem schwer zu verstehen, mühsam zu erweitern oder sogar fragil waren. Das Problem: Zahlen allein liefern kaum Kontext. Sie verraten dir weder, ob ein Projekt sinnvoll strukturiert ist, noch ob eine Klasse eine klare Verantwortung hat oder das Zusammenspiel der Komponenten stimmig ist. Genau diese Fragen wollen wir Entwickler aber beantworten. Wichtig dabei: DeepQuali ist kein Black-Box-Orakel. Alle Prompts sind einsehbar, die Ergebnisse nachvollziehbar und die Bewertungen beruhen auf bekannten Prinzipien wie Kopplung, Kohäsion oder Schichtenmodellen.

Architektur-Feedback mit System: DeepQuali als Entscheidungshilfe

DeepQuali soll keinesfalls die Entscheidungen von Architekten ersetzen. Das kann es nicht, und das will es auch nicht. Die Verantwortung bleibt am Ende immer bei uns Entwicklern und Architekten. DeepQuali liefert vielmehr strukturiertes Feedback:

• Wo ist die Architektur stabil und zugleich flexibel?
• Welche subtilen Anti-Patterns verbergen sich unter der Oberfläche?
• Und welche Bereiche sind so eng miteinander verzahnt, dass jede Änderung eine Kettenreaktion auslöst?

Stell dir DeepQuali wie einen besonders aufmerksamen Co-Piloten vor: Es liest deinen Code, macht sich Notizen und gibt dir anschließend Hinweise wie diese:

• „Diese Klasse übernimmt ziemlich viele Aufgaben – vielleicht zu viele?“
• „Deine Serviceschicht ist stärker an die Datenbankschicht gekoppelt als vermutlich beabsichtigt.“
• „Für dieses Paket wäre möglicherweise eine klar definierte Schnittstelle sinnvoll.“

Am Ende bekommst du also nicht nur Zahlen, sondern eine konkrete Einschätzung und sogar Vorschläge, die dich bei Refactorings und Architekturentscheidungen unterstützen.

Von Klassen zur Architektur – Schritt für Schritt

Nun stellen sich natürlich Fragen:

• Wie funktioniert das Ganze eigentlich hinter den Kulissen?
• Wie kommen wir von rohem Quellcode zu aussagekräftigen Erkenntnissen über die Architektur – ohne die KI mit Bergen von Code zu überfordern und dabei unnötig Geld zu verbrennen?

Werfen wir einen genaueren Blick darauf, ohne gleich tief in Algorithmen oder YAML-Monstrositäten abzutauchen.

Der erste Schritt: die Abhängigkeiten sortieren

Bevor wir als Entwickler etwas bewerten können, brauchen wir zunächst Kontext. Bei Software bedeutet das vor allem, zu verstehen, wie die einzelnen Klassen miteinander zusammenhängen. DeepQuali nutzt dafür zwei unterschiedliche Ansätze:

• Bytecode-Analyse: Sie ist besonders robust und präzise und funktioniert mit allen JVM-Sprachen wie Java, Kotlin, Scala oder Groovy. Die ideale Lösung, wenn sich das Projekt bauen lässt.
• Shallow Parser: Er kommt zum Einsatz, wenn kein Bytecode verfügbar ist – etwa weil sich das Projekt nicht bauen lässt – oder wenn wir Sprachen außerhalb der JVM-Welt analysieren. Der Parser untersucht direkt den Quellcode und ermittelt daraus die Abhängigkeiten.

Am Ende kennen wir alle Klassen – wobei wir mit „Klasse“ ab jetzt jede beliebige Quelldatei meinen – und ihre Abhängigkeiten. Das Ergebnis ist ein Netzwerk, manchmal sogar ein zyklisches. (Nein! Doch! Oh!) DeepQuali bringt Ordnung in diesen Abhängigkeitsdschungel, indem es das Netzwerk linearisiert. Dadurch werden Abhängigkeiten in der Regel vor dem Code analysiert, der sie verwendet. Technisch gesehen handelt es sich dabei um eine Näherungslösung für das Minimum Feedback Arc Set. An alle Graphen- und Algorithmustheoretiker: jetzt seid ihr wach!

Zusammenfassungen – Klasse für Klasse

In genau dieser Reihenfolge analysiert DeepQuali nun die Klassen und erstellt jeweils eine kompakte Zusammenfassung: Was macht die Klasse? Welche Methoden sind besonders wichtig? Dabei fließen die bereits erstellten Zusammenfassungen ihrer Abhängigkeiten in die Analyse ein.

Ein Beispiel:

• Klasse A verwendet die Klassen B und C. Klasse B wiederum verwendet Klasse C.
• Deshalb analysiert DeepQuali zunächst Klasse C.
• Anschließend folgt Klasse B, wobei die Zusammenfassung von C bereits in die Analyse einfließt. So weiß das LLM, was die aufgerufenen Methoden tun.
• Zum Schluss wird Klasse A analysiert – nun mit den Zusammenfassungen von B und C als zusätzlichen Kontext.
  

Das KI-Modell betrachtet dabei nicht nur, was die Methoden tun, sondern auch grundlegende Architekturfragen: Hat die Klasse einen klaren Fokus? Wie stark ist sie gekoppelt? Sind ihre Schnittstellen einfach und verständlich?

Die Zusammenfassungen helfen also nicht nur dir, den Code schneller zu verstehen. Sie machen ihn auch für die KI handhabbar, ohne dass wir ihr den gesamten Quellcode auf einmal übergeben – und damit ziemlich sicher das Kontextfenster sprengen.

Alle Ergebnisse landen anschließend in einem Index, für den DeepQuali derzeit OpenSearch nutzt. Dort kannst du sie abrufen, filtern oder dich bequem über eine UI durchklicken.

Von Klassen zu Paketen

Danach geht es eine Ebene höher: Die Ergebnisse der einzelnen Klassen fließen in die Analyse ihrer Pakete ein. Bei übergeordneten Paketen werden wiederum die Analysen der enthaltenen Unterpakete berücksichtigt. So arbeitet sich DeepQuali (bottom-up) von den tiefsten Paketen Schritt für Schritt bis zum Root-Package vor. Am Ende entsteht ein Gesamtbild der Projektstruktur – einschließlich Hinweisen auf Schichten, Architekturpatterns und Anti-Patterns.

Skalierbare Analysen durch kompakte Zusammenfassungen

Viele Ansätze zur Codeanalyse stoßen bei großen Projekten schnell an ihre Grenzen: Irgendwann wird der Input für das KI-Modell schlicht zu umfangreich. DeepQuali löst dieses Problem mit einem agglomerativen Ansatz und verdichtet die Informationen schrittweise. Statt Zehntausende Zeilen Code auf einmal in das Modell zu kippen, erstellt es kompakte Zusammenfassungen, die anschließend als Kontext dienen. So bleiben die Prompts überschaubar und die Ergebnisse aussagekräftig – selbst bei sehr großen Codebasen.

Ergebnisse, die wirklich weiterhelfen

Die KI bewertet nicht einfach Codezeilen oder abstrakte LOC-Werte. Stattdessen richtet sie den Blick auf das, was für Entwickler wirklich relevant ist:

• Stärken: klare Schichtentrennung, intuitive API, gute Testbarkeit

• Risiken: eine zu komplexe OrderProcessor-Klasse, enge Kopplung an Datenbankdetails

• Empfehlung: Geschäftslogik und Datenbankzugriff im OrderProcessor voneinander trennen

So entstehen kurze, fokussierte Einschätzungen mit konkreten Hinweisen, die sich direkt umsetzen lassen.

Flexibel dank Scripting

Ein interessantes Detail, ohne zu sehr ins Technische abzutauchen: DeepQuali wurde von Anfang an auf Erweiterbarkeit ausgelegt – mit Scripting als zentralem Baustein. Dadurch lässt es sich leicht an neue Anwendungsfälle anpassen: von Architekturbewertungen über Codequalitätsprüfungen bis hin zu speziellen Szenarien wie der „Code-Archäologie“ in Legacy-Systemen. Neue Funktionen können einfach über Groovy, JavaScript oder eine andere JSR223-kompatible Skriptsprache ergänzt werden.

Beispiele

Wie die Ergebnisse von DeepQuali konkret aussehen, zeigen die folgenden beiden Beispiele:

1. Die Zusammenfassung des Pakets de.deepquali.impl.Llm:

• purpose: Implementierungen von LLM-Chatbots für verschiedene Anbieter
• functionalSummary: Bündelt die Anbindung verschiedener LLM-Anbieter, darunter OpenAI, Anthropic Claude, Google Gemini und OpenAI-kompatible Dienste. Verarbeitet Prompts, kommuniziert mit den jeweiligen APIs, extrahiert die Antworten und erfasst den Tokenverbrauch. Anbieterspezifische Konfigurationen und Tuning-Parameter werden direkt in die Prompts eingebettet.

Du hast keine einzige Zeile Code gesehen und weißt trotzdem schon, wofür dieses Paket zuständig ist. Stell dir vor, du steigst neu in ein Projekt ein: keine Dokumentation, kein Onboarding – oder du übernimmst plötzlich ein gigantisches Legacy-System. DeepQuali schafft diese Art von Überblick für jedes einzelne Paket. Hilfreich? Jau!

2. Die Architekturbewertung für de.deepquali.impl.dependencies.ClassAnalyzer

Empfehlungen

• Die Visitor-Implementierungen in eigene Top-Level-Klassen auslagern, um die Lesbarkeit zu verbessern und die Verschachtelung zu reduzieren.
• Die Aufrufe von ClassReader.accept() mit einer umfassenden Fehlerbehandlung absichern, damit fehlerhafter Bytecode kontrolliert verarbeitet werden kann.
• Eine Abstraktionsschicht über ASM einführen, um die direkte Kopplung zu verringern und Tests mit Mock-Implementierungen zu vereinfachen.

Risiken

• Die Implementierung ist stark an ASM gekoppelt. Dadurch lässt sich das Framework für die Bytecode-Analyse nur schwer austauschen.

• Das tief verschachtelte Visitor-Pattern mit anonymen inneren Klassen erschwert die Lesbarkeit und Wartung.

• Fehlerhafter Bytecode oder Probleme beim ASM-Parsing werden bislang nur unzureichend abgefangen und können zu unerwarteten Abstürzen führen.

Stärken

• Klare Trennung der Verantwortlichkeiten (Separation of Concerns) durch eigene Visitor-Klassen wie DependencyGraphCollector, die dem ASM-Visitor-Pattern folgen.

• Gut dokumentierte öffentliche API mit ausführlichem Javadoc zu den Vorteilen und Grenzen der Bytecode-Analyse.

• Thread-sicheres Design durch ein Enum-Singleton und unveränderliche statische Methoden.
  

Fazit

Ein insgesamt gut aufgebautes Werkzeug zur Bytecode-Analyse mit klarer API und guter Dokumentation. Schwächen zeigt es vor allem bei der engen Kopplung an ASM und der komplexen, verschachtelten Visitor-Implementierung.

Was meinst du: Vermittelt dir dieser Auszug ein Gefühl dafür, wo die Architektur solide ist und an welchen Stellen es hakt? Und sind die Empfehlungen konkret genug, um daraus die nächsten Schritte abzuleiten?

Technische Schulden frühzeitig erkennen

Entwicklungszyklen werden immer kürzer, der Zeitdruck steigt. Dabei entstehen schnell technische Schulden, die im Arbeitsalltag zunächst kaum auffallen – bis sie irgendwann teuer werden. DeepQuali soll dabei helfen, solche Probleme frühzeitig sichtbar zu machen: nicht mit abstrakten Diagrammen, sondern mit konkreten Hinweisen direkt aus dem Code.

Manchmal fühlt sich das fast wie Code-Archäologie an: Ein altes Projekt ohne Dokumentation? Kein Problem. DeepQuali arbeitet sich durch die Klassen und Pakete und liefert innerhalb weniger Minuten einen Überblick, für den du sonst deutlich länger bräuchtest.

Schichten und God Classes – erste Erfahrungen mit DeepQuali

So weit die Theorie. Aber was passiert, wenn DeepQuali auf die Realität trifft? Auf unübersichtlichen, komplexen und undokumentierten Code – du kennst die üblichen Verdächtigen.

Zeit für Erfahrungen aus der Praxis!

Eines unserer größten Aha-Erlebnisse: Schon die kurzen Beschreibungen, was eine Klasse tut und wie sie in das System eingebettet ist, verändern den Blick auf ein Projekt enorm. Ursprünglich waren diese Zusammenfassungen nur als Kontext für die Architekturbewertung durch das LLM gedacht. In der Praxis haben sie sich aber als äußerst hilfreich erwiesen, um ein Projekt schneller zu verstehen.

Das Abstraktionsniveau, das Modelle wie ChatGPT oder Claude dabei erreichen, ist beeindruckend. DeepQuali wird so zum Navigationssystem für Codebasen: Repository rein, grobe Landkarte raus. Gerade bei unbekanntem Code spart das enorm viel Zeit.

Auch die Architekturbewertungen funktionieren in der Praxis erstaunlich gut: Das LLM erkennt zuverlässig, ob ein Projekt sinnvoll in Schichten gegliedert ist, ob die Domänenlogik sauber vom Framework getrennt wurde – oder ob sich irgendwo ein God-Class-Monster versteckt.

DeepQuali im Arbeitsalltag

Im Entwicklungsalltag sehen wir vor allem zwei Einsatzmöglichkeiten für DeepQuali:

• Ad-hoc-Analysen: Du möchtest dir schnell einen Überblick über ein Projekt verschaffen – beim Einstieg, während eines Reviews oder bei einer Runde „Code-Archäologie“.

• Integration in CI/CD-Pipelines: DeepQuali lässt sich als leichtgewichtiges Analysewerkzeug in bestehende Pipelines integrieren. Dabei soll es bewusst kein hartes Quality Gate bilden, sondern auf mögliche Probleme hinweisen – denn die Bewertungen können von Lauf zu Lauf leicht schwanken.

Erkenntnisse und Ausblick

• Die Qualität der Prompts ist absolut entscheidend für die Ergebnisse. Wir haben in diesem Bereich bereits viel gelernt – sind aber sicher noch nicht am Ziel.
• LLMs liefern selbst bei einem festen Seed nicht immer exakt dieselben Antworten. Mit einer niedrigeren Temperatur – zum Beispiel 0,3 – werden die Bewertungen stabiler. Eine gewisse Schwankung bleibt jedoch bestehen, und das ist durchaus erwünscht: Manchmal liefert gerade eine unerwartete Perspektive den entscheidenden Denkanstoß.
• Aktuell konzentriert sich DeepQuali auf JVM-Sprachen wie Java, Kotlin, Scala und Groovy. Mithilfe von Shallow Parsern wollen wir künftig auch weitere Sprachen und Ökosysteme unterstützen.
• Künftig wollen wir auch Unit-Tests in die Analyse einbeziehen. So erhältst du nicht nur einen Überblick über die Architektur, sondern auch darüber, wie gut die Software durch Tests abgesichert ist und wo mögliche Schwachstellen liegen.

Fazit

DeepQuali ist keine Silver Bullet. Aber es ist ein Werkzeug, das Zeit spart und wertvolle Einblicke liefert. Es macht Stärken und Schwächen sichtbar, gibt Denkanstöße für bessere Architekturentscheidungen und hilft dir, dich schneller in unbekannten oder gewachsenen Codebasen zurechtzufinden.

Wichtig ist dabei: DeepQuali bewertet die Struktur, nicht die fachliche Korrektheit. Es kann dir nicht sagen, ob deine Geschäftslogik sinnvoll ist oder die Architektur tatsächlich zu deiner Domäne passt. Dafür – und für viele weitere Fragen – bleibt menschliche Expertise unverzichtbar.

Für uns ist DeepQuali vor allem ein Beitrag dazu, Softwarequalität transparenter und greifbarer zu machen. Und wenn es dir hilft, dich in deinem nächsten Projekt schneller zurechtzufinden, hat es seinen Zweck erfüllt.