Dein Debugging-Playbook

🔄 Quick Recall: In den letzten 7 Lektionen hast du das Debugging-Mindset, Fehlermeldungen lesen, den 5-Schritte-Prozess, Debugging-Werkzeuge, Bug-Muster, Produktions-Debugging und Ursachenanalyse gelernt. Jetzt kombinierst du alles in deinem persoenlichen Debugging-Playbook.

Ein Debugging-Playbook ist dein systematischer Ansatz fuer jeden Bug — ein Entscheidungsbaum aus allem, was du gelernt hast. Statt jedes Mal bei Null anzufangen, folgst du einem bewaehrten Prozess, der mit jedem Bug schneller wird.

Dein komplettes Debugging-Playbook

Phase 1: Triage (2 Minuten)

Bevor du loslegst, die Situation einschaetzen:

Frage	Aktion
Ist Produktion JETZT betroffen?	Ja → Symptom-Fix zuerst, Ursache spaeter
Kann ich es reproduzieren?	Nein → mehr Kontext sammeln (Nutzerumgebung, Logs, Timing)
Kenne ich dieses Muster?	Ja → direkt zum passenden Bug-Muster springen
Ist die Fehlermeldung klar?	Ja → dem Fehler direkt zur Quelle folgen

Phase 2: Untersuchen (5-30 Minuten)

Schritt	Aktion	Werkzeug
1. Fehler lesen	Typ, Beschreibung, Ort extrahieren	Fehlermeldungs-Anatomie (Lektion 2)
2. Reproduzieren	Exakte Ausloeser finden	Reproduktions-Checkliste (Lektion 3)
3. Muster abgleichen	Symptome mit bekannten Mustern vergleichen	Bug-Muster-Bibliothek (Lektion 5)
4. Isolieren	Binaere Suche zum exakten Fehlerpunkt	Binaere Suche (Lektion 3)
5. Identifizieren	Verstehen WARUM der Code scheitert	Debugger oder strategisches Logging (Lektion 4)

Phase 3: Fixen (15-60 Minuten)

Aktion	Check
Erst fehlschlagenden Test schreiben	Test schlaegt mit aktuellem Code fehl?
Ursache beheben	Zeigt die 5-Warum-Analyse hierhin?
Test ausfuehren	Test besteht mit Fix?
Alle Tests laufen lassen	Nichts anderes kaputt?
Praevention ergaenzen	Monitoring, Linting-Regel oder Dokumentation?

Bug-Muster Schnellreferenz

Symptom	Wahrscheinliches Muster	Erster Check
„Cannot read property of null/undefined"	Null-Referenz	Rueckwaerts verfolgen, wo der Wert null wurde
Index out of bounds / fehlendes Element	Off-by-One	Schleifengrenzen: `<` vs. `<=`, 0 vs. 1
Funktioniert lokal, schlaegt intermittierend in Prod fehl	Race Condition	Async-Reihenfolge pruefen, `Promise.all()`
Gibt `[object Promise]` zurueck	Fehlendes await	Async-Aufruf ohne `await` finden
`"5" + 3 = "53"`	Typ-Mismatch	Typ-Coercion pruefen, `===` nutzen
Wert hat sich „mysterioes" geaendert	State-Mutation	Pruefen ob Objekte/Arrays mutiert statt kopiert werden
Funktioniert, dann kaputt nach Deploy	Regression	`git bisect` fuer den brechenden Commit
Schlaegt nur bei bestimmter Eingabe fehl	Edge Case	Leere Strings, 0, null, Sonderzeichen testen

KI-Debugging-Prompts

Wenn du feststeckst:

„Ich debugge seit [ZEIT] und stecke fest. Bug: [BESCHREIBUNG]. Was ich probiert habe: [LISTE]. Meine Annahmen: [LISTE]. Hinterfrage meine Annahmen — welche ist am wahrscheinlichsten falsch? Schlage 3 Hypothesen vor, die ich nicht beruecksichtigt habe."

Fuer Mustererkennung:

„Mein Bug hat diese Symptome: [LISTE]. Welches Muster passt: Off-by-One, Null-Referenz, Race Condition, Async-Fehler, Typ-Mismatch, State-Mutation, Stale Closure? Erklaere warum und schlage den ersten Check vor."

Fuer Ursachenanalyse:

„Die unmittelbare Ursache ist [URSACHE]. Hilf mir bei einer 5-Warum-Analyse. Nach jedem ‘Warum’: Welche Evidenz sollte ich suchen? Stoppe bei einem Prozess- oder Design-Fix."

Fuer Fix-Review:

„Hier ist mein Bug-Fix: [DIFF]. Der Bug war: [BESCHREIBUNG]. Pruefe: (1) Adressiert er die Ursache oder nur das Symptom? (2) Koennte er etwas anderes kaputt machen? (3) Welcher Regressionstest? (4) Gibt es einen einfacheren Fix?"

Selbsteinschaetzung

Faehigkeit	Schluesselfrage
Fehlermeldungen lesen	Kann ich Typ, Ursache, Ort aus jedem Fehler extrahieren?
Systematische Reproduktion	Kann ich exakte Ausloeser fuer intermittierende Bugs finden?
Binaere Suche	Halbiere ich den Suchraum mit jedem Test?
Mustererkennung	Kann ich Symptome in unter 30 Sekunden einem Muster zuordnen?
Werkzeugwahl	Waehle ich das richtige Werkzeug fuer jede Situation?
Produktions-Debugging	Kann ich Bugs nur mit Logs und Error-Tracking diagnostizieren?
Ursachenanalyse	Behebe ich Ursachen oder nur Symptome?

Deine schwaechste Faehigkeit ist deine beste Lernchance. Konzentriere dich dort.

✅ Quick Check: Wann solltest du beim Debugging deine Annahmen hinterfragen? (Antwort: Wenn du laenger als 30 Minuten feststeckst. Die haeufigste Ursache fuer Sackgassen: Der Bug versteckt sich hinter einer Annahme, die du nicht getestet hast. Liste deine Annahmen auf — eine davon ist wahrscheinlich falsch.)

Key Takeaways

Dein Debugging-Playbook ist ein Drei-Phasen-System: Triage (2 Min. — Schwere einschaetzen, Muster pruefen), Untersuchen (5-30 Min. — Fehler lesen, reproduzieren, Muster abgleichen, isolieren, identifizieren), Fixen (15-60 Min. — fehlschlagenden Test schreiben, Ursache beheben, verifizieren, Praevention ergaenzen)
Mustererkennung ist die wirkungsvollste Debugging-Faehigkeit: Symptome bekannten Bug-Mustern zuordnen verwandelt 30-Minuten-Untersuchungen in 30-Sekunden-Diagnosen — baue deine Muster-Bibliothek auf, indem du jeden Bug benennst
Die Debugging-Meta-Faehigkeit ist zu wissen, wann man den Ansatz wechselt: nach 30+ Minuten Sackgasse dokumentieren, Annahmen hinterfragen, frische Perspektive holen und Pause machen — Ausdauer auf dem falschen Pfad ist kein produktives Debugging

Kurs abgeschlossen

Herzlichen Glueckwunsch — du hast jetzt ein komplettes Debugging-Toolkit. Vom Fehlermeldungen-Lesen bis zur Ursachenanalyse kannst du jeden Bug systematisch angehen. Der Schluessel ist Uebung: Nutze das Playbook bei jedem Bug, auch bei kleinen, bis der Prozess automatisch wird.