Code-Review-Kultur und Best Practices für PRs

Code-Reviews dienen nicht als Zugangskontrolle – sie ermöglichen es Teams, gemeinsam zu lernen, Verantwortung zu übertragen und die Qualität hochzuhalten. Eine gute Review-Kultur stärkt das gesamte Team; eine schlechte führt zu Engpässen und Unmut.

1) Halten Sie ihn klein (wenn möglich unter 400 Zeilen). 2) Verfassen Sie eine klare Beschreibung: warum, was und wie getestet wird. 3) Verlinken Sie das Ticket. 4) Fügen Sie bei UI-Änderungen Screenshots oder Videos hinzu. 5) Reviewen Sie Ihren Diff selbst, bevor Sie Reviewer anfordern.

Verwenden Sie dieselben konventionellen Präfixe wie bei Commits: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Viele Teams generieren daraus Changelogs.

Die meisten Teams verwenden eine PR-Vorlage – richten Sie sie im Repository unter .github/pull_request_template.md ein.

Gehen Sie Ihren eigenen Diff Zeile für Zeile durch, bevor Sie Reviewer anfordern. Fügen Sie Kommentare hinzu, die nicht offensichtliche Entscheidungen erklären. Oft entdecken Sie eigene Fehler, bevor jemand anderes es tun muss.

Ein PR mit 2000 Zeilen wird selten gründlich reviewt. Teilen Sie ihn auf in: 1) Refactoring (keine Verhaltensänderung), 2) neues Verhalten, 3) UI-Feinschliff. Jeder Teil lässt sich leichter reviewen und zurücksetzen.

Formulieren Sie Feedback als Fragen, nicht als Anweisungen: „Was halten Sie davon, dies in einen Hook auszulagern?“ ist besser als „Lagern Sie dies aus“. Unterscheiden Sie zwischen zwingend nötigen Änderungen und wünschenswerten Verbesserungen. Verwenden Sie Präfixe: nit:, question:, blocker:.

„Das ist verwirrend“ hilft dem Autor nicht weiter. „Ich musste das dreimal lesen, um den Early Return zu verstehen – könnten wir eine Guard Clause daraus machen?“ gibt ihm eine konkrete Handlungsmöglichkeit.

Geben Sie positives Feedback zu cleveren Lösungen, guter Benennung und hilfreichen Tests. Das ermutigt zu diesen Mustern und mildert das übrige Feedback ab. PRs, die ausschließlich Kritik erhalten, wirken konfrontativ.

Prettier übernimmt die Formatierung. ESLint kümmert sich um den Stil. Verschwenden Sie keine Review-Zeit mit Tabulatoren gegenüber Leerzeichen. Wenn eine Stilregel immer wieder zum Thema wird, bilden Sie sie im Linter ab.

Tests sind ebenfalls Code. Stellen Sie sicher, dass neuer Code Tests hat. Prüfen Sie, ob die Tests tatsächlich das Richtige testen – viele Tests bestehen trotz fehlerhaftem Code, weil sie die falsche Sache prüfen.

Reagieren Sie auf jeden Kommentar – notfalls nur mit einem Daumen-hoch-Emoji. Widersprechen Sie Vorschlägen, mit denen Sie nicht einverstanden sind (Sie haben den Code geschrieben und verfügen möglicherweise über zusätzlichen Kontext). Markieren Sie erledigte Threads als erledigt. Aktualisieren Sie die PR-Beschreibung, wenn sich der Umfang ändert.

Reviewen Sie innerhalb eines Arbeitstags. Veralteten PRs geht der Kontext verloren – der Autor hat inzwischen weitergearbeitet, und der Branch muss rebased werden. Große PRs, die eine Woche liegen bleiben, werden immer zu quälenden Merges.

Mit der Suggestion-Funktion von GitHub kann der Autor eine Änderung mit einem Klick übernehmen. Das ist wesentlich schneller als „Ändern Sie diese Zeile in X“ in einem Fließtext.

Geben Sie frei, wenn: der Code korrekt ist, die Tests bestehen, Sie die Änderung verstehen und sie sicher gemergt werden kann. Mit einer Freigabe übernehmen Sie Mitverantwortung für das Ergebnis. Nicken Sie nichts blind ab – wenn Sie den Code nicht gelesen haben, sagen Sie das.

Autor: kleine, gut beschriebene PRs mit Screenshots und Tests. Zuerst selbst reviewen. Reviewer: konstruktives, auf Fragen basierendes Feedback. Zwischen Blocker und Nit unterscheiden. Gutes anerkennen. Stil überspringen – Tools sollen sich darum kümmern. Innerhalb eines Tages reviewen. Nur freigeben, wenn Sie die Änderung verstehen. PR-Vorlagen standardisieren den Prozess. Reviews sind Zusammenarbeit, keine Zugangskontrolle.