Review-Bemerkung beantworten
Behebe eine Code-Review-Bemerkung, indem ein klärender Kommentar an der richtigen Stelle im Quellcode eingefügt wird, der die Begründung festhält, damit zukünftige Reviewer denselben Einwand nicht erheben.
Eingaben
Leite beide Eingaben aus dem Gesprächskontext ab. Frage nur nach, wenn sie mehrdeutig sind.
Eingabe 1 — Die Bemerkung.
Ein Befund des Reviewers: meist eine Tabellenzeile mit einem Ort (Datei:Zeile) und einer Beschreibung des Anliegens.
Die Tabelle stammt normalerweise aus dem Skill dakubo-display-pr-remarks oder dakubo-review-commit-range. Wenn keine Tabelle im Gespräch vorhanden ist und einer dieser Skills verfügbar ist, verwende ihn, um die Tabelle zu erstellen. Wenn nicht, frage den Benutzer nach der Bemerkung.
Eingabe 2 — Die Erklärung. Die Antwort des Entwicklers: warum der Code so wie er ist korrekt ist, die Designentscheidung dahinter, der akzeptierte Kompromiss oder der Gesamtkontext, den der Reviewer übersehen hat. Dies muss die Bemerkung nicht direkt widerlegen – es kann lediglich die Perspektive des Reviewers verschieben.
Prozess
- Lies die Datei an dem Ort aus Eingabe 1.
- Identifiziere das genaue Konstrukt, das die Bemerkung betrifft (Methode, Block, Feld, Zeile).
- Verfasse einen Kommentar, der:
- Den Kern von Eingabe 2 erfasst (die Begründung / Entscheidung / den Kontext).
- Prägnant ist – maximal ein bis vier Zeilen.
- Den Reviewer, die PR oder die Bemerkungsnummer nicht erwähnt (Kommentare überdauern Reviews).
- Nicht wiederholt, was der Code bereits sagt – füge nur das WARUM hinzu, das beim Lesen nicht offensichtlich ist.
- Das Anliegen der Bemerkung adressiert, wenn dies die Erklärung klarer macht, aber dies ist optional.
- Platziere den Kommentar unmittelbar über dem betroffenen Konstrukt oder inline, wenn ein abschließender Kommentar natürlich passt.
- Wende die Bearbeitung an.
Ausgabe
Bestätige die Datei und Zeile, an der der Kommentar hinzugefügt wurde. Ein Satz reicht.
Was NICHT zu tun ist
- Schreibe den Code nicht um, es sei denn, der Benutzer bittet explizit darum.
- Schreibe keinen Kommentar, der lediglich wiederholt, was der Code tut.
- Verweise im Kommentar nicht auf „der Reviewer sagte…“ oder „PR #N“.
- Füge keinen Kommentar hinzu, der länger als ~4 Zeilen ist; wenn die Erklärung mehr braucht, gehört sie in ein Design-Dokument oder eine Commit-Nachricht, nicht inline.