Lernreise 5 — Erst verifizieren, dann erweitern

Was du nach dieser Reise kannst

Du verstehst, dass forward momentum — der Drang weiterzugehen — der größte Feind von Korrektheit ist. Du kennst die Disziplin der Verifikations-Rituale: was sie sind, warum sie spannungsarm wirken müssen, und wie sie atomare Commits ermöglichen.

Konkret nach Tier 3: Du hast ein eigenes Verifikations-Ritual, das du bewusst anwendest, und du strukturierst Commits so, dass jeder Commit für sich verifiziert ist.

Anker — was die iDev-Direktive in einer Session zeigte

Beim Debuggen von iMenu galt die iDev-Direktive: „Erst verifizieren, dann erweitern."

In acht aufeinanderfolgenden Bug-Fixes wurde vor dem Commit jedes Mal:

  1. Die geänderte Funktion als ganze App durchgelaufen — nicht nur als Unit-Test
  2. Das erwartete Verhalten erst beschrieben, dann verifiziert
  3. Der Commit erst geschrieben, wenn die Verifikation grün war

Acht Bugs, acht atomare Commits, keiner musste später revidiert werden.

Das klingt langsam, ist aber das Gegenteil. Die Reibung saß an der richtigen Stelle. Keine „ich war mir sicher, aber doch nicht ganz"-Momente, kein „eigentlich sollte das laufen"-Druck, kein „wir gucken später".

Tier 1 · Erkennen — Was „verifiziert" wirklich heißt

Die zwei Bedeutungen von „grün"

TXT
A) Die Tests sind grün.
B) Der Fix tut, was er soll.

Diese beiden sind nicht dasselbe. Wenn dein Test-Suite den Pfad gar nicht abdeckt, der gebrochen war, sagen grüne Tests nichts über den Fix aus.

Konkret aus der iMenu-Session: der vergessene self._render-Aufruf war in einem set_interval(2.0, self._render). Kein Unit-Test deckte den Timer ab. Tests blieben grün. Der Bug hat trotzdem zwei Sekunden nach Overlay-Öffnung die App umgeworfen.

Nur die echte Ausführung des Code-Pfads beweist, dass der Fix wirkt. Tests erhöhen das Vertrauen — sie ersetzen die Verifikation nicht.

Forward Momentum — die Falle

Du hast einen Bug gefunden. Du hast eine Idee, wie du ihn fixt. Du schreibst den Fix. Dein Verstand sagt: „weiter, weiter, der nächste Bug wartet."

Das ist forward momentum. Es ist ein Gefühl, kein Argument. Und es ist die häufigste Ursache von:

  • Fixes, die den Bug nicht wirklich beheben
  • Commits, die mehrere Bugs vermischen
  • „Eigentlich sollte das laufen"-Commits, die später zurückgerollt werden
  • Drei Tage später: „wann ist das eigentlich kaputt gegangen?"

Die Antwort darauf ist nicht „mehr Disziplin" — es ist ein Ritual, das die Momentum-Pause erzwingt.

Tier 2 · Üben — Das Green-Light-Protokoll

Sechs Schritte. Jeden aufschreiben.

Schritt 1 — Was ist die Hypothese?

Bevor du den Fix schreibst:

TXT
HYPOTHESE: Das Overlay friert, weil set_interval(2.0, self._render)
auf eine umbenannte Methode zeigt. Der AttributeError im Timer-
Callback wird im UI-Thread nicht sichtbar — er verstummt im Loop.

Wenn du das nicht aufschreiben kannst, hast du den Bug noch nicht verstanden — und kannst keinen Fix verifizieren.

Schritt 2 — Was wäre Grün?

TXT
GREEN-LIGHT-KRITERIEN:
- Overlay öffnen mit `s`
- 5 Sekunden warten — kein Freeze
- Tastendruck `q` — Overlay schließt
- Sessions-Liste hat sich mindestens einmal aktualisiert

Genau die Schritte, die du nachher tatsächlich tun wirst. Nicht abstrakt.

Schritt 3 — Fix schreiben

Klein halten. Eine Sache pro Commit. Den Rest später.

Schritt 4 — Verifizieren

Genau die Schritte aus Schritt 2 durchführen. Nicht ähnliche Schritte. Nicht „sollte schon stimmen". Genau diese.

Schritt 5 — Commit schreiben

Atomar. Die Commit-Nachricht beantwortet drei Fragen:

TXT
fix(SessionsOverlay): replace renamed _render with _update_display

WAS:           set_interval-Callback zeigt jetzt auf _update_display.
WARUM:         Methode wurde in Commit a4f48 umbenannt, ein Aufruf blieb.
WIE VERIFIZIERT: Overlay 5s offen gehalten, periodisches Update sichtbar,
                Schließen mit `q` funktioniert.

Die „Wie verifiziert"-Zeile ist die wichtigste — sie ist dein zukünftiges Argument, dass dieser Commit gut war.

Schritt 6 — Nächster Bug

Erst jetzt. Ein Bug pro Iteration. Kein „während ich dabei bin, noch dieses und das".

Die Asymmetrie

Schritte 1, 2 und 5 fühlen sich wie Reibung an. Sie sind die Ersparnis. Drei Wochen später, wenn etwas explodiert, sagt der Commit dir genau, was er getestet hat — du musst nicht raten.

Tier 3 · Übertragen — Dein eigenes Ritual

Bau dein eigenes Ritual. Mindestens diese drei Elemente:

  1. Hypothese-Aufschrieb — bevor der Fix geschrieben wird
  2. Green-Light-Kriterien — die konkreten Schritte, die nachher Beweis liefern
  3. Verifikations-Zeile im Commit — sodass das Argument im Repo bleibt

Anti-Pattern: „ich gucke mal eben"

Du fängst an, einen Bug zu jagen. Auf dem Weg fällst du über einen anderen. „Den fixe ich auch mal eben." Beide landen im selben Commit. Verifiziert wurde keiner einzeln.

Drei Wochen später bricht einer der beiden Fixes etwas. git revert rollt beide zurück. Der unschuldige Fix verschwindet auch. Du musst ihn neu schreiben.

Faustregel: Ein Bug pro Commit, eine Verifikation pro Commit. Was du nebenbei findest, kommt auf eine Liste — nicht in den aktuellen Diff.

Das echte Stake — gleichzeitige Mutation deines Arbeitsbaums

In manchen Setups läuft ein Auto-Commit-Sweep im Hintergrund. Während du selbst etwas änderst, kann ein Hintergrund-Agent committen. Atomare Commits sind hier nicht nur Disziplin — sie sind der einzige Weg, die Spuren auseinanderzuhalten:

BASH
# Was hat _meine_ Hand getan?
git log --author="Daniel Klier" --since="1 hour ago"

# Was ist im selben Zeitraum noch passiert?
git log --since="1 hour ago"

Wenn dein „Fix" mehrere Bugs vermischt und gleichzeitig der Sweep läuft, ist die Forensik ein Tag Arbeit. Wenn jeder Commit eine Hypothese und eine Verifikation trägt, ist sie zwei Minuten.

Deine Übung

Such die letzten drei Commits, die du gemacht hast. Pro Commit:

  • Welche Hypothese steht dahinter? (Steht sie im Commit?)
  • Was hätte „grün" bedeutet? (Wurde es geprüft?)
  • Welcher Pfad wurde tatsächlich ausgeführt? (Oder waren es nur Tests?)

Wenn du eine Frage nicht beantworten kannst, schreib das nächste Mal ein bisschen mehr in die Commit-Nachricht. Nicht für jetzt — für dich in drei Wochen.

Was du jetzt weißt

  • „Tests grün" und „Fix wirkt" sind nicht dasselbe. Nur die echte Pfad-Ausführung beweist den Fix.
  • Forward momentum ist die häufigste Bug-Quelle. Die Antwort ist ein Ritual, das den Schub bricht.
  • Atomare Commits sind eine Form von Verifikation. Sie machen drei Wochen später eine Antwort möglich.
  • „Wie verifiziert"-Zeilen im Commit sind dein zukünftiges Argument. Schreib sie für das Zukunfts-Ich.

Weiterführende Reisen

  • Code als Daten — AST — die statische Stufe deines Verifikations-Rituals. 0,3 Sekunden, vor jedem Commit.
  • Refactoring ohne Zeitbomben — Refactorings erzwingen Mehr-Datei-Sweeps. Verifikation pro Commit hält sie atomar.
  • Testpyramide für TUIs — welche Test-Stufe die Verifikation der echten Pfad-Ausführung am besten ersetzt — und wann sie es nicht kann.
  • Den Loop nicht blockieren — Bugs, die nur in echter Laufzeit auftreten. Genau hier ist „Tests grün ≠ Fix wirkt" am gefährlichsten.

Quellen & Anker

  • iDev-Direktive: „Erst verifizieren, dann erweitern" — die Grundregel der iDev-Disziplin
  • iMenu-Session: 8 atomare Fix-Commits, alle einzeln verifiziert, alle stehen
  • ~/my Auto-Commit-Sweep — der praktische Grund, warum atomare Commits keine Tugend, sondern Notwendigkeit sind