App

Zwischen zu oberflaechlich und zu nitpicky: Wie gute Reviews aussehen

Ein gutes Code Review ist kein Kontrollinstrument, sondern gemeinsames Lernen, so gelingt es in der Praxis.

Zu schnell, zu oberflaechlich, zu fokussiert auf Stil statt Logik. Oder das Gegenteil: zu lang, zu detailverliebt.

Beides kostet Zeit und erzeugt wenig Wert. Ein Code Review hat mehrere Ziele gleichzeitig: Bugs finden, Wissen teilen, Qualitaet sichern, Teamstandards etablieren.

Was ein Review leisten sollte

Ja zu: Logikfehlern, potenziellen Abstuerzen, Security-Issues, Verstaendlichkeit, Architektur-Entscheidungen, fehlenden Tests. Nein zu: Code-Stil, den der Linter regeln sollte, persoenlichen Praeferenzen ohne Begruendung, Kommentaren ohne Mehrwert.

Aus Sicht des Reviewers

Reviewen als Kollaborateur, nicht als Richter. Der Autor hat oft Kontext, den der Reviewer nicht hat, erst fragen, nicht urteilen. Die Frage nach dem Warum oeffnet mehr als die Feststellung, etwas sei falsch.

Aus Sicht des Autors

Ein kleiner PR wird sorgfaeltiger reviewt als ein grosser, bei 1.000 Zeilen sinkt die Aufmerksamkeit spuerbar, bei 150 Zeilen bleibt sie hoch. Ein Self-Review vor dem Oeffnen des PRs spart oft die Haelfte der spaeteren Kommentare bereits selbst.

Checkliste: PR-Beschreibung erklaert Was und Warum, PR-Groesse auf maximal 300 bis 400 Zeilen begrenzt, Linter laeuft vor Review-Anfrage durch, Reviewer hat ausreichend Kontext, Feedback konstruktiv formuliert, Follow-up-Kommentare werden aufgeloest.

Ein kleiner, aber wirkungsvoller Kniff

Viele Teams unterschaetzen, wie stark die Formulierung eines Kommentars die Reaktion des Autors beeinflusst. „Das ist falsch“ erzeugt fast automatisch eine Verteidigungshaltung, waehrend „Ich bin nicht sicher, ob das den Edge Case X abdeckt, kannst du kurz erklaeren?“ dieselbe Beobachtung macht, aber Raum fuer Kontext laesst. Manche Teams fuehren zusaetzlich ein einfaches Praefix-System ein, etwa „Nitpick:“ fuer unwichtige Kleinigkeiten oder „Blocking:“ fuer Muss-Aenderungen, damit der Autor priorisieren kann, welches Feedback wirklich vor dem Merge geloest werden muss.

Ihr wollt eure Review-Kultur verbessern? markom.digital beraet Teams bei der Einfuehrung effektiver Code-Review-Prozesse, von der Tooling-Konfiguration bis zur Retrospektive.

Weitere Beiträge