Technische Schulden sichtbar und messbar machen

„Der Code ist ein Albtraum." Das höre ich in fast jedem Erstgespräch. Es ist ein Gefühl, kein Argument. Und Gefühle bekommen kein Budget. Wenn Sie technische Schulden abbauen wollen, brauchen Sie zuerst etwas anderes: Zahlen. Nicht, weil Zahlen die Wahrheit sind, sondern weil sie eine Diskussion ermöglichen, die über „das müsste man mal aufräumen" hinausgeht.

Wichtig vorweg: Ein System, das seit acht oder zwölf Jahren im Produktivbetrieb läuft, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert – dass jemand die Domäne verstanden hat. Das Problem sitzt fast nie in der Logik selbst, sondern im Code drumherum: in der Struktur, den Abhängigkeiten, der fehlenden Testbarkeit. Genau das lässt sich messen.

Warum Sie technische Schulden messen müssen, bevor Sie sie abbauen

Technische Schulden messen bedeutet, ein diffuses Unbehagen in überprüfbare Kennzahlen zu übersetzen. Ohne Baseline können Sie weder priorisieren noch Fortschritt zeigen. Sie wissen nicht, ob eine Änderung das System besser oder schlechter gemacht hat.

Der praktische Nutzen: Sie können einem Entscheider, der kein PHP liest, erklären, warum ein bestimmtes Modul jeden neuen Feature-Wunsch verdreifacht. Und Sie schützen sich selbst vor der teuersten und riskantesten aller Optionen – dem kompletten Neuschreiben. Eine Neuentwicklung wirft nicht nur den schlechten Code weg, sondern auch die über Jahre gehärtete Fachlogik, jeden stillen Bugfix und jeden Sonderfall, an den sich niemand mehr erinnert.

Welche Metriken zeigen wirklich technische Schulden?

Statische Analyse ist der günstigste erste Schritt. Sie liefert in einer halben Stunde ein belastbares Bild, ohne dass Sie eine Zeile Code ändern. Für PHP-Projekte sind das die Werkzeuge, mit denen ich immer beginne:

• PHPStan oder Psalm auf einem niedrigen Level starten, dann Level für Level erhöhen. Die Anzahl der Fehler pro Level ist eine harte Zahl. Ein Projekt, das erst auf Level 0 durchläuft und dort schon tausende Fehler produziert, sagt mehr als jedes Bauchgefühl.
• Zyklomatische Komplexität pro Methode, etwa via PHPMetrics oder PHP Mess Detector. Methoden mit einem Wert über 10 sind schwer testbar, Werte über 20 sind faktisch nicht mehr sicher änderbar.
• Kopplung und Kohäsion. PHPMetrics zeichnet, welche Klassen von wie vielen anderen abhängen. Die Klassen mit der höchsten eingehenden Kopplung sind Ihre Risikozonen – jede Änderung dort strahlt aus.
• Testabdeckung über die Coverage von PHPUnit. Nicht als Prozentfetisch, sondern um die blinden Flecken zu finden: Welche kritischen Pfade haben null Tests?
• Deprecations und Sicherheit. composer audit zeigt verwundbare Pakete, composer outdated den Rückstand. Eine Anwendung auf PHP 7.4 oder Symfony 4 hat eine tickende Uhr im Namen.

Die aussagekräftigste Metrik ist nicht rein technisch

Zahlen aus statischer Analyse zeigen Ihnen den Zustand des Codes. Sie zeigen Ihnen nicht, wo es wehtut. Dafür brauchen Sie den Faktor, den kein Linter kennt: die Änderungshäufigkeit.

Ein Modul kann grausam komplex sein – wenn es niemand mehr anfasst, ist es kein akutes Problem. Kritisch wird es dort, wo hohe Komplexität auf hohe Änderungsfrequenz trifft. Diese Kombination heißt oft „Hotspot".

Eine Datei, die im letzten Jahr 60-mal geändert wurde und gleichzeitig eine hohe Komplexität hat, kostet Sie bei jeder Berührung Geld. Genau dort lohnt Refactoring zuerst.

Sie holen sich diese Daten direkt aus Git. Der folgende Einzeiler zählt, wie oft jede Datei geändert wurde:

git log --pretty=format: --name-only --since="12 months ago" | sort | uniq -c | sort -rg | head -30

Legen Sie diese Liste neben Ihren Komplexitäts-Report. Die Dateien, die in beiden Listen oben stehen, sind Ihre Prioritätenliste – nicht die theoretisch schlimmsten, sondern die praktisch teuersten.

Wie machen Sie die Schulden für Nicht-Entwickler sichtbar?

Ein PHPStan-Report überzeugt keinen Geschäftsführer. Übersetzen Sie technische Kennzahlen in Sprache, die Entscheidungen auslöst:

• Zeit statt Fehleranzahl. Nicht „4.000 PHPStan-Fehler", sondern „ein neues Feld in diesem Formular kostet drei Tage statt drei Stunden, weil die Logik an elf Stellen dupliziert ist".
• Risiko statt Kopplung. Nicht „Coupling von 47", sondern „Änderungen an der Rechnungslogik können ungetestet den Versand beeinflussen".
• Trend statt Momentaufnahme. Lassen Sie die statische Analyse in der CI-Pipeline mitlaufen und speichern Sie die Werte. Eine Kurve, die zeigt, ob die Schulden wachsen oder schrumpfen, ist überzeugender als jeder Einzelwert.

Ein einfaches Ampelsystem pro Modul – grün, gelb, rot, gestützt auf die drei Achsen Komplexität, Testabdeckung und Änderungshäufigkeit – verstehen auch Menschen, die nie eine IDE geöffnet haben.

Der pragmatische Ablauf in fünf Schritten

1. Baseline ziehen. PHPStan, PHPMetrics und composer audit einmal laufen lassen und die Ergebnisse festhalten. Das ist Ihr Nullpunkt.
2. Hotspots finden. Komplexitäts-Report mit der Git-Änderungshäufigkeit kreuzen.
3. Übersetzen. Die drei bis fünf teuersten Hotspots in Geschäftssprache beschreiben.
4. Messung automatisieren. Analyse in die CI-Pipeline hängen, damit neue Schulden sofort sichtbar werden und nicht erst in zwei Jahren.
5. Gezielt abtragen. Zuerst Tests um den Hotspot herum schreiben, dann refactoren. Nie ohne Netz an der teuersten Stelle arbeiten.

Ein ehrlicher Praxis-Hinweis zum Schluss

Messen Sie nicht alles auf einmal. Eine vollständige, wochenlange Vermessung führt oft zu einer Excel-Tabelle, die niemand mehr anfasst. Beginnen Sie mit einer halben Stunde statischer Analyse und dem Git-Einzeiler von oben. Das reicht, um die drei schlimmsten Stellen zu benennen – und der Rest ergibt sich aus der Arbeit an ihnen.

Und behalten Sie im Kopf: Die Zahlen bewerten den Code, nicht das System. Dass Ihre Anwendung seit Jahren Umsatz macht, ist der eigentliche Wert. Technische Schulden messen heißt, diesen Wert zu schützen, statt ihn im Namen der Sauberkeit wegzuwerfen.

Wenn Sie bei genau dieser ersten Vermessung und Priorisierung einen erfahrenen Blick von außen brauchen, ist das die Art von Arbeit, mit der ich Legacy-PHP-Teams bei LegacyWerk unterstütze.