Code-Review-Dojo

Zweck

Ein Code-Review-Dojo bringt das gesamte Team zusammen, um ein Stück Produktionscode kollaborativ zu reviewen. Es gleicht das Team bei Coding-Standards ab und normalisiert das Geben und Empfangen von Code-Feedback.

Auf einen Blick

Ablauf

1. Code auswählen (vor der Session) — Einen aktuellen Pull Request oder Code-Modul wählen.
2. Kontext (5 Min.) — Autor erklärt kurz Zweck und Rahmenbedingungen.
3. Stilles Lesen (10 Min.) — Jeder liest den Code unabhängig und notiert Beobachtungen.
4. Gruppenreview (30 Min.) — Code gemeinsam durchgehen. Beobachtungen teilen: Lesbarkeit, Benennung, Struktur, Fehlerbehandlung, Testbarkeit.
5. Standards vereinbaren (10 Min.) — Neue Coding-Standards oder Muster festhalten.
6. Debrief (5 Min.) — Was haben wir über unser Review-Verhalten gelernt?

Material

• Zu reviewender Code (ausgedruckt oder auf geteiltem Bildschirm)
• Team-Coding-Standards-Dokument (falls vorhanden)
• Beobachtungsvorlage (optional)
• Geteiltes Dokument für vereinbarte Standards

Stolperfallen & häufige Fehler

• Persönlich machen — Den Code reviewen, nicht den Coder.
• Nur nach Bugs suchen — Auch Lesbarkeit, Benennung und Design betrachten.
• Senior-Entwickler dominieren — Juniors zuerst sprechen lassen.

Inklusion & Barrierefreiheit

• Code 24 Stunden vorab teilen.
• Schriftgröße auf dem geteilten Bildschirm ausreichend groß.
• Round-Robin-Format, damit alle beitragen.

Varianten

• Bug-Hunt-Dojo — Absichtlich Bugs einfügen; Team findet sie.
• Refactoring-Dojo — Team refactored den Code live.
• Architektur-Review-Dojo — Fokus auf Systemdesign statt Code-Details.

Wann NICHT einsetzen

• Wenn das Team keine Code-Review-Kultur hat — mit Pair Programming beginnen.
• Wenn der Code zu spezialisiert für die meisten Teammitglieder ist.

Quelle & Weiterlesen

• Atwood, J. (2006). „Code Reviews: Just Do It.“ codinghorror.com
• Bacchelli, A. & Bird, C. (2013). „Expectations, Outcomes, and Challenges of Modern Code Review.“ ICSE.