Viele unnötige Review-Schleifen entstehen nicht wegen des Codes, sondern wegen missverständlicher Kommentare. „Bitte ändern“, „Gefällt mir nicht“ oder ein einzelnes Fragezeichen lassen offen, ob etwas wirklich blockiert, nur diskutiert werden soll oder lediglich eine alternative Idee ist.
Priorität sichtbar machen
Ein Team sollte klar unterscheiden können zwischen einem echten Blocker, einem sinnvollen Verbesserungshinweis und einer offenen Frage. Dafür braucht es kein kompliziertes System. Schon Begriffe wie Blocker, Hinweis und Frage reichen oft aus.
Blocker brauchen eine überprüfbare Begründung
Ein Blocker sollte sich auf Verhalten, Sicherheit, Datenintegrität, verbindliche Architektur oder eine klare Teamregel beziehen. „Ich würde das anders machen“ ist keine ausreichende Begründung.
Schlecht: „Bitte umbauen.“
Besser: „Blocker: Bei parallelen Requests kann hier derselbe Datensatz zweimal angelegt werden. Bitte die Eindeutigkeit auf Datenbankebene absichern.“
Hinweise als Hinweise formulieren
Nicht jede Verbesserung muss vor dem Merge umgesetzt werden. Wenn eine alternative Benennung, ein kleiner Refactoring-Vorschlag oder eine Lesbarkeitsidee optional ist, sollte das auch so erkennbar sein.
Beispiel: „Hinweis: isEligible wäre für mich klarer als valid, weil hier nicht die technische Gültigkeit geprüft wird. Kein Blocker.“
Fragen dürfen echte Fragen sein
Manchmal fehlt dem Reviewer Kontext. Dann ist eine Frage besser als eine als Forderung verkleidete Vermutung. „Warum passiert das hier?“ kann völlig legitim sein – sofern klar ist, dass zunächst Verständnis gesucht wird.
Die Auswirkung nennen
Kommentare werden leichter nachvollziehbar, wenn die mögliche Folge beschrieben wird. Statt „Null prüfen“ ist „Ohne Prüfung entsteht bei importierten Altbeständen ein Fehler, weil dort die Kunden-ID fehlen kann“ deutlich hilfreicher.
Problem und Wunschlösung trennen
Reviewer sehen oft eine mögliche Lösung und formulieren sie direkt als Pflicht. Besser ist, zuerst das Problem zu benennen. Vielleicht kennt die Person, die den Code geschrieben hat, eine einfachere Lösung.
Geschmacksfragen aus dem Review herausnehmen
Formatierung, Importreihenfolge und andere automatisierbare Stilfragen sollten möglichst durch Formatter, Linter oder verbindliche Konventionen gelöst werden. Wiederkehrende persönliche Präferenzen kosten im Review Zeit, ohne die fachliche Qualität proportional zu erhöhen.
Ein Kommentar pro Problem
Wenn ein einzelner Kommentar drei verschiedene Punkte enthält, ist später schwer erkennbar, was davon erledigt wurde. Besser sind getrennte Kommentare oder ein klar strukturierter Sammelkommentar auf Pull-Request-Ebene.
Eine einfache Struktur
Typ: Blocker / Hinweis / Frage
Beobachtung: Was ist konkret auffällig?
Auswirkung: Warum ist das relevant?
Erwartung: Was sollte geklärt oder geändert werden?
Ziel: weniger Reibung, nicht weniger Kritik
Klare Review-Kommentare machen Reviews nicht weicher. Echte Blocker werden sichtbarer, weil sie nicht zwischen Stilhinweisen und persönlichen Vorlieben verschwinden. Gleichzeitig können optionale Verbesserungen geäußert werden, ohne den Merge unnötig zu verzögern.