Code-Review

Wenn du Claude Code eine Aufgabe gibst, die in deiner Codebasis erledigt werden soll, berichtet Claude oft auf knappe Weise zurück. Unter der Beschreibung dessen, was Claude geändert hat, kann es eine Vielzahl von geänderten Dateien geben (von kleinen bis zu größeren Änderungen). Oft ist die Sitzung, die die Codeänderungen selbst geschrieben (und erklärt) hat, nicht der beste Richter über diese Änderungen. Es ist eine gute Praxis, dir jede Änderung selbst anzusehen, bevor du sie behältst, und Claude sie dann erneut aus einem sauberen Kontext heraus überprüfen zu lassen, ohne den Verlauf dieser Sitzung.

Überprüfe die tatsächlichen Änderungen

Ein Diff ist das Vorher-Nachher einer Änderung: die entfernten Zeilen und die hinzugefügten Zeilen, Datei für Datei. Der Befehl /diff öffnet einen interaktiven Viewer deiner nicht committeten Änderungen in dieser Form, und er kann auch zeigen, was jeder einzelne Zug von Claude geändert hat. Verwende die Pfeiltasten nach oben und unten, um zwischen Dateien zu wechseln, und Enter, um eine zu öffnen.

Die wichtigsten Dinge, die jedes Mal einen zweiten Blick verdienen, sind:

• Änderungen, um die du nicht gebeten hast. Ein Konfigurationswert, der geändert wurde, während Claude in der Datei war, oder eine umgeschriebene Hilfsmethode, die du nicht erwähnt hast.
• Tests, die schwächer wurden. Wenn das Projekt, an dem du arbeitest, Tests enthält, identifiziere alle, die übersprungen, gelöscht oder so weit gelockert wurden, bis sie bestanden haben.
• Neue Pakete und hartcodierte Werte. Eine Abhängigkeit, die nur für eine einzige Funktion hinzugefügt wurde, eine URL oder ein Schlüssel, der direkt in den Code geschrieben wurde.

Wenn die gesamte Änderung falsch ist, führe /rewind aus (oder drücke zweimal Esc bei einem leeren Prompt), wähle den Prompt aus, der sie erzeugt hat, und wähle Restore code and conversation. Eine Einschränkung, die du kennen solltest: Dateien, die durch Shell-Befehle geändert wurden, die Claude ausgeführt hat, wie z. B. eine Paketinstallation, werden nicht zurückgesetzt.

Die folgende Übung verwendet eine kleine Anmeldeformular-Aufgabe: Claudes Zusammenfassung oben, die acht Dateien, die Claude bearbeitet hat, darunter.

Bitte um eine zweite Meinung

Die Lektion Explore → Plan → Code → Commit hat gesagt, dass du vor dem Commit einer Änderung einen zweiten Prüfer hinzuziehen solltest. Eine lange Sitzung trägt alles mit sich, was sie gelesen und entschieden hat. Das ist der Kontext, den du in der vorherigen Lektion zu verwalten gelernt hast, und genau das ist der Verlauf, den du in einem Prüfer nicht haben willst. /code-review ist dieser zweite Prüfer: Er überprüft die Änderung in einem sauberen Kontext, ohne den Verlauf deiner Sitzung, und berichtet, was er findet. Er bearbeitet nichts, es sei denn, du bittest ihn darum.

Die Überprüfung läuft im Hintergrund, von Sekunden bis zu ein paar Minuten, und zählt wie jede andere Aufgabe zu deiner Nutzung, also hebe sie dir für Änderungen auf, die einen zweiten Blick verdienen. Die Ergebnisse erscheinen in deiner Konversation, sobald sie fertig ist. Du kannst auch in einfachen Worten fragen, und Claude kann dieselbe Überprüfung aus der Anfrage heraus starten. Wenn Claude stattdessen direkt antwortet, anstatt eine Überprüfung zu starten, führe den Befehl selbst aus.

Für die Änderung am Anmeldeformular kam die Überprüfung mit vier Ergebnissen zurück:

Entscheide, was mit jedem Ergebnis zu tun ist

Sortiere jedes Ergebnis in einen von drei Stapeln:

1. Jetzt beheben. Dies ist ein echtes Problem, es ist wichtig, und es muss behoben werden.
2. Nachfragen. Dies ist der Stapel für Ergebnisse, die du nicht ganz verifizieren kannst oder die seltsam erscheinen. Es ist möglich, dass Prüfer, die Codeänderungen ohne Vorwissen lesen, auch Dinge übersehen.
3. Liegen lassen. Dies ist ein echtes Problem, aber klein oder unbedeutend. Diese können oft zu einer Gruppe von Korrekturen zusammengefasst werden, die du in einer zukünftigen Sitzung erledigst.

Um nachzufragen, zitiere das Ergebnis gegenüber Claude und bitte Claude, es noch einmal zu überprüfen. Für das zweite Ergebnis oben würdest du Folgendes eingeben:

Wann immer du um eine Korrektur bittest, ist es gut, gleichzeitig um einen Nachweis zu bitten:

Wenn eine Korrektur schließlich zu einer eigenen großen Änderung heranwächst, führe die Überprüfung erneut aus.

Wann es sich lohnt, Dinge genauer zu überprüfen

Eine einfache, einzeilige Änderung braucht oft nur einen kurzen Blick auf das Diff und sonst nichts. Du solltest eine menschliche Überprüfung und eine Claude-Überprüfung verwenden, wenn eine Änderung größer ist, als du im Kopf behalten könntest, wenn sie etwas Sensibles berührt oder etwas Destruktives tut, und bevor du die Arbeit an ein Teammitglied übergibst.

Probier es aus: Sortiere die vier Ergebnisse

Zusammenfassung

• Lies das tatsächliche Diff der Dateiänderungen, bevor du allein der Zusammenfassung vertraust. Führe /diff aus und achte auf Änderungen, um die du nicht gebeten hast, schwächere Tests und neue Pakete oder hartcodierte Werte.
• Hol dir eine zweite Meinung aus einem sauberen Kontext mit /code-review (oder frage in einfachen Worten und lass Claude es starten). Der Prüfer berichtet, und Claude bearbeitet nichts, es sei denn, du bittest darum.
• Behandle jedes Ergebnis als „jetzt beheben", „nachfragen" oder „liegen lassen", und bitte bei jeder Korrektur um einen Nachweis.

Wenn der Prüfer dasselbe Problem mehrmals markiert, könnte es eine gute Idee sein, eine Regel zu schreiben, die Claude zu Beginn jeder Sitzung liest. Diese Datei ist CLAUDE.md, und sie ist als Nächstes dran.