code-review: Review entlang zweier Achsen

Hauptfluss🤖 Kann selbst gewählt werden🔧 Angepasst für unser SetupHerunterladen ↓

Review des Diffs zwischen HEAD und einem fixen Punkt, den du angibst, entlang zweier getrennter Achsen:

• Standards: folgt der Code den dokumentierten Coding-Standards dieses Repos?
• Spec: setzt der Code das ursprüngliche Ticket/die Spec tatsächlich um?

Wann brauche ich das?

Bevor du committest, wenn du einen Branch oder eine Änderung seit einem bestimmten Punkt reviewen willst.

Wie funktioniert das?

1. Fixpunkt festlegen

Du nennst den Fixpunkt (Commit-SHA, Branch, Tag, main, HEAD~5, …). git diff <fixpunkt>...HEAD und git log <fixpunkt>..HEAD --oneline sind über die Git-Introspektion des Chats abrufbar, das funktioniert direkt.

2. Spec-Quelle

Da keine Tracker-Anbindung existiert, fügst du den Spec-/Ticket-Text manuell ein (Copy-Paste aus Jira), oder verweist auf eine Datei im Repo (docs/, .scratch/). Ohne Spec markiert die Spec-Achse sich selbst als "keine Spec verfügbar" statt sie zu überspringen.

3. Standards-Quellen

Alles im Repo, das dokumentiert, wie Code geschrieben werden soll (CODING_STANDARDS.md, CONTRIBUTING.md, ESLint-/Checkstyle-Konfiguration). Zusätzlich gilt immer die Fowler-Smell-Baseline (siehe unten), der Repo-Standard hat aber immer Vorrang, wo er etwas ausdrücklich erlaubt, was die Baseline anmahnen würde.

Smell-Baseline (jeder Fund ist eine Einschätzung, kein hartes Urteil):

• Mysterious Name: Name verrät nicht, was etwas tut/hält → umbenennen.
• Duplicated Code: dieselbe Logik mehrfach im Diff → gemeinsame Form extrahieren.
• Feature Envy: eine Methode greift mehr auf fremde Daten zu als auf eigene → verschieben.
• Data Clumps: dieselben Felder reisen immer zusammen → in einen Typ bündeln.
• Primitive Obsession: ein Primitive/String steht für ein Domain-Konzept → eigener Typ.
• Repeated Switches: dieselbe Fallunterscheidung wiederholt sich → Polymorphie oder eine Map.
• Shotgun Surgery: eine fachliche Änderung verstreut sich über viele Dateien → bündeln.
• Divergent Change: eine Datei ändert sich aus mehreren unabhängigen Gründen → aufteilen.
• Speculative Generality: Abstraktion für einen Bedarf, den die Spec nicht hat → löschen.
• Message Chains: lange a.b().c().d()-Ketten → hinter einer Methode verstecken.
• Middle Man: eine Klasse, die nur weiterreicht → weglassen, direkt aufrufen.
• Refused Bequest: eine Unterklasse ignoriert das meiste, was sie erbt → Komposition statt Vererbung.

4. Beide Achsen nacheinander statt parallel

Im Original laufen Standards- und Spec-Review als zwei parallele Subagenten. Ohne Agenten laufen sie sequenziell im selben Chat: erst die eine Achse komplett durchgehen und das Ergebnis notieren, dann die andere. Inhaltlich identisch, nur nacheinander statt gleichzeitig.

5. Zusammenfassen

Beide Berichte unter eigenen Überschriften ## Standards und ## Spec, nicht mischen, nicht gegeneinander aufwiegen. Ein Fund kann eine Achse bestehen und die andere durchfallen lassen, das ist der Grund für die Trennung.

Wo passt das rein?

Letzter Kettenschritt im Hauptfluss (grill-me → to-spec → to-tickets → implement → code-review), von implement am Ende aufgerufen. Reicht auch standalone, wenn du selbst einen Branch reviewen willst. Gesamtüberblick: ask-simon.

Was sich gegenüber dem Original geändert hat

• Keine parallelen Subagenten, sondern ein sequenzieller Zwei-Pass-Review im selben Chat.
• Keine automatische Spec-Beschaffung über den Issue-Tracker, du kopierst den Spec-Text manuell rein.