Technical Debt Management
Technical Debt Management
Technical Debt ist wie finanzielle Schulden - sie wächst mit Zinsen. Lernen Sie technische Schulden zu identifizieren, zu priorisieren und strategisch abzubauen.
Was ist Technical Debt?
┌─────────────────────────────────────────────────────────────┐ │ TECHNICAL DEBT │ ├─────────────────────────────────────────────────────────────┤ │ │ │ "Technical Debt ist die implizite Kosten der │ │ Nacharbeit, die durch schnelle aber unsaubere │ │ Lösungen entstehen." │ │ - Ward Cunningham │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ KURZFRISTIG: Schnellere Entwicklung 🚀 │ │ │ │ ┌───────────────────────────────────┐ │ │ │ │ │ "Wir fixen das später..." │ │ │ │ │ │ "Nur ein Quick Fix für Deadline" │ │ │ │ │ │ "Refactoring können wir später" │ │ │ │ │ └───────────────────────────────────┘ │ │ │ │ │ │ │ │ LANGFRISTIG: Immer langsamer 🐢 │ │ │ │ ┌───────────────────────────────────┐ │ │ │ │ │ • Bugs häufen sich │ │ │ │ │ │ • Features dauern länger │ │ │ │ │ │ • Onboarding wird schwieriger │ │ │ │ │ │ • Entwickler sind frustriert │ │ │ │ │ └───────────────────────────────────┘ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘
Arten von Technical Debt
1. BEWUSSTE SCHULDEN (Deliberate) ┌─────────────────────────────────────────────────────┐ │ "Wir wissen, dass das nicht ideal ist, aber..." │ │ │ │ • Deadline-getrieben │ │ • MVP/Prototyp wird Production │ │ • Bewusste Trade-offs │ │ │ │ → OK wenn dokumentiert und geplant │ └─────────────────────────────────────────────────────┘ 2. UNBEWUSSTE SCHULDEN (Inadvertent) ┌─────────────────────────────────────────────────────┐ │ "Wir wussten nicht, dass es besser geht..." │ │ │ │ • Mangelnde Erfahrung │ │ • Fehlende Best Practices │ │ • Veraltetes Wissen │ │ │ │ → Durch Lernen und Code Reviews reduzieren │ └─────────────────────────────────────────────────────┘ 3. BIT ROT (Environmental) ┌─────────────────────────────────────────────────────┐ │ "Das war mal state-of-the-art..." │ │ │ │ • Veraltete Dependencies │ │ • Überholte Patterns │ │ • Security Vulnerabilities │ │ │ │ → Regelmäßige Updates und Modernisierung │ └─────────────────────────────────────────────────────┘
Technical Debt Quadrant
RECKLESS PRUDENT
│
DELIBERATE "Wir haben keine │ "Wir müssen jetzt
Zeit für Design" │ shippen und später
│ refactoren"
─────────────────────┼─────────────────────
│
INADVERTENT "Was ist eigentlich │ "Jetzt wissen wir
Layered Architecture?"│ wie wir es hätten
│ machen sollen"
│
PRUDENT (Umsichtig): Bewusste, kalkulierte Entscheidungen
RECKLESS (Rücksichtslos): Ignoranz oder Gleichgültigkeit
DELIBERATE (Absichtlich): Wissentlich Schulden aufnehmen
INADVERTENT (Versehentlich): Schulden aus Unwissenheit
Symptome erkennen
CODE SYMPTOMS ┌────────────────────────────────────────────────────────────┐ │ • "God Classes" - Klassen mit zu vielen Verantwortungen │ │ • Copy-Paste Code (Duplikation) │ │ • Lange Methoden (> 50 Zeilen) │ │ • Tiefe Verschachtelungen │ │ • Fehlende oder veraltete Tests │ │ • Magic Numbers und Hardcoded Strings │ │ • Auskommentierter Code │ │ • Übermäßig komplexe Conditional Logic │ └────────────────────────────────────────────────────────────┘ PROCESS SYMPTOMS ┌────────────────────────────────────────────────────────────┐ │ • Features dauern immer länger │ │ • Bugs in "unveränderten" Bereichen │ │ • Angst vor Refactoring │ │ • "Das kann nur Person X anfassen" │ │ • Neue Entwickler brauchen Monate zum Onboarding │ │ • Häufige Production Incidents │ │ • Workarounds statt echten Fixes │ └────────────────────────────────────────────────────────────┘ METRIKEN ┌────────────────────────────────────────────────────────────┐ │ • Code Coverage sinkt │ │ • Cyclomatic Complexity steigt │ │ • Deployment Frequency sinkt │ │ • Lead Time steigt │ │ • Bug Escape Rate steigt │ │ • Technische Story Points > Feature Story Points │ └────────────────────────────────────────────────────────────┘
Debt inventarisieren
// Technical Debt Register (Beispiel) | ID | Bereich | Beschreibung | Impact | Effort | Priority | |-----|--------------|-------------------------------|--------|--------|----------| | TD1 | Auth Module | Legacy Session ohne JWT | High | Medium | P1 | | TD2 | API | Keine Versionierung | High | High | P1 | | TD3 | Database | Fehlende Indizes | Medium | Low | P2 | | TD4 | Frontend | jQuery statt React | Medium | High | P3 | | TD5 | Tests | 20% Coverage im Payment Code | High | Medium | P1 | | TD6 | DevOps | Manual Deployments | Medium | Medium | P2 | | TD7 | Code | Duplikation in Helpers | Low | Low | P3 | PRIORISIERUNG: P1 = Blockiert wichtige Features oder verursacht Incidents P2 = Verlangsamt Entwicklung spürbar P3 = Ärgerlich aber nicht dringend
// Im Code dokumentieren (Debt Tags)
// TODO: Refactor - Legacy code, see TD-123
// FIXME: Performance issue with large datasets
// HACK: Workaround for third-party bug, remove when updated
// DEBT: This violates SRP, split into separate services
// In Jira/Tickets mit Label: technical-debt
// Epics für größere Debt-Bereiche
// SonarQube Tags
@SuppressWarnings("squid:S1192") // Duplicated strings - TD-456
Strategien zum Abbau
1. DEDICATED TIME ┌─────────────────────────────────────────────────────┐ │ 20% der Sprint-Kapazität für Tech Debt reservieren │ │ │ │ Sprint: 10 Story Points │ │ → 8 SP Features, 2 SP Tech Debt │ │ │ │ ✅ Kontinuierlicher Abbau │ │ ❌ Kann bei Deadline-Druck geopfert werden │ └─────────────────────────────────────────────────────┘ 2. TECH DEBT SPRINTS ┌─────────────────────────────────────────────────────┐ │ Alle X Sprints ein reiner Tech-Debt Sprint │ │ │ │ Beispiel: Alle 4 Sprints │ │ → 3 Feature Sprints, 1 Tech Debt Sprint │ │ │ │ ✅ Fokussierte Arbeit │ │ ❌ Lange Pausen zwischen Abbau-Phasen │ └─────────────────────────────────────────────────────┘ 3. BOY SCOUT RULE ┌─────────────────────────────────────────────────────┐ │ "Leave the code cleaner than you found it" │ │ │ │ Bei jedem Feature/Bug: │ │ → Kleine Verbesserungen im betroffenen Bereich │ │ │ │ ✅ Keine separate Planung nötig │ │ ❌ Nur kleine, lokale Verbesserungen │ └─────────────────────────────────────────────────────┘ 4. STRANGLER FIG PATTERN ┌─────────────────────────────────────────────────────┐ │ Legacy-System schrittweise ersetzen │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Legacy │ → │ Legacy │ → │ New │ │ │ │ 100% │ │ + New │ │ 100% │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ ✅ Niedrigeres Risiko │ │ ❌ Längere Koexistenz-Phase │ └─────────────────────────────────────────────────────┘
Mit dem Business kommunizieren
// Technical Debt in Business-Sprache
NICHT SAGEN:
"Wir müssen refactoren"
"Der Code ist schlecht"
"Das ist technisch nicht sauber"
STATTDESSEN:
"Dieses Feature würde 2 Wochen statt 2 Tagen dauern wegen..."
"Wir haben erhöhtes Bug-Risiko in diesem Bereich weil..."
"Die Wartungskosten für X betragen Y Stunden pro Monat"
// Visualisierung für Stakeholder
VELOCITY TREND
Sprint 1: ████████████ 12 SP
Sprint 2: ██████████ 10 SP
Sprint 3: ████████ 8 SP
Sprint 4: ██████ 6 SP
↓
"Unsere Geschwindigkeit sinkt wegen wachsender Tech Debt"
ROI BERECHNUNG
Tech Debt Fix: 3 Wochen Aufwand
Einsparung: 2 Stunden/Woche Maintenance
→ Break-even nach 7.5 Wochen
→ Danach: 2 Stunden/Woche gespart
Tools zur Messung
STATIC ANALYSIS
SonarQube
• Debt-Ratio berechnen
• Hotspots identifizieren
• Trends über Zeit
# SonarQube Metriken
sonar.qualitygate.wait=true
sonar.issues.defaultSeverity=BLOCKER
CodeClimate
• Maintainability Rating
• Technical Debt Estimate
• Test Coverage
# CodeClimate Config
version: "2"
plugins:
duplication:
enabled: true
config:
threshold: 100
complexity:
enabled: true
config:
threshold: 10
DEPENDENCY ANALYSIS
npm audit # JavaScript
composer audit # PHP
safety check # Python
bundle audit # Ruby
Dependabot / Renovate # Automatische Updates
Debt vorbeugen
PRÄVENTIVE MASSNAHMEN 1. CODE REVIEWS • PR-Größe limitieren (< 400 Zeilen) • Checklisten für Qualitätsstandards • Pair Programming für komplexe Features 2. TESTING • Test Coverage Minimum (z.B. 80%) • Tests vor Merge erforderlich • Integration Tests für kritische Pfade 3. ARCHITECTURE DECISION RECORDS (ADRs) • Entscheidungen dokumentieren • Trade-offs festhalten • Bekannte Schulden explizit machen 4. CODING STANDARDS • Linter und Formatter automatisieren • Style Guide im Team etablieren • Onboarding-Dokumentation pflegen 5. CONTINUOUS INTEGRATION • Automated Quality Gates • Keine Merges wenn Tests fehlschlagen • Complexity-Checks in Pipeline
💡 Best Practices:
1. Technical Debt explizit tracken (Register)
2. Regelmäßige Zeit für Abbau einplanen
3. Business-Sprache für Kommunikation nutzen
4. Boy Scout Rule im Alltag anwenden
5. Neue Schulden bewusst und dokumentiert aufnehmen
2. Regelmäßige Zeit für Abbau einplanen
3. Business-Sprache für Kommunikation nutzen
4. Boy Scout Rule im Alltag anwenden
5. Neue Schulden bewusst und dokumentiert aufnehmen