Die Rolle der Codequalität: Kritische Kennzahlen und ihre Auswirkungen

Codequalität ist messbar. Das klingt selbstverständlich, bis man versucht, die Frage zu beantworten, die ein CTO vor der Anschaffung eines Softwareprodukts oder ein technischer Leiter vor Beginn eines Refactoring-Programms stellt: Woher weiß man, dass der Code gut ist? „Er funktioniert“ reicht nicht aus. „Das Team hat ihn geprüft“ reicht nicht aus. Die Antwort erfordert objektive, konsequent angewandte Messgrößen: zyklomatische Komplexität pro Funktion, Wartbarkeitsindex pro Modul, Fehlerdichte pro tausend Zeilen, Testabdeckung pro Komponente, Codeänderung pro Datei und Sprint. Jede dieser Kennzahlen liefert einen Wert. Diese Werte lassen sich analysieren, vergleichen und als Grundlage für Maßnahmen nutzen.

Die Herausforderung besteht darin, dass Codequalitätsmetriken nicht austauschbar und nicht universell interpretierbar sind. Ein hoher Wartbarkeitsindex in einem COBOL-Programm hat eine andere Bedeutung als derselbe Wert in einem Python-Skript. Eine zyklomatische Komplexität von 15 ist in einem gut getesteten Zustandsautomaten akzeptabel, stellt aber in einer Validierungsfunktion ein schwerwiegendes Problem dar. Eine Fehlerdichte von 2 Fehlern pro KLOC ist in der Systemprogrammierung hervorragend, in einer sicherheitskritischen eingebetteten Anwendung jedoch alarmierend. Um Metriken sinnvoll nutzen zu können, muss man verstehen, was jede einzelne misst, welche Faktoren ihren Wert beeinflussen und welche Schwellenwerte im jeweiligen Kontext angemessen sind. Der Rest dieses Artikels liefert genau diese Informationen.

Was ist Codequalität?

Codequalität beschreibt, inwieweit Quellcode messbare Eigenschaften erfüllt, die ihn korrekt, wartbar, lesbar, effizient, sicher und testbar machen. Keine einzelne Eigenschaft definiert Qualität isoliert. Korrekt laufende, aber unlesbare Codes verlieren mit jeder Änderung an Qualität, da Entwickler, die sie nicht verstehen, sie nicht sicher modifizieren können. Lesbarer, aber ungetesteter Code birgt versteckte Fehler. Getesteter, aber strukturell komplexer Code häuft mit zunehmender Komplexität immer mehr Fehler an, da die Wahrscheinlichkeit steigt, dass eine Änderung unerwartete Probleme verursacht.

Die Norm ISO/IEC 25010 definiert formal acht Softwarequalitätsmerkmale: funktionale Eignung, Leistungsfähigkeit, Kompatibilität, Benutzerfreundlichkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit und Portabilität. Speziell für Quellcode lassen sich Wartbarkeit, Zuverlässigkeit (annähernd durch Fehler- und Komplexitätsmetriken), Sicherheit (mittels statischer Analyse) und funktionale Eignung (mittels Testabdeckung) direkt aus dem Code selbst messen, anstatt aus dem Laufzeitverhalten. Die übrigen Merkmale erfordern die Ausführung des Codes. Codequalitätsmetriken erfassen daher nur einen definierten und wichtigen Teilbereich der Softwarequalität, nicht aber die gesamte Softwarequalität.

Warum Codequalität wichtig ist

Technische Teams wissen, warum Codequalität so wichtig ist. Für Business-Stakeholder und Teams, die dies intern begründen müssen, liegt der Zusammenhang in den Kosten und dem Zeitaufwand. Studien von McKinsey und dem Consortium for IT Software Quality (CISQ) zeigen übereinstimmend, dass Entwickler 30 bis 40 Prozent ihrer Arbeitszeit mit der Beseitigung bestehender technischer Schulden verbringen, anstatt neue Funktionen zu entwickeln. Schlechte Codequalität ist der Mechanismus, durch den sich technische Schulden anhäufen: Jeder Fehler, der nicht frühzeitig erkannt wird, jede Funktion, die komplexer als nötig ist, jeder duplizierte Logikblock, der separat gewartet werden muss, erhöht die Kosten der nächsten Änderung. Hohe Codequalität reduziert diese Kosten kontinuierlich und summiert sich über die gesamte Lebensdauer des Systems.

Codequalitätsmetriken: Vollständige Referenz

Die folgenden Kennzahlen decken alle wichtigen Kategorien der Codequalitätsmessung ab. Für jede Kennzahl werden Definition, Messmethode, zulässiger Bereich und Interpretation erläutert. Die Schwellenwerte in der Tabelle unten entsprechen gängigen Branchenstandards; Teams in sicherheitskritischen oder regulierten Umgebungen sollten strengere Schwellenwerte anwenden.

Komplexitätsmetriken

Zyklomatische Komplexität misst die Anzahl der linear unabhängigen Pfade durch eine Funktion oder Methode. Sie wurde 1976 von Thomas McCabe eingeführt und ist nach wie vor das am weitesten verbreitete Komplexitätsmaß. Die Formel zählt Entscheidungspunkte, if, else if, switch Fälle, Schleifenbedingungen, catch Blöcke und bedingte Operatoren und addieren 1. Eine Funktion ohne Verzweigungen hat eine zyklomatische Komplexität von 1.

Zyklomatische Komplexität	Dolmetschen
1-5	Einfach, leicht zu testen
6-10	Mäßig, überschaubar
11-20	Komplexe Tests gestalten sich schwierig
21-50	Sehr hohes Risiko, Refactoring empfohlen
50+	Nicht testbar, enthält mit hoher Wahrscheinlichkeit Mängel

Eine hohe zyklomatische Komplexität korreliert stark mit der Fehlerdichte. Eine in den IEEE Transactions on Software Engineering veröffentlichte Studie ergab, dass Funktionen mit einer zyklomatischen Komplexität über 10 deutlich höhere Fehlerraten aufweisen als einfachere Funktionen. Bei der Analyse der zyklomatischen Komplexität in bestehenden Codebasen besteht die Herausforderung darin, Funktionen zu finden, in denen sich über Jahre hinweg durch Wartung Entscheidungslogik angesammelt hat, ohne dass die Gesamtstruktur jemals refaktoriert wurde.

Die NPath-Komplexität zählt die Anzahl der eindeutigen Ausführungspfade einer Funktion, einschließlich der Pfade, die durch verschachtelte Bedingungen und Schleifen entstehen. Während die zyklomatische Komplexität Verzweigungen linear zählt, multipliziert die NPath-Komplexität diese: Eine Funktion mit drei aufeinanderfolgenden if-else-Blöcken hat eine zyklomatische Komplexität von 4, aber eine NPath-Komplexität von 8, da jede Bedingung unabhängig wahr oder falsch sein kann. Die NPath-Komplexität wächst exponentiell mit der Verschachtelung. Ein Wert über 200 deutet auf eine Funktion hin, die mehr Testfälle erfordern würde, als ein Team realistischerweise schreiben kann.

Kognitive Komplexität wurde von SonarSource eingeführt und misst die Verständlichkeit des Codes, nicht die Anzahl der darin enthaltenen Pfade. Verschachtelungen werden stärker bestraft als lineare Verzweigungen: ein if in einem while in einem anderen if Punktzahlen, die höher sind als drei aufeinanderfolgende if Anweisungen mit derselben zyklomatischen Komplexität. Die kognitive Komplexität korreliert besser mit den tatsächlichen Schwierigkeiten, die Entwickler beim Lesen von Code erleben. Eine kognitive Komplexität von über 15 pro Methode wird in der Regel zur Überprüfung markiert; über 25 deutet sie auf eine Funktion hin, die die meisten Entwickler als schwer verständlich empfinden werden.

Halstead Metrics leitet eine Familie von Kennzahlen aus vier Zählungen im Quellcode ab: verschiedene Operatoren (n1), verschiedene Operanden (n2), Gesamtzahl der Operatoren (N1) und Gesamtzahl der Operanden (N2). Daraus berechnet Halstead:

• Volumen (N × log2(n)): die Größe der Implementierung im Hinblick auf den Informationsgehalt
• Schwierigkeit (n1/2 × N2/n2): eine Schätzung, wie schwierig es ist, den Code zu schreiben oder zu verstehen.
• Aktion (Umfang × Schwierigkeitsgrad): der geschätzte gesamte mentale Aufwand zur Implementierung oder zum Verständnis des Codes

Halstead-Metriken eignen sich besonders gut, um Funktionen ähnlicher zyklomatischer Komplexität zu vergleichen und festzustellen, welche schwerer verständlich ist. Eine Funktion mit 10 Verzweigungen über eindeutig benannte Variablen weist eine geringere Halstead-Schwierigkeit auf als eine mit 10 Verzweigungen über berechnete Indizes und einstellige Bezeichner.

Kennzahlen zur Wartbarkeit

Der Maintainability Index ist eine zusammengesetzte Metrik, die ursprünglich von Paul Oman und Jack Hagemeister entwickelt und später von Microsoft Visual Studio als Standardmaß für die Wartbarkeit übernommen wurde. Er kombiniert Halstead-Volumen, zyklomatische Komplexität und Codezeilen zu einem einzigen Wert.

Die Visual Studio-Formel liefert einen Wert zwischen 0 und 100:

Wartbarkeitsindex	Rating
20-100	Nachhaltig (grün)
10-19	Mittlerer Wartungsaufwand (gelb)
0-9	Schwer zu pflegen (rot)

Der Wartbarkeitsindex ist eine zusammenfassende Statistik. Er eignet sich am besten zur Identifizierung von Ausreißern, also Dateien oder Modulen mit schlechter Bewertung, weniger für detaillierte Vergleiche zwischen Modulen im grünen Bereich. In Python ist der radon Die Bibliothek berechnet den Wartbarkeitsindex direkt. In Visual Studio wird er im Fenster „Codemetriken“ angezeigt. statische Code-Analyse Bei Plattformen ist der Wartbarkeitsindex typischerweise einer der Standardausgaben neben der zyklomatischen Komplexität und der Anzahl der Codezeilen.

Die Anzahl der Codezeilen (Lines of Code, LOC) und die Anzahl der Codezeilen (Kloaks of Code, KLOC) messen die Größe der Codebasis in Zeilen bzw. Tausenden von Zeilen. Die Anzahl der Codezeilen allein sagt nichts über die Qualität aus, liefert aber wichtige Bezugsgrößen für andere Metriken: Die Fehlerdichte entspricht der Anzahl der Fehler pro Kloakenzeile, die Kommentardichte den Kommentaren pro Codezeile und die Testdichte den Testzusicherungen pro Codezeile. Die Anzahl der Codezeilen skaliert auch die Komplexität: Eine 500-zeilige Funktion mit einer zyklomatischen Komplexität von 20 stellt ein deutlich größeres Problem dar als eine 50-zeilige Funktion mit demselben Wert.

Code-Churn bezeichnet die Rate, mit der sich Code im Laufe der Zeit ändert. Gemessen wird die Summe aus hinzugefügten, gelöschten und geänderten Zeilen pro Datei und Zeiteinheit. Hoher Code-Churn deutet auf Instabilität hin: Häufig geänderter Code reagiert möglicherweise auf ein von Anfang an fehlerhaftes Design, instabile Anforderungen oder Fehler, die immer wieder Patches erfordern. Untersuchungen von Microsoft ergaben, dass die 10 % am stärksten von Code-Churn betroffenen Dateien fünfmal mehr Fehler enthielten als Dateien mit geringem Churn. Die Beobachtung von Code-Churn und Fehlerraten zeigt, ob häufige Änderungen die Qualität verbessern oder neue Probleme verursachen.

Code-Coverage-Metriken

Die Unit-Test-Abdeckung gibt den Prozentsatz der Codezeilen, -zweige oder -bedingungen an, die von Unit-Tests ausgeführt werden. Am aussagekräftigsten ist die Zweigabdeckung: Sie zeigt an, ob jede Entscheidung im Code von mindestens einem Test sowohl im wahren als auch im falschen Fall erreicht werden kann. Die Zeilenabdeckung lässt sich leichter manipulieren: Ein Test, der jede Zeile ausführt, ohne etwas zu überprüfen, erreicht 100 % Zeilenabdeckung, findet aber keine Fehler.

Branchenstandards für die Unit-Test-Abdeckung:

• Unter 50 %: unzureichend, die meisten Mängel werden durch die Tests nicht erkannt.
• 50–75 %: moderat, wichtige Pfade abgedeckt, Grenzfälle wahrscheinlich übersehen
• 75–90 %: gut für die meisten Anwendungscodes
• Über 90 %: geeignet für sicherheitskritische oder hochzuverlässige Systeme

Die Codeabdeckung in sicherheitskritischen Anwendungen unterliegt strengeren Standards. DO-178C für Luftfahrtsoftware und IEC 61508 für funktionale Sicherheit spezifizieren Abdeckungsanforderungen (MC/DC-Abdeckung für höchste Kritikalitätsstufen), die über die Möglichkeiten von Standard-Komponententests hinausgehen. Zur Verbesserung der Codequalität in sicherheitskritischen Anwendungen werden Abdeckungswerkzeuge benötigt, die die Bedingungs-/Entscheidungsabdeckung verfolgen und die von den Zertifizierungsbehörden geforderten formalen Nachweise erbringen können.

Die Testdichte ergänzt die Testabdeckung, indem sie die Anzahl der Testzusicherungen im Verhältnis zur Größe des Produktionscodes misst. Eine hohe Testabdeckung bei geringer Testdichte kann darauf hindeuten, dass Tests Code ausführen, ohne das Verhalten sinnvoll zu überprüfen. Eine hohe Testdichte bei geringer Testabdeckung deutet hingegen darauf hin, dass sich die Tests auf einen kleinen Teil der Codebasis konzentrieren.

Fehlermetriken

Die Fehlerdichte (auch Bugdichte genannt) gibt die Anzahl bestätigter Fehler pro tausend Codezeilen (KLOC) an. Sie ist das direkteste quantitative Maß für die Korrektheit von Code. Branchenvergleiche von CISQ zeigen, dass kommerzielle Standardsoftware vor dem Testen durchschnittlich 15–50 Fehler pro KLOC aufweist; nach dem Testen und der Veröffentlichung liegt die Fehlerrate hochwertiger kommerzieller Software typischerweise unter einem Fehler pro KLOC.

Ergebnisse der statischen Analyse Die ungefähre Fehlerdichte wird ermittelt, bevor Fehler durch Tests oder den Produktionseinsatz bestätigt werden. Tools wie SonarQube, Checkmarx und SMART TS XL Die Codebasis wird auf Muster bekannter Fehler- und Schwachstellenklassen hin analysiert, wodurch potenzielle Probleme nach Schweregrad kategorisiert werden. Das Verhältnis kritischer und blockierender Fehler zu Codezeilen (LOC) liefert frühzeitig Hinweise auf die Codequalität, bevor der Code getestet wird.

Die Code-Smell-Dichte misst das Vorkommen von Anti-Patterns, doppeltem Code, übermäßig langen Funktionen, starker Klassenkopplung, Feature-Envy und God-Objekten pro KLOC. Code-Smells verursachen zwar keine unmittelbaren Fehler, sagen aber zukünftige Defekte und Wartungskosten voraus. In einer Codebasis mit hoher Code-Smell-Dichte sind die Kosten jeder zukünftigen Änderung erhöht, da jede Änderung die angesammelten strukturellen Probleme überwinden muss.

Lesbarkeits- und Stilmetriken

Kommentardichte Das Verhältnis von Kommentarzeilen zu Codezeilen ist entscheidend. Optimale Werte variieren je nach Programmiersprache und Teamkonventionen, liegen aber typischerweise zwischen 10 und 30 %. Werte unter 10 % können auf unzureichend dokumentierten Code hindeuten; Werte über 50 % können auf so komplexen Code hindeuten, dass er ausführliche Erklärungen nicht offensichtlicher Logik erfordert. Die Qualität der Kommentare ist wichtiger als ihre Quantität: Ein Kommentar, der die Funktion des Codes wiederholt (// increment i by 1) fügt nichts hinzu, wohingegen ein Kommentar, der erklärt, warum ein bestimmter Algorithmus gewählt wurde, einen erheblichen Mehrwert bietet.

Die Einhaltung von Namenskonventionen misst den Prozentsatz der Bezeichner (Variablen, Funktionen, Klassen), die den Namenskonventionen des Projekts entsprechen. Automatisierte Tools können die Einhaltung von Namenskonventionen im Rahmen der Linting-Konfiguration erzwingen. Konsistente Benennung ist eine der wirkungsvollsten Maßnahmen zur Verbesserung der Lesbarkeit, da Entwickler so den Zweck eines Bezeichners allein anhand seines Namens erschließen können. Dies reduziert die kognitive Belastung beim Lesen unbekannten Codes.

Die Code-Duplizierungsrate misst den Prozentsatz des Quellcodes, der an mehreren Stellen dupliziert ist. Eine Duplizierung von über 5 % wird üblicherweise als problematisch eingestuft. Duplizierter Code vervielfacht den Wartungsaufwand: Ein Fehler in der duplizierten Logik muss in jeder Kopie gefunden und behoben werden, und Verhaltensänderungen müssen in allen Kopien konsistent angewendet werden. Duplizierung verschleiert zudem die tatsächliche Größe des Quellcodes: Ein System, das scheinbar 100,000 Zeilen Code umfasst, kann 40,000 Zeilen einzigartige Logik und 60,000 kopierte Zeilen enthalten.

Sicherheits- und technische Schuldenkennzahlen

Die technische Schuldenquote wird von SonarQube als Verhältnis der geschätzten Kosten für die Behebung der bestehenden Probleme zu den geschätzten Entwicklungskosten des Quellcodes definiert. Eine technische Schuldenquote unter 5 % gilt als Indikator für einen sauberen Quellcode; über 20 % deutet sie auf erhebliche Schulden hin, die die zukünftige Entwicklung deutlich verlangsamen werden.

Die Sicherheits-Hotspot-Dichte zählt die Anzahl der Sicherheits-Hotspots – also Code-Muster, die einer Sicherheitsüberprüfung bedürfen (keine bestätigten Schwachstellen) – pro KLOC. Beispiele hierfür sind nicht parametrisierte SQL-Abfragen, die Verwendung veralteter kryptografischer Funktionen und die Verarbeitung nicht validierter Eingaben. Statische Analysetools identifizieren diese Muster und kennzeichnen sie als Elemente, die einer manuellen Sicherheitsüberprüfung bedürfen.

Die Schwachstellendichte gibt die Anzahl bestätigter Sicherheitslücken pro KLOC an, typischerweise kategorisiert nach CVSS-Schweregrad. Diese Kennzahl ist besonders aussagekräftig im Kontext von Sicherheitsaudits nach der Veröffentlichung oder kontinuierlichen Sicherheitsüberwachungssystemen.

Wie man die Codequalität misst: Ein praktischer Ansatz

Die Messung der Codequalität ist keine einmalige Aktion, sondern ein kontinuierlicher Prozess, der in den Entwicklungsprozess integriert ist. Ein pragmatischer Vier-Phasen-Ansatz eignet sich gut für Teams, die mit einer ungemessenen Codebasis beginnen.

Phase 1: Festlegung einer Ausgangsbasis. Führen Sie vor jeglichen Änderungen eine vollständige statische Codeanalyse durch. Erfassen Sie die aktuellen Werte für die zyklomatische Komplexitätsverteilung, den Wartbarkeitsindex pro Datei, die Fehlerdichte, die Codeabdeckung und die Duplikationsrate. Diese Ausgangsbasis dient als Vergleichspunkt für alle zukünftigen Messungen. Ohne eine solche Ausgangsbasis lässt sich nicht feststellen, ob Änderungen die Qualität verbessern oder verschlechtern.

Phase 2: Schwellenwerte definieren. Legen Sie für jede Kennzahl einen dem jeweiligen Kontext entsprechenden, akzeptablen Schwellenwert fest. Eine kommerzielle Webanwendung und ein sicherheitskritisches Medizinprodukt haben unterschiedliche Schwellenwerte. Dokumentieren Sie diese Schwellenwerte in den Qualitätsstandards des Projekts und stellen Sie sie dem gesamten Team zur Verfügung.

Phase 3: Integration in CI/CD. Konfigurieren Sie die CI-Pipeline so, dass bei jedem Commit oder Pull Request wichtige Metriken berechnet werden. Kennzeichnen Sie Änderungen, die eine Metrik außerhalb ihres zulässigen Bereichs verschieben. Blockieren Sie Merges, die neuen Code mit einer zyklomatischen Komplexität oberhalb des Schwellenwerts einführen, die Codeabdeckung unter den Schwellenwert reduzieren oder kritische Ergebnisse der statischen Codeanalyse liefern. Dadurch werden Metrikschwellenwerte von Richtlinien zu verbindlichen Standards.

Phase 4: Trends statt Momentaufnahmen analysieren. Einzelne Messwerte liefern zwar Informationen, Trends ermöglichen jedoch konkrete Maßnahmen. Steigende Code-Änderungen in einem bestimmten Modul, sinkende Codeabdeckung im Laufe des Release-Zyklus oder ein rückläufiger Wartbarkeitsindex für eine bestimmte Datei deuten auf Probleme hin, die bei einer Momentaufnahme möglicherweise übersehen werden. Analysieren Sie die Metriktrends in jeder Sprint-Retrospektive.

Codequalitätsmetriken in Unternehmens-, agilen und sicherheitskritischen Kontexten

Codequalitätsmetriken in der agilen Entwicklung

Agile Teams stehen vor einer besonderen Herausforderung im Hinblick auf Codequalitätsmetriken: Der Fokus auf die Bereitstellung funktionierender Software in kurzen Zyklen kann Druck erzeugen, die Software auszuliefern, bevor Qualitätsprobleme behoben sind. Die Lösung besteht nicht darin, Metriken aufzugeben, sondern sie in die Definition von „Fertig“ zu integrieren. Eine User Story ist nicht abgeschlossen, wenn die Funktion funktioniert; sie ist abgeschlossen, wenn die Funktion funktioniert und der neue Code die Qualitätsstandards des Teams erfüllt.

Frühindikatoren in agilen Kontexten, also Kennzahlen, die zukünftige Probleme vorhersagen, bevor sie auftreten, umfassen die Code-Churn-Rate, die pro Sprint neu entstehenden technischen Schulden und die Entwicklung der Anzahl statischer Analyseergebnisse pro Release. Spätindikatoren, also Kennzahlen, die bereits erzielte Ergebnisse messen, umfassen die Fehlerdichte im Test, den Zeitaufwand für Wartung im Vergleich zu neuen Funktionen und die Produktionsstörungsrate pro Release.

Codequalität für die technische Due Diligence

Die technische Due-Diligence-Prüfung bei M&A-Transaktionen, der Auswahl von Anbietern und der Systembeschaffung erfordert eine strukturierte Bewertung der Codequalität der gesamten Codebasis. Die wichtigsten Kennzahlen in diesem Zusammenhang sind:

• Verteilung des WartbarkeitsindexWelcher Prozentsatz des Quellcodes fällt in die roten, gelben und grünen Zonen?
• Verhältnis der technischen SchuldenWie hoch sind die geschätzten Sanierungskosten im Verhältnis zu den Entwicklungskosten?
• Defektdichte: Wie viele bekannte Defekte gibt es pro KLOC, und wie verhält sich dies zu Branchenstandards?
• TestabdeckungWelcher Prozentsatz der Codebasis ist durch automatisierte Tests abgedeckt und auf welcher Ebene (Zeile, Zweig, Bedingung)?
• Abhängigkeitsgesundheit: wie viele externe Abhängigkeiten bestehen, wie viele davon veraltet oder nicht mehr genutzt werden und wie stark die Architektur gekoppelt ist
• Code-DuplizierungWelcher Anteil des Quellcodes ist dupliziert und gibt somit ein Wartungsrisiko an?

Wie im Kontext der Wirkungsanalyse für die Bewertung von Unternehmenscode untersucht wurde , ist es für eine genaue Due-Diligence-Prüfung unerlässlich zu verstehen, nicht nur, wie die einzelnen Komponenten bei Qualitätsmetriken abschneiden, sondern auch, wie die Komponenten voneinander abhängen: Ein isoliertes Modul von geringer Qualität kann überschaubare Sanierungskosten verursachen, während dasselbe Modul im Zentrum eines dichten Abhängigkeitsdiagramms ein viel größeres Risiko darstellt.

Codequalität in sicherheitskritischen und Fintech-Anwendungen

Sicherheitskritische Anwendungen in der Luftfahrt, der Automobilindustrie, der Medizintechnik und der industriellen Steuerungstechnik erfordern Codequalitätsstandards, die über die übliche kommerzielle Software hinausgehen. Wesentliche Unterschiede:

• Die Grenzen der zyklomatischen Komplexität werden typischerweise auf 10 oder niedriger festgelegt, und Ausnahmen bedürfen einer formalen Begründung.
• Die Deckungsanforderungen verwenden MC/DC (Modified Condition/Decision Coverage) anstelle von Leitungs- oder Zweigdeckung.
• Statische Analysen müssen mit zertifizierten Werkzeugen durchgeführt werden, und Verstöße müssen dokumentiert und behoben oder formell akzeptiert werden.
• Die Codeänderungsrate wird als Sicherheitsindikator überwacht: Hohe Änderungsraten in sicherheitskritischen Modulen lösen eine zusätzliche Überprüfung und erneute Validierung aus.

Fintech-Anwendungen stehen unter ähnlichem Druck durch regulatorische Rahmenbedingungen. PCI DSS fordert sichere Codierungsstandards und Code-Review-Prozesse. Die SOX-Compliance für Finanzberichtssysteme verlangt eine dokumentierte Rückverfolgbarkeit von den Anforderungen über den Code bis hin zu den Tests. Codequalitätsmetriken liefern den objektiven Nachweis, dass diese Prozesse funktionieren: Abdeckungsberichte belegen die Existenz von Tests, statische Analyseberichte zeigen, dass bekannte Schwachstellen überprüft wurden, und Komplexitätsberichte belegen, dass Prüfer den Code angemessen bewerten konnten.

Codequalitätsmetriken nach Sprache

Python-Codequalitätsmetriken kann berechnet werden mit radon (zyklomatische Komplexität und Wartbarkeitsindex), pylint (Code-Smells und Stilverstöße), coverage.py (Testabdeckung), bandit (Sicherheitsprobleme) und mypy or pyright (Typkorrektheit). Der Wartbarkeitsindex in radon Verwendet eine modifizierte Halstead-Formel, kalibriert für Python. Note A liegt über 20, Note B zwischen 10 und 20, Note C unter 10.

RPG-Codequalität Auf IBM i sind spezielle Tools erforderlich, da Standard-Qualitätsmetrik-Tools die RPG-Syntax nicht analysieren können. SMART TS XL bietet zyklomatische Komplexität, Codezeilen und Abhängigkeitsanalyse für RPG-Programme, was insbesondere für IBM i-Umgebungen wertvoll ist, die große Legacy-Codebasen verwalten, bei denen die Qualitätsmessung bisher nicht automatisiert werden konnte.

Kennzahlen für Code-Reviews

Die Codeüberprüfung ist eine Maßnahme zur Qualitätssicherung, deren Wirksamkeit messbar ist:

• Abdeckung überprüfenProzentsatz des eingecheckten Codes, der vor dem Zusammenführen einer formalen Überprüfung unterzogen wurde.
• Laut Überprüfung festgestellte MängelDie Anzahl der während der Überprüfung festgestellten Fehler im Verhältnis zur Größe des überprüften Änderungssatzes.
• Bearbeitungszeit für die ÜberprüfungDie Zeitspanne vom Öffnen eines Pull Requests bis zu dessen Überprüfung und Zusammenführung
• Bewertungsquote für Kommentare: der Prozentsatz der Kommentare in den Rezensionen, die zu einer Codeänderung führen, im Vergleich zu denen, die abgelehnt werden

Leistungsstarke Teams weisen typischerweise eine Review-Abdeckung von über 90 %, durchschnittlich 1–3 gefundene Fehler pro Review und 100 geprüften Codezeilen sowie kurze Bearbeitungszeiten auf. Die Review-Metriken helfen dabei zu erkennen, ob ein Code-Review als Qualitätssicherung oder lediglich als Formalität dient.

Kontinuierliche Codequalitätsüberwachung

Eine einmalige Messung der Codequalität ist deutlich weniger aussagekräftig als die kontinuierliche Überwachung. Die Codequalität ist keine statische Eigenschaft einer Codebasis; sie ändert sich mit jedem Commit. Eine Codebasis, die heute gute Werte aufweist, kann sich innerhalb von drei Sprints unter Zeitdruck erheblich verschlechtern, wenn die Qualitätsmetriken nicht kontinuierlich erfasst werden.

Eine effektive kontinuierliche Überwachung der Codequalität umfasst:

• Berechnung der Kennzahl pro Commit: Zyklomatische Komplexität und Ergebnisse der statischen Analyse werden bei jedem Push berechnet.
• Trend-Dashboards: Visuelle Darstellungen wichtiger Kennzahlen im Zeitverlauf, täglich oder pro Release aktualisiert.
• Qualitätsgates in CI/CD: automatisierte Durchsetzung von Mindestschwellenwerten für Kennzahlen, die Wartbarkeit, Sicherheit und Fehlerrisiko beeinflussen
• Regressionserkennung: Gibt Warnmeldungen aus, wenn sich eine Metrik zwischen den Releases deutlich in die falsche Richtung bewegt.

Die wichtigsten Indikatoren für eine verbesserte Codequalität – also die Signale, die vorhersagen, ob die Qualität im nächsten Release besser oder schlechter ausfallen wird – sind die Richtung des Abdeckungstrends, die pro Sprint neu hinzugekommene Komplexität und das Verhältnis von behobenen zu neu entstandenen Code-Smells. Entwickeln sich diese Indikatoren in die richtige Richtung, verbessert sich die Qualität. Andernfalls ist die Verschlechterung vorhersehbar, bevor sie vollständig eingetreten ist.

Wie SMART TS XL Misst und verbessert die Codequalität

SMART TS XL Berechnet den vollständigen Satz der in diesem Artikel beschriebenen Codequalitätsmetriken für jede Sprache und Plattform in der Entwicklungsumgebung: COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, RPG, SQL und andere. Während die meisten Qualitätswerkzeuge jeweils nur eine Sprache verarbeiten, SMART TS XL Es wird ein einheitliches Qualitätsmodell des gesamten Systems erstellt, wodurch es möglich wird, die Qualität über verschiedene Sprachen hinweg zu vergleichen, Metriken auf Systemebene anstatt auf Dateiebene zu verfolgen und komponentenübergreifende Qualitätsprobleme zu identifizieren, die mit Tools für einzelne Sprachen nicht erkennbar sind.

Für Unternehmen mit großen, mehrsprachigen Codebasen, statische Code-Analyse Fähigkeit von SMART TS XL liefert die Basismessung, die für die technische Due-Diligence-Prüfung, die Planung der Modernisierung bestehender Systeme und die kontinuierliche Qualitätsverbesserung gleichermaßen erforderlich ist. Abhängigkeitszuordnung Die Fähigkeit erweitert die Qualitätsbewertung um strukturelle Aspekte: von welchen Komponenten die größte Abhängigkeit besteht, welche Änderungen die größten Auswirkungen haben und welche Bereiche der Codebasis das höchste Wartungsrisiko darstellen, wenn Qualitätsmetriken mit der Abhängigkeitszentralität kombiniert werden.

SMART TS XLDie Codequalitätsmetriken von [Name der Software] lassen sich über die API in DevOps-Pipelines integrieren und ermöglichen so Qualitätsprüfungen auf der CI/CD-Ebene. Wenn ein Commit eine Funktion mit zyklomatischer Komplexität über dem Schwellenwert einführt, die Codeabdeckung unter das konfigurierte Minimum reduziert oder einen kritischen Befund der statischen Codeanalyse verursacht, kann die Pipeline den Build mit einer spezifischen Diagnose abbrechen. Diese Diagnose informiert den Entwickler genau darüber, was gemessen wurde und warum der Schwellenwert überschritten wurde. Dadurch wird die Qualitätssicherung von Audits nach der Veröffentlichung auf Feedback während der Entwicklung verlagert. So werden die Kosten für Qualitätsprobleme gesenkt, indem diese genau dort erkannt werden, wo sie am kostengünstigsten zu beheben sind.

Codequalität ist eine Teamdisziplin, kein Bericht.

Der Wert von Codequalitätsmetriken hängt allein davon ab, wie Teams sie nutzen. Ein vierteljährlicher Bericht zur Codequalität, auf den niemand reagiert, ist schlimmer als gar kein Bericht, denn er erweckt den Eindruck, die Qualität werde verwaltet, während der Code unkontrolliert verfällt. Metriken werden dann wertvoll, wenn sie konkrete Maßnahmen auslösen: beispielsweise wenn ein plötzlicher Anstieg der zyklomatischen Komplexität in einer neuen Funktion eine Refactoring-Diskussion anstößt, bevor die Funktion zusammengeführt wird; wenn ein Rückgang der Codeabdeckung in einem Modul einen Test-Sprint auslöst; oder wenn eine steigende Fehlerdichte in einer bestimmten Komponente eine formale Überprüfung des Designs dieser Komponente nach sich zieht.

Um diese Kultur aufzubauen, müssen Kennzahlen zum richtigen Zeitpunkt – während der Entwicklung, nicht erst nach der Veröffentlichung – sichtbar gemacht und mit konkreten Teamverpflichtungen verknüpft werden. Teams, die ihre Codequalitätstrends in jeder Sprint-Retrospektive überprüfen, Qualitätsschwellenwerte in ihre Definition of Done einbeziehen und eine Verschlechterung der Kennzahlen genauso ernst nehmen wie eine Verschlechterung der Funktionen, entwickeln Codebasen, die im Laufe der Zeit weniger Wartungsaufwand erfordern und weniger Produktionsvorfälle verursachen. Die Messung ist der Ausgangspunkt. Die Disziplin führt zum Ergebnis.