Viele Review-Schleifen werden länger als nötig, weil alle Kommentare gleich behandelt werden. Ein Team gewinnt deutlich an Tempo, wenn es zwischen echten Blockern, normalen Verbesserungsvorschlägen und reinen Geschmacksfragen unterscheidet.
Was ein echter Blocker ist
Blockierend sollte ein Punkt sein, wenn die Änderung sonst fachlich falsch, technisch riskant oder nicht ausreichend wartbar wäre. Dazu gehören zum Beispiel Datenverlust, Sicherheitslücken, fehlende Berechtigungsprüfungen, offensichtlich falsches Verhalten oder ein Bruch verbindlicher Architekturregeln.
Was meistens kein Blocker ist
Alternative Benennungen, bevorzugte Schreibweisen, kleine Refactorings ohne funktionalen Nutzen oder persönliche Stilpräferenzen sollten in der Regel nicht blockieren. Solche Punkte können wertvolle Hinweise sein, aber sie rechtfertigen nicht automatisch eine weitere Review-Runde.
Beispiel: zwei vertretbare Lösungen
Wenn zwei Implementierungen fachlich korrekt, verständlich und wartbar sind, sollte ein Reviewer nicht allein deshalb blockieren, weil er persönlich Variante B bevorzugt. Ein Teamstandard kann solche Diskussionen reduzieren, aber nicht jede Entscheidung muss zentral vereinheitlicht werden.
Beispiel: echter Sicherheitsfehler
Ein neuer API-Endpunkt prüft zwar die Anmeldung, aber nicht, ob der Nutzer auf die angefragten Daten zugreifen darf. Das ist kein optionaler Hinweis. Solange die Berechtigungsprüfung fehlt, sollte der Merge blockiert bleiben.
Kommentare kennzeichnen
Hilfreich ist eine einfache Sprache im Review: „Blocker“, „Hinweis“, „Frage“ oder „optional“. Dadurch weiß die andere Person sofort, was vor dem Merge zwingend geklärt werden muss und was als Verbesserung mitgenommen werden kann.
Fragen statt Anweisungen
Viele vermeintliche Fehler beruhen auf fehlendem Kontext. Eine Frage wie „Was passiert hier bei einem leeren Wert?“ ist oft hilfreicher als „Das musst du anders machen.“ Gute Reviews schaffen Raum für Erklärung, ohne Unklarheiten einfach durchzuwinken.
Standards automatisieren
Formatierung, Imports, einfache Lint-Regeln und andere mechanische Themen gehören möglichst in Tools statt in menschliche Reviews. Je mehr davon automatisiert ist, desto mehr Zeit bleibt für Logik, Risiken und Wartbarkeit.
Wann ein Hinweis später zur Aufgabe wird
Ein optionaler Review-Hinweis kann sinnvoll sein, ohne Teil dieses Pull Requests zu werden. Wenn daraus echter Verbesserungsbedarf entsteht, ist ein separates Ticket oft sauberer als eine spontane Erweiterung des aktuellen Scopes.
Teamregel
Ein Review-Kommentar sollte blockieren, wenn ohne seine Klärung Korrektheit, Sicherheit, Datenintegrität oder ein verbindlicher Qualitätsstandard verletzt wäre. Alles andere sollte als Hinweis oder Frage kenntlich gemacht werden.