Technische Schulden und Code Smells

Kurz: Technische Schulden sind Abkürzungen im Code, die jetzt Zeit sparen, später aber „Zinsen“ in Form von Mehraufwand kosten; Code Smells sind Warnzeichen dafür.

Genauer: Der Begriff stammt von Ward Cunningham. Wer aus Zeitdruck eine unsaubere Lösung wählt, nimmt einen Kredit auf: Es geht schneller voran, aber jede weitere Änderung wird mühsamer, bis man die Schuld zurückzahlt (durch Aufräumen). Nicht jede Schuld ist schlecht, solange man sie bewusst eingeht und eine Rückzahlung plant.

Im Detail

Arten

• Bewusst und klug: „Wir liefern jetzt mit einer einfachen Lösung und bauen sie nach dem Start aus.“
• Unbewusst: Man erkennt erst später, dass der Entwurf schlecht war.
• Nachlässig: „Für Tests haben wir keine Zeit.“ Neben Code zählen auch fehlende Tests, veraltete Bibliotheken, fehlende Dokumentation und manuelle Abläufe dazu.

Typische Code Smells

• Lange Methode / große Klasse: macht zu viel.
• Duplizierter Code: dieselbe Logik an mehreren Stellen.
• Magische Zahlen: unerklärte Konstanten wie if (status == 7).
• Lange Parameterlisten.
• Feature Envy: eine Methode interessiert sich mehr für fremde Daten als für die eigene Klasse.
• Tote Teile: ungenutzter Code und alte Kommentare.
• Verschachtelte Bedingungen über viele Ebenen.

Umgang damit

Schulden sichtbar machen (Liste im Ticketsystem, Markierung TODO mit Ticketnummer). Regelmäßig einen Teil der Zeit für Aufräumen einplanen, statt auf einen großen Umbau zu hoffen. Nach der Pfadfinderregel hinterlässt man jeden Code etwas sauberer, als man ihn vorgefunden hat. Werkzeuge wie statische Analyse (SonarQube, ESLint) zeigen Smells und Komplexität an.

Vorsicht

Nicht alles Unschöne ist Schuld, die sich lohnt zu tilgen: Code, der stabil läuft und nie angefasst wird, kostet kaum Zinsen. Umgekehrt sollte man Schulden in Bereichen, die oft geändert werden, zuerst abbauen.

Siehe auch: Refactoring, Clean Code, Spaghetti-Code, Code-Review