Code-Review-Prozesse beginnen häufig mit „Qualitätskontrolle", enden aber in „Ego-Kämpfen". Mit wachsendem Team werden zwei Fallen deutlich: PRs warten wochenlang oder jeder Kommentar wird als persönliche Kritik empfunden. Beide Probleme entstehen aus derselben Wurzel — messbaren Regeln fehlt es. Nach 8 Jahren mit einem 15+-köpfigen Team aus verschiedenen Disziplinen bei Roibase haben wir gelernt: Solange die Review-Kultur nicht auf numerischen Kriterien aufbaut, sind persönliche Urteile unvermeidlich. Wenn man Time-to-Review, Comment Density und PR-Size zu Systemkriterien macht, steigt die Qualität und sinken Konflikte.
Review-Geschwindigkeit: Time-to-Review-SLA
Jede PR hat einen Lebenszyklus. Die Zeit vom Öffnen bis zum ersten Kommentar — time-to-first-review — ist der erste Indikator für Team-Disziplin. Bei Roibase haben wir diese Zeit auf maximal 4 Stunden begrenzt (während Arbeitszeiten). Warum 4 Stunden? Im asynchronen Arbeitsmodell ist das der Sweet Spot zwischen Schutz von Deep-Work-Blöcken und beschleunigtem Feedback-Loop.
Die Regel lautet: Innerhalb von 4 Stunden nach dem Öffnen einer PR muss mindestens ein Reviewer schauen. Das Enforce-Mechanismus ist nicht eine Slack-Benachrichtigung, sondern ein GitHub-Actions-Workflow. Wenn eine PR geöffnet wird, wird automatisch ein Tag vergeben; nach 4 Stunden geht ein Slack-Mention an den zugewiesenen Reviewer. Dieser sanfte Reminder eliminiert „vergessene" Reviews.
Die Time-to-Merge-Metrik ist noch kritischer. Die Zeit vom Öffnen der PR bis zum Merge in den Main-Branch — beispielsweise sollte ein Backend-Change 24 Stunden nicht überschreiten. Frontend-Changes haben ein 48-Stunden-Fenster. Warum dieser Unterschied? Backend-Merges erfordern meist weniger visuelle Genehmigung und können hinter Feature-Flags deployed werden. Frontend braucht Design-QA und Cross-Device-Tests, die Zeit kosten.
Metrik-Dashboard: Linear-Integration
Wir integrieren Linear mit GitHub und verknüpfen automatisch jede PR mit einem Linear-Ticket. Der Ticket-Status wird nach dem PR-Lebenszyklus aktualisiert. Am Sprint-Ende schauen wir auf eine Zahl: durchschnittliche Time-to-Merge. Überschreitet das Team-Average 36 Stunden, gibt es etwas zu besprechen in der Retrospektive — meist ist es entweder PR-Größe oder Reviewer-Last.
PR-Größe: Die 400-Zeilen-Regel
Große PRs können nicht ordnungsgemäß reviewed werden. Das ist der häufigste Konsens in der Branche, wird aber selten zu einer messbaren Regel. Der Roibase-Standard: maximal 400 Zeilen Änderung (Summe von Hinzufügungen und Löschungen). Woher kommt diese Zahl? Sie ist die Menge an Zeilen, die ein Reviewer in 30 Minuten konzentrierter Review sinnvoll im Kopf behalten kann.
Um diese Regel zu erzwingen, nutzen wir eine GitHub-Branch-Protection-Rule: PRs über 400 Zeilen erhalten automatisch das Label „needs-split" und können nicht gemergt werden. Es gibt Ausnahmen — etwa Dependency-Updates oder Migration-Scripts. Aber auch die erfordern ein Manual-Override und einen GitHub-Kommentar mit Begründung.
Wie werden große Refactorings gemacht? Mit gestapelten PRs. Erste PR: Interface-Änderung, zweite PR: Implementation, dritte PR: Old-Code-Removal. Jede unter 400 Zeilen, jede unabhängig reviewbar. Dauert das länger? Ja. Steigt das Merge-Conflict-Risiko? Ein bisschen. Aber die Review-Qualität verbessert sich exponentiell — der Reviewer hat die mentale Kapazität, jede Änderung durchzudenken.
# GitHub Actions — PR-Größen-Check
name: PR Size Check
on: pull_request
jobs:
size_check:
runs-on: ubuntu-latest
steps:
- name: Check PR size
run: |
ADDITIONS=$(jq '.pull_request.additions' "$GITHUB_EVENT_PATH")
DELETIONS=$(jq '.pull_request.deletions' "$GITHUB_EVENT_PATH")
TOTAL=$((ADDITIONS + DELETIONS))
if [ $TOTAL -gt 400 ]; then
echo "PR too large: $TOTAL lines"
gh pr edit --add-label needs-split
exit 1
fi
Comment Density: Die Nitpick-Grenze
Nicht alle Kommentare haben gleiches Gewicht. Zwischen „Das könnte refaktoriert werden" und „Das verursacht einen Null-Pointer-Exception" liegt eine Kritikalitätskluft. Das Roibase-Review-Template macht Comment-Kategorien verbindlich:
| Kategorie | Label | Beispiel |
|---|---|---|
| Blocker | 🔴 BLOCKER | Security-Lücke, Runtime-Crash |
| Major | 🟠 MAJOR | Performance-Regression, Logik-Fehler |
| Minor | 🟡 MINOR | Naming-Convention, Test-Coverage |
| Nitpick | 🔵 NITPICK | Geschmacksfrage, subjektiv |
Regel: Nitpick-Anteil nicht über 30 %. Hat eine PR 10 Kommentare, dürfen höchstens 3 Nitpicks sein, der Rest muss Blocker/Major/Minor sein. Warum? Weil Nitpick-schwere Reviews die Author-Motivation senken und den Reviewer als „unnötig kritisch" erscheinen lassen.
Die Comment-Density-Metrik ist: durchschnittliche Kommentare pro PR. Bei Roibase liegt diese Zahl zwischen 3–5. Über 10 Kommentare deuten meist darauf hin, dass die PR gesplittet werden sollte. Null Kommentare sind ein Zeichen für Rubber-Stamp-Review — auch unerwünscht.
Template-Nutzung
Jeder Reviewer beginnt mit dem GitHub-PR-Template:
## Review-Checkliste
- [ ] Ist die Code-Logik korrekt?
- [ ] Ist die Test-Coverage über 80 %?
- [ ] Gibt es Breaking Changes? (CHANGELOG aktualisiert?)
- [ ] Wurde Performance-Impact gemessen? (benchmarks/)
## Kommentare
**🔴 BLOCKER:**
-
**🟠 MAJOR:**
-
**🟡 MINOR:**
-
**🔵 NITPICK:**
-
Dieses Template erfüllt zwei Zwecke: Der Reviewer wird zur Kategorisierung gezwungen, der Author sieht sofort, welche Kommentare kritisch sind.
Asynchrone Reviews: Die Sync-Meeting-Falle
Code-Review sollte nicht in synchronen Meetings stattfinden. Das Konzept einer „Review-Call" existiert bei Roibase nicht — alle Reviews sind asynchron auf GitHub. Warum? Das Team arbeitet in 3 verschiedenen Zeitzonen; Deep-Work-Blöcke sind kritisch zu schützen.
Asynchrone Review-Disziplin funktioniert so: Der Reviewer schaut sich die PR während seines eigenen Deep-Focus-Fensters an (meist 09:00–12:00 Uhr). Er schreibt Kommentare, gibt Approve oder fordert Changes an. Der Author erhält die Benachrichtigung nach seiner eigenen Planung, macht Änderungen und fordert Re-Review an. Dieser Zyklus wiederholt sich durchschnittlich 2–3 Mal.
Ausnahme: Review-Deadlock — wenn Author und Reviewer nach 3 Hin-und-Her-Runden nicht einer Meinung sind, gibt es dann ein 15-Minuten-Sync-Call. Das passiert aber nur 5–6 Mal pro Jahr, im absoluten Ausnahmefall. Roibases Branding-Prozess spiegelt auch diese asynchron-erste Arbeitskultur wider — Documentation-first, Meeting-last.
Ownership vs. Gatekeeping
Code-Review soll Qualität sichern, nicht als Gatekeeping fungieren. Bei Roibase braucht jede PR mindestens 1, maximal 2 Approvals. Warum 2 als Obergrenze? Weil der Zeitaufwand für 3+ Approvals den Code-Quality-Gewinn überwiegt.
Die Reviewer-Auswahl ist nicht automatisch — der Author wählt selbst. Regel: Mindestens einer muss ein Code Owner sein (aus der CODEOWNERS-Datei), der andere kann jeder beliebige sein. Dieser Ansatz hält das Ownership beim Author. Die Frage „Wer muss approven?" liegt in der Verantwortung des Authors, nicht des Team Leads.
Die CODEOWNERS-Datei sieht so aus:
# Backend
/backend/ @backend-team
/api/ @backend-team
# Frontend
/web/ @frontend-team
/mobile/ @mobile-team
# Infrastruktur
/terraform/ @devops-team
/.github/ @devops-team
Jede Dateiänderung muss von jemandem aus dem entsprechenden Team reviewed werden — aber der Author wählt die Person.
Retrospektive: Review-Metriken
Am Ende jedes Sprints (alle 2 Wochen) schauen wir uns Review-Metriken an. Linear-Dashboard zeigt:
- Durchschnittliche Time-to-Merge (Ziel: 36 Stunden)
- PR-Size-Verteilung (Ziel: 90 % unter 400 Zeilen)
- Comment Density (Ziel: 3–5 pro PR)
- Nitpick-Anteil (Ziel: <30 %)
- Review-Bottleneck (Wer wartet am längsten?)
Diese Zahlen werden in der Retrospektive besprochen, aber ohne persönliche Anschuldigungen. Statt „Alis Reviews sind langsam" fragen wir: „Backend-PRs warten durchschnittlich 48 Stunden — sollten wir den Reviewer-Pool vergrößern?"
Code-Review-Kultur von persönlichen Urteilen zu systemischer Disziplin zu verschieben ist nicht schwer — aber es braucht messbare Regeln. Time-to-Review-SLA, 400-Zeilen-Regel, Comment-Kategorien, asynchron-first Ansatz — diese konkreten Tools haben uns bei Roibase geholfen, über 8 Jahre Wachstum Qualität zu bewahren. Falls euer Review-Prozess noch „intuitiv" und „fallabhängig" läuft: setzt Zahlen fest, macht ihn systemisch. Die Qualität steigt, Konflikte sinken.