Jeder Entwickler wünscht sich sauberen Code, der leicht zu lesen und zu warten ist und möglichst wenige Probleme und Fehler enthält. Eine Patentlösung dafür gibt es jedoch nicht: Jedes Unternehmen hat eigene Best Practices und Coding-Regeln und versucht, einen Prozess zu definieren, mit dem der Code sauber gehalten wird.
Die Codequalität eines Projekts zu messen, ist keine einfache Aufgabe. Viele Tools verwenden eigene Algorithmen zur Bewertung, die auf zahlreichen Faktoren beruhen:
- Von statischen Analysetools erkannte Probleme.
- Codeabdeckung.
- Codeduplizierung.
- Dokumentation.
- Mängel im Design.
Es gibt eine Metrik, die eine Schätzung und damit einen ungefähren Gesamtüberblick über die Qualität unserer Codebasis liefert: die technische Schuld.
Wikipedia gibt eine kurze Erklärung der technischen Schuld:
Technische Schuld (auch Design- oder Codeschuld genannt) ist ein Konzept aus der Programmierung, das den zusätzlichen Entwicklungsaufwand beschreibt, der entsteht, wenn kurzfristig leicht umsetzbarer Code verwendet wird, anstatt die insgesamt beste Lösung anzuwenden. Technische Schuld lässt sich mit finanziellen Schulden vergleichen. Wird sie nicht zurückgezahlt, können sich gewissermaßen „Zinsen“ ansammeln, wodurch spätere Änderungen schwieriger werden. Nicht behobene technische Schulden erhöhen die Softwareentropie. Technische Schuld ist nicht zwangsläufig schlecht; manchmal ist sie etwa für einen Proof of Concept notwendig, um ein Projekt voranzubringen. Einige Experten kritisieren jedoch, dass die Metapher der technischen Schuld die Auswirkungen verharmlosen kann und notwendige Korrekturarbeiten dadurch nicht ausreichend priorisiert werden.
Theoretisch ist der Abbau technischer Schulden ein vielversprechender Weg, die Softwarequalität zu verbessern. In der Praxis ist dies jedoch nicht einfach umzusetzen. Die größte Herausforderung besteht darin, technische Schulden zu bewerten.
Unabhängig davon, welches Tool oder welche Methode zur Bewertung verwendet wird, muss sie flexibel und leicht anpassbar sein. Ein Unternehmen sollte den Algorithmus an seinen jeweiligen Kontext anpassen können. So kann ein Team beispielsweise Methoden mit mehr als 50 Codezeilen tolerieren, während ein anderes 30 Zeilen als Obergrenze festlegt.
Ein agiler Algorithmus als Lösung
Es gibt zwei Möglichkeiten, die Berechnung technischer Schulden flexibel zu gestalten:
- Einen konkreten Algorithmus definieren und ermöglichen, seine Parameter an den Kontext des Entwicklungsteams anzupassen.
- Keinen festen Algorithmus vorgeben und dem Benutzer ermöglichen, die Berechnungsformeln selbst anzupassen.
Mit CppDepend haben wir uns für einen flexiblen Algorithmus entschieden, der für jede Regel an den jeweiligen Projektkontext angepasst werden kann.
Hier ist beispielsweise eine Formel für die Schuld, die durch übermäßig große Typen entsteht:
Und hier eine weitere Formel für ein Cppcheck-Problem:
Auf diese Weise kann jedes Team die Schuldenberechnung an den Projektkontext anpassen und so Schätzfehler reduzieren.
Vergleich mit einer Baseline
Technische Schulden zu bewerten ist schwierig: Jeder Algorithmus bringt Schätzfehler mit sich, und seine Kalibrierung kann zeitaufwendig sein, da das Ergebnis von vielen Faktoren abhängt.
Vergleichen wir jedoch die technische Schuld zweier Versionen einer Codebasis, erhalten wir einen guten Eindruck davon, wie sich ihre Codequalität entwickelt.
Die Differenz der Schuldenmetriken zweier Versionen verringert den Einfluss von Schätzfehlern und liefert eine aussagekräftigere Kennzahl.
Qualitätsentwicklung mithilfe von Trends verfolgen
Konzepte wie technische Schuld sind sehr hilfreich. Besonders anschaulich wird die Entwicklung jedoch durch Visualisierungen.
Sie können beispielsweise die durchschnittliche zyklomatische Komplexität und die Codezeilen pro Methode betrachten. Im Allgemeinen sollten diese Werte in einer Codebasis relativ stabil und niedrig bleiben. Mit einem Trenddiagramm lässt sich das überprüfen und kontinuierlich beobachten.
Bleibt die Trendlinie weitgehend flach und zeigt nur gelegentliche kleine Ausschläge nach oben oder unten? Oder steigt sie langsam, aber stetig an? Solche Trends zu beobachten hilft, Probleme wesentlich früher zu erkennen. Wenn ich eine Codebasis mit extrem komplexen Methoden sehe, ist klar, dass diese Komplexität nicht an einem Nachmittag entstanden ist. Sie ist das Ergebnis jahrelanger, unbemerkter schleichender Verschlechterung.
Fazit
Die Metrik der technischen Schuld ist ein leistungsfähiges Mittel, um die Qualität einer Codebasis zu überwachen. Benutzer benötigen jedoch eine einfache Möglichkeit zur Kalibrierung, um Schätzfehler zu reduzieren. Außerdem ist es sinnvoller, die Entwicklung der technischen Schuld zu betrachten als ausschließlich ihren absoluten Wert.