Debugging-Werkzeuge richtig einsetzen

🔄 Quick Recall: In der vorherigen Lektion hast du den 5-Schritte-Debugging-Prozess vertieft: reproduzieren, isolieren (binaere Suche!), identifizieren (Hypothesen testen), beheben und verifizieren. Jetzt bekommst du die konkreten Werkzeuge an die Hand, die jeden Schritt effizienter machen.

Debugging-Werkzeuge lassen dich den Zustand deines Programms waehrend der Ausfuehrung beobachten — Variablenwerte, Aufrufstapel, Netzwerkanfragen, DOM-Aenderungen. Das richtige Werkzeug fuer jede Situation zu waehlen, macht den Unterschied zwischen Minuten und Stunden.

Werkzeug 1: Print/Log-Debugging

Die einfachste und universellste Debugging-Technik — und die am meisten unterschaetzte.

Strategisches Print-Debugging (nicht wahllos):

# SCHLECHT: Wahllose Prints, die dir nichts sagen
print(data)
print("hier")
print(result)

# GUT: Beschriftete Prints mit Kontext
print(f"[verarbeite_daten] Input: {type(data)} len={len(data)}")
print(f"[verarbeite_daten] Nach Filter: {len(gefiltert)} Eintraege")
print(f"[verarbeite_daten] Ergebnis: {result} (erwartet: positiv)")

Drei Regeln fuer gutes Print-Debugging:

Beschrifte jeden Print — [Funktionsname] als Prefix, damit du in der Ausgabe weisst, woher jede Zeile kommt
Zeige den Kontext — Nicht nur den Wert, sondern auch Typ, Laenge oder erwarteten Wert
Raeume danach auf — Print-Statements im Code lassen ist wie Geruest am fertigen Haus

KI-Prompt fuer Print-Debugging:

„Ich debugge diese Funktion: [CODE]. Fuege strategische Print-Statements ein, die mir zeigen: (1) Welche Daten in die Funktion kommen, (2) wie sie sich bei jedem Schritt aendern, (3) welche Entscheidungspfade genommen werden, (4) was am Ende herauskommt. Beschrifte jeden Print eindeutig."

✅ Quick Check: Warum ist „print(data)" schlechtes Debugging? (Antwort: Ohne Beschriftung weisst du bei mehreren Prints nicht, welche Ausgabe zu welchem Print gehoert. Ohne Kontext (Typ, Laenge, erwarteter Wert) siehst du den Wert, verstehst aber nicht, ob er korrekt ist. Strategisches Print-Debugging heisst: Jeder Print beantwortet eine spezifische Frage.)

Werkzeug 2: IDE-Debugger (Breakpoints)

Feature	Was es tut	Wann einsetzen
Breakpoint	Pausiert die Ausfuehrung an einer Zeile	Zustand an einem bestimmten Punkt inspizieren
Bedingter Breakpoint	Pausiert nur wenn Bedingung erfuellt	„Stoppe wenn i > 100 und wert < 0"
Step Over	Aktuelle Zeile ausfuehren, zur naechsten	Zeile fuer Zeile der Ausfuehrung folgen
Step Into	In einen Funktionsaufruf springen	Tiefer in eine Funktion eintauchen
Step Out	Bis zum Rueckgabewert der Funktion laufen	Fertig mit der Inspektion, weiter
Watch Expression	Einen Wert kontinuierlich ueberwachen	Berechnete Werte verfolgen

Wann vom Print zum Debugger wechseln:

Mehr als 5 Print-Statements noetig → Debugger
Mehrere Variablen in einer Schleife verfolgen → Debugger
Du willst den Code nicht veraendern (Produktionscode) → Debugger
Komplexe Objekte inspizieren → Debugger (besser als Print fuer verschachtelte Strukturen)

KI-Prompt fuer Breakpoint-Strategie:

„Ich debugge [BUG-BESCHREIBUNG]. Wo sollte ich Breakpoints setzen und welche Bedingungen verwenden? Mein Code: [CODE]."

Werkzeug 3: Browser DevTools

Fuer Web-Entwicklung sind die DevTools dein wichtigstes Werkzeug:

Tab	Debuggt was	Wichtigste Features
Console	JavaScript-Fehler, Log-Ausgabe	Fehler, Warnungen, interaktive JS-Ausfuehrung
Elements	HTML/CSS-Zustand, Event Listener	DOM inspizieren, Styles live aendern
Sources	JavaScript-Ausfuehrung	Breakpoints, Code schrittweise durchgehen
Network	API-Aufrufe, Ressourcen-Loading	Request/Response-Daten, Timing, Fehler
Performance	Laufzeit-Performance	Frame Rate, lange Tasks, Rendering
Application	Speicher, Cookies	localStorage, sessionStorage, Cookies

Debugging-Workflow nach Symptom:

Symptom	Starte mit	Dann pruefe
Button funktioniert nicht	Console (Fehler)	Elements (Event Listener) → Sources
Seite laedt langsam	Network (Wasserfall)	Performance (lange Tasks)
Falsche Daten angezeigt	Network (API-Response)	Sources (Datenverarbeitung)
Layout kaputt	Elements (berechnete Styles)	Console (CSS-Warnungen)
State aktualisiert nicht	Sources (Breakpoints im State)	Application (Storage)

Werkzeug 4: KI als Debugging-Partner

KI funktioniert hervorragend als „Rubber Duck" — du erklaerst das Problem, und allein durch das Strukturieren deiner Gedanken findest du oft die Loesung.

KI-Prompt fuer Rubber-Duck-Debugging:

„Ich stecke bei einem Bug fest. Lass mich erklaeren, was passiert, und hilf mir, es durchzudenken: (1) Erwartetes Verhalten: [WAS PASSIEREN SOLLTE]. (2) Tatsaechliches Verhalten: [WAS STATTDESSEN PASSIERT]. (3) Was ich bisher geprueft habe: [LISTE]. (4) Meine aktuelle Hypothese: [WAS ICH GLAUBE, WAS FALSCH IST]. Finde Schwachstellen in meiner Hypothese. Was uebersehe ich? Was sollte ich noch pruefen?"

✅ Quick Check: Du setzt einen Breakpoint in einer JavaScript-Async-Funktion. Der Breakpoint wird nie ausgeloest, obwohl die Funktion definitiv aufgerufen wird. Warum? (Antwort: Haeufige Ursachen: (1) Die Source Map stimmt nicht mit dem laufenden Code ueberein — Projekt neu bauen. (2) Die Funktion wirft einen Fehler VOR deiner Breakpoint-Zeile. Breakpoint frueher setzen oder „Pause on caught exceptions" aktivieren. (3) Falsche Datei — bei mehreren Kopien (gebundelt und Quellcode) ist der Breakpoint moeglicherweise in der Datei, die nicht ausgefuehrt wird.)

Wann welches Werkzeug?

Situation	Bestes Werkzeug	Warum
Schneller Wert-Check	Print-Statement	Am schnellsten einzufuegen
Komplexe Zustandsinspektion	IDE-Debugger	Alle Variablen gleichzeitig sehen
Webseiten-Verhalten	Browser DevTools	DOM, Netzwerk, JS zusammen
API/Netzwerk-Probleme	Network-Tab / curl	Exakte Request und Response sehen
Produktions-Bug	Strukturiertes Logging	Debugger nicht in Produktion moeglich
Parallele/Async-Bugs	Logging mit Zeitstempel	Debugger veraendert das Timing

Key Takeaways

Strategisches Print-Debugging (beschriftet, mit Kontext) ist das universellste Werkzeug — funktioniert ueberall, hinterlaesst eine Spur und ist fuer einfache Checks schneller als ein Debugger; wechsle bei mehr als 5 Prints
Browser DevTools-Tabs entsprechen Debugging-Ebenen: Console fuer Fehler, Elements fuer DOM/Events, Sources fuer Code-Stepping, Network fuer API-Aufrufe — in dieser Reihenfolge grenzt du systematisch ein
KI als Rubber-Duck-Partner: Erwartetes Verhalten, tatsaechliches Verhalten, bisherige Checks und Hypothese erklaeren — KI findet Luecken in deinem Denken

Up Next

In der naechsten Lektion lernst du die haeufigsten Bug-Muster — die wiederkehrenden Fehlertypen, die 80% aller Bugs verursachen — damit du sie sofort erkennst statt von Null zu debuggen.