Binaere-Suche-Debugging

Das Problem

Wenn sich ein Fehler in einer grossen Codebasis verbirgt — Tausende Zeilen, Dutzende Module — ist es unpraktisch, jede Zeile zu pruefen. Entwickler verschwenden Stunden mit wahllosen console.log-Anweisungen. Binaere-Suche-Debugging halbiert den Suchraum mit jedem Schritt und findet jeden Fehler in O(log n) Iterationen statt O(n).

Der Prompt

Du bist ein Debugging-Stratege, spezialisiert auf binaere Suchistolation. Hilf mir, einen Fehler per Divide-and-Conquer zu lokalisieren:

FEHLERBESCHREIBUNG: [beschreibe das fehlerhafte Verhalten]
ERWARTETES VERHALTEN: [was stattdessen passieren sollte]
BEREICH: [z.B. "irgendwo im Checkout-Flow", "in der Datenverarbeitungs-Pipeline"]
CODEBASIS-GROESSE: [ungefaehre Anzahl beteiligter Dateien/Module]

Wende dieses Binaere-Suche-Debugging-Protokoll an:
1. **Observable definieren**: Was ist das klarste einzelne Symptom, anhand dessen ich den Fehler bestaetigen kann?
2. **Pipeline kartieren**: Liste jedes Modul/jede Funktion/jeden Schritt, den die Daten von Eingabe bis zur fehlerhaften Ausgabe durchlaufen.
3. **Mittelpunkt finden**: Identifiziere die exakte Mitte der Pipeline fuer den ersten Checkpoint.
4. **Entscheidungslogik**: Am Mittelpunkt — sind die Daten noch korrekt? JA → Fehler in der zweiten Haelfte. NEIN → Fehler in der ersten Haelfte.
5. **Checkpoints generieren**: Liefere die exakten Code-Snippets fuer jeden Checkpoint.
6. **Iterationsplan**: Bilde den vollstaendigen binaeren Suchbaum ab — wie viele Iterationen sind noetig?
7. **Ausschlussbeweis**: Erklaere nach jedem Schritt, was definitiv ausgeschlossen wurde und warum.

Beispiel-Ausgabe

Pipeline kartiert: Eingabe → validateForm() → transformData() → apiCall() → processResponse() → updateState() → renderUI()
Mittelpunkt: Checkpoint NACH apiCall() einfuegen — pruefen ob Response-Payload dem erwarteten Schema entspricht
Iteration 1: Wenn Response korrekt → Fehler in processResponse/updateState/renderUI (3 Schritte)
Iteration 2: Pruefung nach updateState() → eingegrenzt auf 1-2 Schritte
Benoetigt: 3 Iterationen (vs. 7 bei sequentieller Pruefung)

Wann verwenden

Diesen Skill einsetzen, wenn der Fehler irgendwo in einer langen Kette von Operationen liegt und nicht sofort ersichtlich ist, welcher Schritt die Daten korrumpiert. Ideal fuer Datentransformations-Pipelines, mehrstufige Formularverarbeitung und jeden Flow mit mehr als 5 Stationen.

Profi-Tipps

• Mit dem Mittelpunkt beginnen, nicht am Anfang — die meisten Entwickler debuggen linear. Ein Sprung zur Mitte eliminiert sofort 50% des Codes.
• Assertions statt Logs verwenden — assert(data.id !== undefined, 'ID fehlt nach Schritt 3') stoppt die Ausfuehrung am exakten Fehlerpunkt, waehrend Logs manuelles Lesen erfordern.
• Mit git bisect kombinieren — bei Regressionen wendet git bisect die binaere Suche auf Commits an und findet den exakten Commit, der den Fehler einfuehrte.
• Einen “Bug-Zaun” erstellen — nach Isolation der fehlerhaften Funktion permanente Assertions an deren Grenzen als Regressionsschutz hinzufuegen.