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 bis 5	Einfach, leicht zu testen
6 bis 10	Mäßig, überschaubar
11 bis 20	Komplexe Tests gestalten sich schwierig
21 bis 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. Untersuchungen, die in den IEEE Transactions on Software Engineering veröffentlicht wurden, ergaben, dass Funktionen mit einer zyklomatischen Komplexität über 10 deutlich höhere Fehlerraten aufweisen als einfachere Funktionen. zyklomatische Komplexitätsanalyse Bei älteren Codebasen besteht die Sorge darin, Funktionen zu finden, die im Laufe jahrelanger Wartung Entscheidungslogik angesammelt haben, ohne dass jemals jemand die Gesamtstruktur refaktorisiert hat.

NPath-Komplexität Die NP-Pfad-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 NP-Pfad-Komplexität diese: Eine Funktion mit drei aufeinanderfolgenden if-else-Blöcken hat eine zyklomatische Komplexität von 4, aber eine NP-Pfad-Komplexität von 8, da jede Bedingung unabhängig wahr oder falsch sein kann. Die NP-Pfad-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-Metriken Aus vier Zählungen im Quellcode wird eine Familie von Kennzahlen abgeleitet: 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

Wartbarkeitsindex Die Halstead-Kennzahl 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. Sie 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 bis 100	Nachhaltig (grün)
10 bis 19	Mittlerer Wartungsaufwand (gelb)
0 bis 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.

Codezeilen (LOC) und KLOC Die Größe der Codebasis wird in Zeilen oder Tausend Zeilen gemessen. Die Anzahl der Codezeilen (LOC) allein sagt nichts über die Qualität aus, liefert aber wichtige Bezugsgrößen für andere Metriken: Fehlerdichte (Bugs pro KLOC), Kommentardichte (Kommentardichte pro LOC) und Testdichte (Testzusicherungen pro LOC). 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 Die Änderungsrate des Codes im Laufe der Zeit wird als Summe der hinzugefügten, gelöschten und geänderten Zeilen pro Datei und Zeiteinheit gemessen. Eine hohe Änderungsrate 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 geänderten Dateien fünfmal mehr Fehler enthielten als Dateien mit geringer Änderungsrate. Die Beobachtung der Änderungsrate zusammen mit der Fehlerrate zeigt, ob häufige Änderungen die Qualität verbessern oder neue Probleme verursachen.

Code-Coverage-Metriken

Unit-Test-Abdeckung Die Codeabdeckung gibt den Prozentsatz der Zeilen, Verzweigungen oder Bedingungen im Quellcode an, die von Unit-Tests ausgeführt werden. Am aussagekräftigsten ist die Zweigabdeckung: Sie gibt 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 prü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

Codeabdeckung in sicherheitskritischen Anwendungen DO-178C für Luftfahrtsoftware und IEC 61508 für funktionale Sicherheit spezifizieren strengere Anforderungen an die Testabdeckung (MC/DC-Abdeckung für höchste Kritikalitätsstufen), die über die Möglichkeiten herkömmlicher Unit-Tests hinausgehen. Die Verbesserung der Codequalität in sicherheitskritischen Anwendungen erfordert Tools zur Testabdeckung, die die Bedingungs-/Entscheidungsabdeckung verfolgen und die von den Zertifizierungsbehörden geforderten formalen Nachweise erbringen können.

Testdichte Die Testabdeckung wird ergänzt, indem die Anzahl der Testzusicherungen im Verhältnis zur Größe des Produktionscodes gemessen wird. 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

Fehlerdichte Die Fehlerdichte (auch Fehlerdichte 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.

Code-Geruchsdichte Zählt das Vorhandensein von Anti-Patterns, doppeltem Code, übermäßig langen Funktionen, übermäßiger Klassenkopplung, Feature-Envy und God-Objekten pro KLOC. Code-Smells verursachen 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.

Einhaltung der Namenskonvention Misst den Prozentsatz der Bezeichner (Variablen, Funktionen, Klassen), die den Namenskonventionen des Projekts entsprechen. Automatisierte Tools können die Einhaltung dieser Konventionen 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.

Code-Duplikationsrate Misst den Anteil des Quellcodes, der an mehreren Stellen dupliziert ist. Duplizierungen über 5 % werden üblicherweise als Fehler markiert. Doppelt vorhandener 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. Zudem verschleiert die Duplikation die tatsächliche Größe des Quellcodes: Ein System mit scheinbar 100,000 Zeilen kann 40,000 Zeilen einzigartige Logik und 60,000 Zeilen Kopien enthalten.

Sicherheits- und technische Schuldenkennzahlen

Technische Verschuldungsquote SonarQube definiert die technische Verschuldung als das Verhältnis der geschätzten Sanierungskosten zu den geschätzten Entwicklungskosten der Codebasis. Eine technische Verschuldung unter 5 % gilt als saubere Codebasis; über 20 % deutet sie auf erhebliche Schulden hin, die die zukünftige Entwicklung deutlich verlangsamen werden.

Dichte der Sicherheits-Hotspots Zählt die Anzahl der Sicherheitslücken, 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.

Schwachstellendichte Zählt bestätigte Sicherheitslücken pro KLOC, 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: Ermittlung einer Ausgangslage. Führen Sie vor jeglichen Änderungen eine vollständige statische Codeanalyse durch. Notieren Sie die aktuellen Werte für die zyklomatische Komplexitätsverteilung, den Wartbarkeitsindex pro Datei, die Fehlerdichte, die Codeabdeckung und die Duplikationsrate. Diese Basislinie dient als Ausgangspunkt für alle zukünftigen Messungen. Ohne eine solche Basislinie lässt sich nicht feststellen, ob Änderungen die Qualität verbessern oder verschlechtern.

Phase 2: Schwellenwerte definieren. Legen Sie für jede Kennzahl akzeptable Schwellenwerte fest, die dem jeweiligen Kontext angemessen sind. 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 analysieren, nicht Momentaufnahmen. Eine einzelne Metrikmessung ist informativ; ein Trend ermöglicht 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. Überprüfen 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 von untersucht Auswirkungsanalyse für die Bewertung von UnternehmenscodeFür eine genaue Due-Diligence-Prüfung ist es unerlässlich zu verstehen, wie die einzelnen Komponenten in Bezug auf Qualitätskennzahlen abschneiden und wie sie voneinander abhängen: Ein isoliertes Modul von geringer Qualität mag ü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.