Warum wir Code Reviews hassen (und warum das falsch ist)
Der Code ist geschrieben, die Unit-Tests sind grün, und du bist stolz auf deine Lösung. Du erstellst den Pull Request (PR), schiebst ihn in den Team-Channel und wendest dich der nächsten Aufgabe zu.
Dann passiert… erst mal nichts. Einen Tag später. Immer noch nichts. Zwei Tage später ploppt endlich eine Benachrichtigung auf. Ein Kommentar! Voller Vorfreude klickst du drauf, in der Hoffnung auf ein “LGTM” (Looks Good To Me) oder eine spannende Architektur-Diskussion.
Stattdessen liest du: “Bitte hier eine Leerzeile einfügen” oder “Warum hast du nicht die map() Funktion genutzt?”.
Frustrierend, oder?
Szenarien wie dieses sind der Grund, warum Code Reviews in vielen Teams als notwendiges Übel, als Bremse oder sogar als toxisches “Gatekeeping” empfunden werden. Es fühlt sich an wie eine Prüfung, bei der der Reviewer versucht, den Autor bei Fehlern zu ertappen, um seine eigene Kompetenz zu beweisen.
Das ist eine massive Verschwendung von Talent und Zeit.
Ein Code Review sollte niemals eine Prüfung sein. Es ist das mächtigste Werkzeug, das wir haben, um Wissensinseln aufzubrechen (Knowledge Sharing), Shared Ownership zu etablieren (der Code gehört uns allen, nicht nur dem Autor) und gemeinsam bessere Ingenieure zu werden.
Wenn dein Team Reviews als Schmerz empfindet, dann läuft etwas im Prozess falsch – nicht mit den Leuten. In diesem Artikel zeige ich dir, wie wir den Prozess von “Erbsenzählerei” zu echtem Mentoring drehen. Und das beginnt paradoxerweise damit, dass wir den Menschen erst mal so weit wie möglich aus dem Prozess entfernen.
Lass Roboter die Drecksarbeit machen (Automation)
Bevor wir darüber sprechen, wie wir Feedback geben, müssen wir klären, worüber wir überhaupt sprechen.
Hier ist eine goldene Regel für jeden Senior Software Engineer: Diskutiere niemals in einem Code Review über Dinge, die ein Computer automatisch finden kann.
Es gibt nichts Unproduktiveres als einen hochbezahlten Engineer, der einen anderen Engineer darauf hinweist, dass am Zeilenende ein Semikolon fehlt oder die Einrückung nicht stimmt. Das ist Verschwendung von kognitiver Kapazität.
Dein Review-Prozess beginnt nicht, wenn du den PR öffnest. Er beginnt in der CI-Pipeline (Continuous Integration).
Bevor ein Mensch auch nur einen Blick auf den Code wirft, muss die Pipeline grün sein. Und diese Pipeline sollte beinhalten:
- Formatter: Tools wie Prettier (JS/TS), Black (Python) oder GoFmt beenden jede Diskussion über Style. Der Code sieht immer gleich aus. Punkt.
- Linter: ESLint, Checkstyle oder SonarQube finden ungenutzte Variablen, tote Code-Pfade und potenzielle Bugs.
- Tests: Unit- und Integration-Tests müssen bestehen.
Wenn du in einem Review schreibst: “Bitte entferne den ungenutzten Import hier”, dann ist das eigentlich ein Fehler im Prozess. Warum hat die Pipeline den Build nicht abgebrochen?
Indem wir diese “Hausmeister-Tätigkeiten” an Tools delegieren, schaffen wir Platz für das Wesentliche: Architektur, Logik und Verständlichkeit. Ein Reviewer sollte sich nicht wie ein Rechtschreibprüfer fühlen, sondern wie ein Co-Architekt.
Für den Reviewer – Fragen statt Befehle
Sobald die Tools durchgelaufen sind, kommst du ins Spiel. Jetzt geht es um Psychologie.
Textkommunikation ist schwierig. Ihr fehlen Mimik und Tonfall. Ein schnell getipptes “Das ist falsch” kann beim Empfänger (der vielleicht Stunden in die Lösung investiert hat) sofortigen Widerstand auslösen.
Ein Senior Software Engineer weiß: Das Ziel ist nicht, Recht zu haben, sondern die beste Lösung zu finden. Und oft hat der Autor einen Grund für seine Implementierung, den du einfach noch nicht siehst.
Daher lautet die wichtigste Regel: Stelle Fragen, statt Befehle zu bellen.
Schau dir den Unterschied an:
❌ Schlecht (Befehl): “Benenn diese Variable in customerList um.”
Wirkung: Autoritär. Es impliziert, dass der Autor einen Fehler gemacht hat.
✅ Gut (Frage/Vorschlag): “Die Variable list ist hier etwas generisch. Was hältst du von customerList, um den Kontext klarer zu machen?”
Wirkung: Kooperativ. Es lädt zur Diskussion ein und lässt dem Autor Raum, seine Entscheidung zu erklären (oder den Vorschlag anzunehmen).
Blocking vs. Non-Blocking (Nitpicking)
Ein weiteres mächtiges Werkzeug ist das explizite Kennzeichnen deiner Kommentare. Nicht jeder Kommentar ist gleich wichtig.
Unterscheide klar zwischen:
- Blockern (Must-Change): Hier ist wirklich etwas kaputt. Ein Bug, eine Sicherheitslücke oder ein grober Verstoß gegen die Architektur. Ohne diesen Fix darf der Code nicht gemerged werden.
- Beispiel: “Hier fehlt eine Prüfung auf
null, das wird crashen.”
- Nitpicks / Optional (Nice-to-have): Das ist deine persönliche Präferenz oder ein kleiner Vorschlag, der den Code “schöner” macht, aber funktional nicht kritisch ist.
- Kennzeichne sie explizit: “
(nitpick)Man könnte das hier auch in einer Zeile schreiben, aber deine Version ist auch okay.”
Indem du Kommentare als “Optional” markierst, nimmst du enorm viel Druck aus dem Kessel. Du zeigst dem Autor: “Ich habe deine Arbeit gelesen und mir Gedanken gemacht, aber ich blockiere dich nicht wegen Kleinigkeiten.”
Das schafft Psychological Safety. Dein Team wird aufhören, Angst vor deinen Reviews zu haben, und anfangen, sie wertzuschätzen.
Worauf wir wirklich achten sollten (Die Checkliste)
Wenn der Linter zufrieden ist, beginnt deine eigentliche Arbeit. Aber wo schaust du hin? Es ist leicht, sich in Details zu verlieren. Deshalb hilft es, eine mentale (oder physische) Checkliste zu haben, die sich auf Wartbarkeit und Architektur fokussiert.
Hier ist die Hierarchie dessen, was in einem Review wirklich zählt:
1. Verständlichkeit (Readability)
Code wird viel öfter gelesen als geschrieben. Deine wichtigste Frage als Reviewer ist daher nicht “Funktioniert das?”, sondern “Verstehe ich das in 30 Sekunden?”.
- Naming: Sagen die Variablennamen was sie sind, oder muss ich raten? (
datavs.pendingOrders). - Komplexität: Wenn eine Methode 50 Zeilen hat und drei verschachtelte
if-Statements, ist der Cognitive Load zu hoch. Schlag vor, sie aufzubrechen. - Kommentare: Erklären Kommentare das Warum (Business-Logik) oder das Wie (was der Code eh schon sagt)? Letzteres ist unnötiges Rauschen.
2. Architektur & Design
Hier schützt du die Struktur eurer Anwendung.
- Separation of Concerns: Macht dieser Service zu viel? Ruft der Controller direkt die Datenbank auf? (Wir erinnern uns an den “Modular Monolith”: Grenzen einhalten!).
- Wiederverwendbarkeit: Wurde hier Code kopiert, den es als Utility-Funktion schon gibt? DRY (Don’t Repeat Yourself) ist wichtig, aber pass auf, dass du nicht in “Premature Optimization” verfällst.
3. Tests als Dokumentation
Tests sind die einzige Dokumentation, die nicht lügen kann.
- Schau dir die Tests vor dem eigentlichen Code an. Verstehst du anhand der Tests, was das Feature tun soll?
- Decken sie auch die “Unhappy Paths” ab? (Was passiert, wenn die API einen 500er wirft?).
- Ein Test, der alles mockt, testet nichts. Achte darauf, dass sinnvolle Szenarien geprüft werden, nicht nur die Code Coverage künstlich hochgetrieben wird.
4. Die “Existenzfrage”
Die beste Zeile Code ist die, die man nicht schreiben muss. Manchmal ist das wertvollste Feedback: “Brauchen wir das wirklich so komplex? Gibt es eine Library, die das schon macht? Oder löst das ein Problem, das wir gar nicht haben?” Ein Senior Software Engineer traut sich zu fragen, ob das Feature überhaupt den gewünschten Business-Value liefert oder ob es einfacher geht.
Für den Autor – Hilf deinen Reviewern (PR-Hygiene)
Es gibt ein ungeschriebenes Gesetz in der Software-Entwicklung:
- 10 Zeilen Code: 10 Kommentare (“Hier fehlt ein Space”, “Variable umbenennen”).
- 500 Zeilen Code: “LGTM” (Looks Good To Me).
Warum ist das so? Weil bei 500 Zeilen der Kopf des Reviewers abschaltet. Die kognitive Last ist zu hoch. Große PRs führen paradoxerweise zu schlechteren Reviews und mehr Bugs, die durchrutschen.
Als Autor ist es deine Verantwortung, das Review so schmerzfrei wie möglich zu gestalten. Hier ist deine Checkliste für “gute PR-Hygiene”:
1. Context is King
Ein leerer PR-Body ist respektlos gegenüber der Zeit deiner Kollegen. Schreibe immer eine Beschreibung. Beantworte zwei Fragen:
- WAS macht dieser PR? (Grobe Zusammenfassung).
- WARUM machen wir das? (Link zum Jira-Ticket, Business-Kontext). Wenn es Frontend-Änderungen sind: Füge Screenshots oder ein GIF hinzu. Ein Bild erklärt Layout-Änderungen schneller als 50 Zeilen CSS.
2. Keep it small (Atomare PRs)
Versuche, PRs so klein wie möglich zu halten. Ein Feature ist zu groß? Brich es herunter:
- PR 1: Datenbank-Schema Update.
- PR 2: Backend-Service Logik.
- PR 3: Frontend-Integration. Das ist schneller zu reviewen, schneller zu mergen und im Fehlerfall leichter zu revertieren.
3. Das “Self-Review”
Das ist der ultimative Pro-Tipp.
Bevor du jemanden als Reviewer hinzufügst, geh die Diff-Ansicht deines eigenen PRs durch. Lies deinen Code so, als wärst du ein Fremder.
Du wirst überrascht sein, wie viele console.log, auskommentierte Code-Leichen oder offensichtliche Tippfehler du selbst findest.
Jeden Fehler, den du selbst korrigierst, muss dein Kollege nicht finden. Das spart Zeit und lässt dich kompetenter wirken.
Fazit – Ein Kultur-Wandel
Am Ende des Tages ist ein Code Review ein Spiegelbild eurer Engineering-Kultur.
Wenn Reviews wehtun, ist das ein Zeichen von fehlendem Vertrauen oder ineffizienten Prozessen. Wenn Reviews hingegen Spaß machen (ja, das ist möglich!), dann habt ihr eine Umgebung geschaffen, in der jeder lernen und wachsen will.
Die Umstellung von “Nitpicking” zu “Mentoring” passiert nicht über Nacht. Aber du kannst heute damit anfangen:
- Richte einen Linter ein, der die Diskussion über Syntax beendet.
- Formuliere deinen nächsten Kommentar als Frage, nicht als Befehl.
- Erstelle deinen nächsten PR so, dass er für den Reviewer ein Geschenk ist, keine Last.
Gute Code Reviews machen den Code besser. Großartige Code Reviews machen den Software Engineer besser.