Code Reviews

Ziel dieses Artikels

Dieser Artikel beschreibt, wie Code Reviews bei uns durchgeführt werden, welche Ziele sie haben und welche Kriterien dabei gelten.

⚠️ Dieser Prozess ist nicht final und kann sich jederzeit ändern oder weiterentwickeln.

Grundprinzipien

Code Reviews erfolgen pro Ticket, nicht gesammelt über mehrere Tickets hinweg
Reviews sollen schnell und effizient sein (typischerweise 3–10 Minuten)
Wenn Code deutlich länger braucht, um verstanden zu werden, ist das bereits ein Hinweis auf ein Problem
Es gibt Ausnahmen (z. B. komplexe Algorithmen oder kritische Logik), bei denen mehr Zeit notwendig ist

Ziele von Code Reviews

Der Fokus liegt nicht auf kleinsten Details, sondern auf dem Gesamtbild:

Architektur
Systemdesign
Verständlichkeit
Qualitätssicherung auf hoher Ebene

Ein Code Review ist kein vollständiges Debugging oder Micro-Optimizing, sondern eine schnelle Validierung der Lösung.

Ablauf eines Code Reviews

1. Vorbereitung durch den Autor

Bevor du einen Merge Request erstellst:

Stelle sicher, dass dein Code funktioniert
Führe relevante Tests aus
Halte den Scope möglichst klein (ein Ticket = ein Review)
Beschreibe klar:
- Was wurde gemacht?
- Warum wurde es gemacht?

2. Durchführung des Reviews

Der Reviewer versucht primär:

die Struktur des Codes zu verstehen
die Intention nachzuvollziehen
die Lösung im Kontext des Systems einzuordnen

Wichtiger als jedes Detail ist die Frage:
„Ergibt das insgesamt Sinn?“

3. Bewertungskriterien

Diskussionen im Review sollten sich vor allem auf folgende Aspekte konzentrieren:

Sicherheit
→ Gibt es potenzielle Risiken oder Angriffsflächen?
Robustheit
→ Ist der Code stabil gegenüber Fehlern und Edge Cases?
Performance
→ Gibt es offensichtliche Ineffizienzen?
Einfachheit
→ Ist die Lösung unnötig kompliziert?

4. Ergebnis

Ein Review kann fehlschlagen, wenn z. B.:

der Code schwer verständlich ist
die Struktur unklar ist
zentrale Designentscheidungen nicht nachvollziehbar sind

In diesem Fall sollte der Code vereinfacht oder besser dokumentiert werden.

Ausnahmen

Es gibt Fälle, in denen ein Review bewusst mehr Zeit benötigt:

komplexe Algorithmen
kritische Business-Logik
sicherheitsrelevante Komponenten

In diesen Fällen ist ein tieferes Verständnis ausdrücklich gewünscht.

Präventive Code Reviews

Neben klassischen Reviews nach der Implementierung sind auch präventive Code Reviews sinnvoll:

Wenn du dir bei einem Ansatz oder Design unsicher bist:

hole früh Feedback ein
bespreche die Idee vor der Umsetzung

Das spart Zeit und verhindert unnötige Nacharbeit.

Beispiele

Schlechtes Beispiel

Große Änderung über mehrere Tickets hinweg
Kaum Beschreibung im Merge Request
Verschachtelter, schwer lesbarer Code
Reviewer braucht 10+ Minuten zum Verstehen

→ Ergebnis: Review schlägt fehl

Gutes Beispiel

Klar abgegrenztes Ticket
Verständliche Struktur
Gute Benennung von Variablen und Funktionen
Kurze, klare Beschreibung im Merge Request

→ Review dauert wenige Minuten und kann schnell freigegeben werden

Grenzfall

Komplexer Algorithmus
Review dauert länger als 10 Minuten
Zusätzliche Erklärung oder Pair-Review notwendig

→ akzeptabel, wenn die Komplexität gerechtfertigt ist

Best Practices

Für Autoren

Halte Code einfach und verständlich
Vermeide unnötige Komplexität
Erkläre nicht offensichtliche Entscheidungen
Schneide Änderungen sauber pro Ticket

Für Reviewer

Fokussiere dich auf das große Ganze
Vermeide Micromanagement
Stelle Fragen statt Annahmen zu treffen
Gib klares, begründetes Feedback

Fazit

Code Reviews sollen schnell, fokussiert und sinnvoll sein.
Das Ziel ist nicht Perfektion im Detail, sondern ein solides, verständliches und gut integriertes Gesamtsystem.

Gute Reviews verbessern nicht nur den Code, sondern auch das gemeinsame Verständnis im Team.