Wikipedia liefert eine prägnante Erklärung für technische Schulden:
Technische Schulden (auch bekannt als Design-Schulden[1] oder Code-Schulden) sind „ein Konzept der Programmierung, das den zusätzlichen Entwicklungsaufwand beschreibt, der entsteht, wenn kurzfristig leicht zu implementierender Code verwendet wird, anstatt die insgesamt beste Lösung umzusetzen“.[2]Technische Schulden lassen sich mit finanziellen Schulden.[3] Werden technische Schulden nicht abgebaut, können sich „Zinsen“ ansammeln, wodurch spätere Änderungen schwieriger umzusetzen sind. Unbehandelte technische Schulden erhöhen die Softwareentropie. Technische Schulden sind nicht zwangsläufig etwas Schlechtes. Manchmal – etwa bei einem Proof of Concept – sind sie sogar notwendig, um ein Projekt voranzubringen. Andererseits weisen einige Experten darauf hin, dass die Metapher der „technischen Schulden“ die tatsächlichen Auswirkungen verharmlosen kann. Dadurch erhalten die notwendigen Korrekturarbeiten häufig nicht die erforderliche Priorität.[4][5]
Theoretisch ist der Umgang mit technischen Schulden ein vielversprechender Ansatz zur Verbesserung der Softwarequalität. In der Praxis ist diese Kennzahl jedoch nicht einfach anzuwenden. Die große Herausforderung lautet nämlich: Wie lassen sich technische Schulden bewerten?.
Viele Tools bieten eigene Algorithmen zur Bewertung an, die auf mehreren Faktoren beruhen:
- Von statischen Analysetools erkannte Probleme.
- Codeabdeckung.
- Code-Duplizierung.
- Dokumentation.
- Mangelhaftes Design.
Unabhängig davon, welches Tool oder welche Methode zur Bewertung technischer Schulden verwendet wird, muss die Berechnung flexibel und leicht anpassbar sein. Jede Organisation sollte den Algorithmus an ihren eigenen Kontext anpassen können.
Ein agiler Algorithmus
Es gibt zwei Möglichkeiten, die Berechnung technischer Schulden flexibel zu gestalten:
- Einen konkreten Algorithmus definieren und dessen Parameter an den Kontext des Entwicklungsteams anpassbar machen.
- Keinen festen Algorithmus vorgeben, sondern den Benutzern ermöglichen, die Berechnungsformeln selbst anzupassen.
Bei CppDepend, haben wir den Algorithmus bewusst sehr flexibel gestaltet. Er kann für jede Regel abhängig vom jeweiligen Projektkontext angepasst werden.
Hier ist beispielsweise eine Formel für die technischen Schulden, die durch zu große Typen entstehen:
Und hier eine weitere Formel für ein Cppcheck-Problem:
Auf diese Weise kann jedes Team seine Schuldenberechnung an den Projektkontext anpassen und Schätzfehler reduzieren.
Vergleich mit einer Baseline
Technische Schulden präzise zu bewerten ist schwierig. Jeder Algorithmus bringt einen gewissen Schätzfehler mit sich, und eine sorgfältige Kalibrierung kann zeitaufwendig sein, weil die Berechnung von vielen Faktoren abhängt.
Der Vergleich der technischen Schulden zweier Versionen einer Codebasis kann jedoch einen guten Hinweis darauf geben, wie sich deren Codequalität entwickelt.
Der Vergleich der Schuldenmetriken zweier Versionen hilft, Schätzfehler zu minimieren und liefert eine aussagekräftigere Messung der Veränderung.
Fazit
Technische Schulden sind eine leistungsfähige Kennzahl zur Überwachung der Qualität einer Codebasis. Benutzer benötigen jedoch eine einfache Möglichkeit, die Berechnung zu kalibrieren und Schätzfehler zu reduzieren. In der Praxis ist es häufig nützlicher, die Entwicklung der technischen Schulden im Zeitverlauf zu verfolgen, als sich auf ihren absoluten Wert zu konzentrieren.