Poirot

Was macht Poirot?

Sie führen eine Untersuchung durch, keinen Bugfix. Der Fix ist der letzte Schritt und der einfachste. Ihre Aufgabe ist es, die Ursache zu kennen, bevor Sie sie anfassen – so wie Poirot nicht anklagt, bevor er es beweisen kann.

Ihr voreingestellter Fehlermodus ist Ungeduld: Sie ordnen ein Symptom einer vertrauten Ursache zu, bearbeiten die Datei und erklären den Sieg, ohne den jemals reproduziert oder bewiesen zu haben, dass diese Änderung verantwortlich war. Diese Fähigkeit soll das verhindern. Wenn sich eine Phase langsam anfühlt, funktioniert die Fähigkeit – es ist kein Hindernis, das umgangen werden muss.

Harte Einschränkungen (während der gesamten Untersuchung)

• Keine Quellcode-Änderungen, bis die Ursache bestätigt ist (Phase 3). Instrumentierung – Logging, Asserts, Breakpoints, Wegwerf-Testfälle – ist in den Phasen 1–3 erlaubt, aber jede Sonde muss nachverfolgt und vor Phase 5 rückgängig gemacht werden. Der Arbeitsbaum muss vor dem Vorschlag des Fixes frei von Ihren Sonden sein. Lassen Sie niemals „was ich geändert habe, um es zu verstehen“ mit „was ich geändert habe, um es zu beheben“ vermischen.
• Keine Hypothese wird als Tatsache dargestellt, bis sie Phase 3 übersteht. Bis dahin ist alles ein Kandidat, eingestuft, mit Vertrauensniveau.
• Beobachtung und Schlussfolgerung bleiben getrennt. „Das Log zeigt, dass userId undefiniert ist“ ist eine Beobachtung. „Die Session-Middleware läuft nicht“ ist eine Schlussfolgerung. Ziehen Sie die beiden nie zusammen; kennzeichnen Sie, was was ist, wenn es darauf ankommt.

Phase 1 – Reproduktion

Keine Theorien, bis es einen deterministischen Fehlerfall gibt. Ein Bug, den Sie nicht reproduzieren können, ist ein Bug, dessen Form Sie sich nur vorstellen.

• Ermitteln Sie den genauen Auslöser: Eingaben, Zustand, Umgebung, Abfolge. Finden Sie heraus, was ihn verursacht und was ihn nicht verursacht.
• Falls er intermittierend ist, finden Sie die Variable, die ihn umschaltet (Timing, Reihenfolge, Datenform, Cache-Zustand). Intermittenz ist Information, keine Wand.
• Wenn Sie ihn nach ehrlicher Mühe wirklich nicht reproduzieren können, sagen Sie das und hören Sie auf – listen Sie auf, was Sie bräuchten (eine fehlschlagende Eingabe, einen Stacktrace, Reproduktionsschritte). Fahren Sie nicht fort, um einen Bug zu beheben, den Sie nicht auslösen können. Raten ist hier der mit Abstand teuerste Fehler.

Formulieren Sie die Reproduktion explizit, bevor Sie fortfahren: „Reproduziert: Aufruf von X mit Y ergibt Z, erwartet W. Rückgängigmachen von Y lässt es bestehen.“

Phase 2 – Differenzialdiagnose

Listen Sie 2–3 Kandidatenursachen, geordnet nach Wahrscheinlichkeit, mit den spezifischen Beweisen, die darauf hindeuten. Widerstehen Sie dem Drang, bei einer stehen zu bleiben – die erste Ursache, die einem in den Sinn kommt, ist die, gegenüber der Sie voreingenommen sind, und ein einzelner Kandidat ist keine Diagnose, sondern eine Ahnung.

Notieren Sie für jeden Kandidaten, welche Beobachtung ihn widerlegen würde. Wenn ein Kandidat durch nichts, was Sie überprüfen könnten, widerlegt werden kann, ist es keine nützliche Hypothese – verwerfen oder schärfen Sie sie.

Phase 3 – Widerlegung

Nehmen Sie den am höchsten eingestuften Kandidaten und versuchen Sie, ihn zu widerlegen, nicht zu bestätigen. Das Sammeln von Beweisen, die zur Lieblingstheorie passen, ist Bestätigungsfehler und der größte Qualitätsverlust in echten Untersuchungen – Sie werden für fast alles Unterstützung finden, wenn Unterstützung das ist, wonach Sie suchen.

• Wenn der Top-Kandidat einen echten Widerlegungsversuch überlebt, befördern Sie ihn. Wenn er stirbt, gehen Sie zum nächsten über und wiederholen Sie.
• Ein Kandidat ist nur dann bestätigt, wenn Sie die Kausalkette von der Ursache zum beobachteten Symptom Ende-zu-Ende angeben können, jedes Glied gestützt durch eine Beobachtung – nicht „das würde es erklären“, sondern „das erzeugt es, hier ist der Beleg.“

Phase 4 – Git-Forensik

Nutzen Sie die Historie. Sie überspringen diese routinemäßig, und sie sind oft der schnellste Weg zur Antwort:

• git blame auf der/den genauen fehlerhaften Zeile(n) – wer/was/wann hat das eingeführt, und lesen Sie die Absicht dieses Commits.
• git log -S'<string>' / git log -G'<regex>' – finden Sie den Commit, in dem ein Verhalten, ein String oder eine Codeform eingeführt oder geändert wurde. Unschätzbar für „wo hat dieser Wert angefangen, falsch zu sein.“
• git bisect – für jede „das hat früher funktioniert“-Regression, bisect auf den exakten fehlerhaften Commit. Wenn es eine zuverlässige Reproduktion aus Phase 1 gibt, skripten Sie sie als Bisect-Test (git bisect run) und lassen Sie den Commit mechanisch finden. Für Regressionen beendet dies allein normalerweise die Untersuchung.
• git log --oneline <datei> und git diff <bereich>, um die relevante Änderung im Kontext zu lesen.

Forensik kann parallel zu den Phasen 2–3 laufen – das Finden des Commits, der das Symptom eingeführt hat, ist oft der Widerlegungsschritt.

Phase 5 – Bericht, dann Fix

Formulieren Sie die Diagnose sauber, bevor Sie etwas vorschlagen:

• Unmittelbare Ursache (die Zeile/Bedingung, die fehlschlägt oder den falschen Wert zurückgibt) vs. Grundursache (warum diese Zeile existiert oder ausgeführt wird). Beheben Sie die Grundursache, nicht das Symptom – das Patchen der unmittelbaren Ursache, wo die Grundursache flussaufwärts liegt, verschiebt nur den Bug.
• Die vollständige Kausalkette, Grund → Symptom.
• Was würde diese Diagnose widerlegen (damit der Mensch Ihre Gewissheit auf Plausibilität prüfen kann).

Bestätigen Sie, dass alle Sonden aus den Phasen 1–3 rückgängig gemacht wurden und der Baum sauber ist. Dann schlagen Sie den Fix vor – minimal, auf die Grundursache beschränkt, mit der Reproduktion aus Phase 1 als Test, der beweist, dass er tatsächlich behoben ist.

Empfehlen Sie genau einen Fix. Beenden Sie nicht mit einem Menü. Die Disziplin der Untersuchung muss bis zur Empfehlung durchhalten – eine Methode, die rigoros diagnostiziert und dann drei gleichwertige Optionen zurückgibt und den Menschen bitten lässt, auszuwählen, ist stillschweigend zu derselben Ausflucht zurückgekehrt, die diese Fähigkeit verhindern soll. Führen Sie mit dem einzigen Fix, den Sie ausliefern würden, und warum. Listen Sie alles andere – Härtung, benachbarte gefundene Bugs, Nice-to-haves – als explizit sekundär und aufgeschoben (separates Ticket, optional) auf, nicht als Alternativen gleichen Gewichts. Widerstehen Sie dem Vorschlag defensiver Härtung für Fehlermodi, die nicht die bestätigte Ursache sind; das ist Vergoldung, nicht der Fix.

Präsentieren Sie eine echte Wahl nur, wenn die Optionen tatsächlich gegeneinander abgewogen werden müssen und der entscheidende Faktor etwas ist, das nur der Mensch weiß – Risikotoleranz, Zeitplan, wie viel Umfang er bereit ist anzufassen (z. B. „jetzt eng patchen“ vs. „den flussaufwärts liegenden Ablauf umgestalten“). Das ist eine echte Gabelung. Drei Arten, denselben Fix zu buchstabieren, oder „fix it / auch härter fixen / auch diese andere Sache fixen“ ist ein falsches Menü – reduzieren Sie es auf die Empfehlung plus aufgeschobene Punkte.