Prompts / it / Technical Debt Analyse
itExperteChatGPTClaude

Technical Debt Analyse

Identifiziert und priorisiert technische Schulden mit ROI-Bewertung für Refactoring.

432× verwendet•Kompatibel mit: ChatGPT, Claude

Der Prompt

Du bist ein Software-Architekt mit Fokus auf technische Schulden und Refactoring-Strategie.

Analysiere die technischen Schulden eines Systems:

**System:** [SYSTEMNAME]
**Code-Basis:** [SPRACHE / FRAMEWORK / ALTER]
**Team-Grösse:** [ENTWICKLER]
**Aktuelle Pain Points (was nervt das Team):** [PAIN POINTS]
**Business-Kontext:** [WARUM JETZT DARÜBER NACHDENKEN]
**Budget für Refactoring:** [ZEIT / GELD]

Liefere:

1. **Debt-Inventar**, identifiziere typische technische Schulden:
   - Veraltete Dependencies
   - Code-Duplikation
   - Fehlende Tests
   - Schlechte Abstraktionen
   - Performance-Issues
   - Security-Issues
   - Dokumentations-Defizite
   - Verwaiste Code-Teile

2. **Pro identifizierte Schuld:**
   - **Business-Impact** (hoch / mittel / niedrig)
   - **Technischer Impact** (blockt neue Features? erhöht Bug-Rate?)
   - **Refactoring-Aufwand** (Zeit-Schätzung)
   - **Risiko des Ignorierens** (was passiert, wenn wir nichts tun?)
   - **Risiko der Änderung** (was könnte beim Fixen brechen?)

3. **Priorisierung nach ROI:**
   - Quick Wins (hoher Impact, niedriger Aufwand)
   - Strategic Bets (hoher Impact, hoher Aufwand)
   - Time Bombs (Risiko steigt mit Zeit)
   - Nice-to-haves (niedriger Impact)

4. **Refactoring-Roadmap** (3-6 Monate)
   - Woche 1-4: Quick Wins
   - Monat 2-3: Strategic Refactorings (parallel zu neuen Features)
   - Monat 4+: Langfristige Modernisierung

5. **Metriken zur Erfolgsmessung:**
   - Code-Coverage
   - Build-Zeit
   - Bug-Rate
   - Feature-Velocity
   - Developer Happiness

6. **Business Case**, wie verkauft man Refactoring an das Management?

Stil: ehrlich über Schmerzen, aber konstruktiv. Keine Perfektions-Obsession.

Anzupassende Variablen

[SYSTEMNAME][CODE-BASIS][TEAM-GRÖSSE][PAIN POINTS][BUSINESS-KONTEXT][BUDGET]

Warum dieser Prompt funktioniert

Technical Debt ist der häufigste Grund für sinkende Entwicklerproduktivität, und wird meist ignoriert, weil der ROI schwer kommunizierbar ist. Dieser Prompt zwingt zur Quantifizierung und Priorisierung. Quick Wins + Time Bombs sind die zwei wichtigsten Kategorien, weil sie einfache Erfolge und kritische Risiken identifizieren.

Beispielausgabe

**Time Bomb (HÖCHSTE PRIORITÄT):** Node.js 14 End-of-Life in 4 Monaten - Business-Impact: HOCH (Security-Updates stoppen, Compliance-Risiko) - Aufwand: 3 Wochen (Dependency-Updates + Tests) - Risiko des Ignorierens: Security-Vulnerabilities ohne Patches - Empfehlung: SOFORT einplanen **Quick Win:** Tests für zentrales Payment-Modul fehlen - Business-Impact: HOCH (jede Änderung ist Roulette) - Aufwand: 1 Woche (Integration-Tests für 80% Coverage) - ROI: extrem hoch, verhindert Bugs in Kern-Funktionalität **Business Case für Management:** "Wir investieren 4 Wochen Refactoring, um: 1) Node 14 EOL Risiko zu eliminieren (Compliance) 2) Bug-Rate um geschätzt 30% zu senken (basierend auf Coverage-Lücken) 3) Feature-Velocity um 15% zu erhöhen (weniger Regression-Fixes)" [...]

Häufige Fragen

Wie viel Zeit für Refactoring einplanen?

Faustregel: 15-20% der Entwicklungszeit für Refactoring und technische Schulden. Weniger führt zu Stagnation, mehr wird vom Business kaum akzeptiert.

Wann ist Refactoring sinnlos?

Bei Code, der kurz vor Deprekation steht. Refactoring ist eine Investition in die Zukunft, wenn es keine Zukunft gibt, investiert man lieber in den Nachfolger.

Verwandte Prompts

Code-Review mit KI

Strukturiertes Code-Review mit Fokus auf Bugs, Performance, Best Practices und Security.

Bug-Analyse & Debug-Hilfe

Analysiert Bugs systematisch und schlägt konkrete Lösungsansätze vor.

API-Dokumentation Generator

Erstellt strukturierte API-Dokumentation mit Beispielen, Fehlercodes und Best Practices.