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

• EsAusnahmen gibtgelten Ausnahmenfür komplexe oder kritische Logik (z. B. komplexe Algorithmen oder kritische Logik), bei denen mehr Zeit notwendig istAlgorithmen)

---

Ziele von Code Reviews

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

• 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

Vorbereitung

Vor dem Erstellen eines Code Reviews

1. Vorbereitung durch den Autor

Bevor du einen Merge Request erstellst:Commits:

• Stelle sicher,Sicherstellen, dass deinder Code funktioniert

• Führe relevanteRelevante Tests ausausführen

• HalteÄnderungen denklar Scopeund möglichstnachvollziehbar kleinhalten (ein Ticket =pro ein Review)Änderung)

• BeschreibeKurz klar:beschreiben:

  • Was wurde gemacht?geändert?

  • Warum wurde es gemacht?geändert?

---

2. Durchführung des ReviewsReview

DerIm ReviewerReview versuchtwird primär:vor allem geprüft:

• Ist die Struktur des Codes zu verstehenverständlich?

• dieIst Intention nachzuvollziehen

• die Lösung im KontextGesamtsystem des Systems einzuordnensinnvoll?

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

---

3. Bewertungskriterien

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

• 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 kanngilt fehlschlagen,als wennnicht z.bestanden, B.:wenn:

• der Code schwer verständlich ist

• die Struktur unklar ist

• zentrale Designentscheidungen nicht nachvollziehbar sind

In diesem Fall solltesind der Code vereinfachtVereinfachung oder besserbessere dokumentiertStruktur 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.erforderlich.

---

Präventive Code Reviews

NebenBei klassischenUnsicherheiten Reviews nach der Implementierung sind auch präventive Code Reviews sinnvoll:

Wenn du dir bei einembezüglich Ansatz oder Design unsichersollte bist:

• hole frühfrühzeitig Feedback ein

  eingeholt
werden,
• bevor

  bespreche die Idee vormit der Umsetzung

  Implementierung
begonnen

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 istwird.

---

Best Practices

Für Autoren

• Halte Code einfach und verständlich halten

• Vermeide unnötigeUnnötige Komplexität vermeiden

• Erkläre nicht offensichtliche Entscheidungen

• Schneide Änderungen sauberklar pro Ticket trennen

---

Für Reviewer

• Fokussiere dichFokus auf dasArchitektur großeund GanzeGesamtbild

• VermeideKeine MicromanagementDetaildiskussionen ohne Mehrwert

• StelleFeedback Fragenklar stattund Annahmenbegründet zu treffen

• Gib klares, begründetes Feedbackformulieren

---

Fazit

Code Reviews sollen schnell, fokussiert und sinnvoll sein.
Das Ziel ist nicht Perfektion im Detail, sondernsind ein solides,schneller, verständlichesfokussierter Prozess zur Sicherstellung von verständlichem und gut integriertesintegriertem Gesamtsystem.Code.

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