Code Review — Wesen, Regeln und Durchführung von Reviews im Team

Was ist Code Review?

Code Review ist der Prozess der Überprüfung des Quellcodes durch einen oder mehrere Entwickler, bevor er in den Hauptzweig des Projekts integriert wird. Ziel des Reviews ist nicht nur das Auffinden von Fehlern, sondern auch die Verbesserung der Architektur, die Sicherstellung der Einhaltung von Teamstandards und die Verbreitung von Wissen. Im Gegensatz zur automatischen Analyse (Linter) wird das Code-Review von einem Menschen durchgeführt und bewertet Lesbarkeit, Logik und Architekturentscheidungen.

Laut Google Engineering Practices, 2024 hat Code Review zwei gleich wichtige Ziele: Schutz der Codebasis vor Fehlern und Schulung der Entwickler durch Feedback. In mobilen Projekten umfasst das Review zwingend die Prüfung von Frameworks (UIKit, SwiftUI, Jetpack Compose), Speicherverwaltung und Netzwerkanfragen.

Code Review wird in GitLab und GitHub über Merge Request bzw. Pull Request organisiert. Jeder MR/PR enthält einen Diff, Zeilenkommentare, Diskussionen und Prüfstatus. Laut Microsoft Research (2023) veröffentlichen Teams, die regelmäßig Reviews durchführen, 40% weniger kritische Fehler in der Produktion.

Geschichte von Code Review: Von formalen Inspektionen zu asynchronen PRs

Die ersten formalen Code Reviews erschienen in den 1970er Jahren bei IBM als „strukturierte Inspektionen“ mit schrittweisen Checklisten und Protokollen. In den 2000er Jahren, mit der Verbreitung von Git und verteilten Teams, entwickelte sich das Review zu einem asynchronen Format über Pull Request. GitHub (2008) machte PR zum Mainstream. Modernes Code Review ist ein informeller, asynchroner Prozess, der sich auf Geschwindigkeit und Lernen konzentriert, nicht auf Bürokratie.

Arten von Code Review: formelle und informelle Ansätze

Code Review wird je nach Prozess und Beteiligung in vier Haupttypen eingeteilt. Formal (asynchrones Review) — Prüfung über MR/PR ohne synchrone Kommunikation, am häufigsten in verteilten Teams. Informell — Quick CR, wenn ein Entwickler zu einem anderen geht und bittet, für 5 Minuten auf den Code zu schauen.

Laut Microsoft Research, 2023 bedeutet Paarprogrammierung (Pair Programming), dass zwei Entwickler an einem Bildschirm arbeiten, jede Zeile Code wird in Echtzeit mit sofortigem Review geschrieben. Over-the-Shoulder — ein Entwickler schaut auf den Bildschirm eines anderen und kommentiert den Code ohne formellen Prozess. Walkthrough — der Code-Autor führt eine Gruppe von Entwicklern durch die Änderungen und erklärt jede Entscheidung.

Code-Review-Checkliste: Was im Code zu prüfen ist

Die Code-Review-Checkliste hilft dem Prüfer, keine kritisch wichtigen Aspekte zu übersehen. Die erste Kategorie — Korrektheit und Architektur: Entspricht die Lösung der Aufgabe, gibt es unnötige Komplexität, wurden die Muster richtig gewählt (MVP, MVVM, Clean Architecture)? Die zweite Kategorie — Stil und Formatierung: Folgt der Code dem Team-Codestil (Kotlin Code Style, Swift Style Guide)?

Laut Thoughtbot Code Review Guide, 2024, der dritte Block — Tests: Sind Unit-Tests geschrieben, decken sie Grenzfälle ab, bestehen die vorhandenen Tests? Viertens — Sicherheit: Gibt es keine hartcodierten Tokens, API-Schlüssel, SQL-Injection, Speicherlecks? Fünftens — Leistung: Werden Coroutinen/RxJava korrekt verwendet, wird der UI-Thread nicht blockiert, gibt es keine übermäßigen Allokationen?

• Logik — Korrektheit des Algorithmus, Behandlung von Grenzfällen und Fehlern
• Architektur — Einhaltung von Clean Architecture, MVVM, Trennung der Verantwortlichkeiten
• Codestil — Benennung, Formatierung, Konsistenz mit dem Projekt
• Tests — Vorhandensein von Unit-Tests, deren Vollständigkeit und grüner Status

Wie man Code Review durchführt: Regeln für den Prüfer

Code Review erfordert vom Prüfer ein Gleichgewicht zwischen Gründlichkeit und Geschwindigkeit. Die Hauptregel ist, Code in kleinen Portionen zu prüfen. Optimale Menge — 200–400 Zeilen Änderungen pro Sitzung. Laut Google Research (2022) verliert das Review von mehr als 500 Zeilen an Effektivität: Die Anzahl der übersehenen Fehler steigt linear mit dem Änderungsvolumen. Die zweite Regel — beginnen Sie mit der Architektur, dann Logik, dann Details.

Laut SmartBear, 2025 sollten Kommentare spezifisch sein: nicht „das ist schlecht“, sondern „diese Methode verstößt gegen SRP — extrahieren Sie die Validierungslogik in eine separate Klasse“. Jeder Kommentar ist ein Verbesserungsvorschlag, keine Kritik. Wenn der Code korrekt ist, aber der Stil nicht den Vorlieben des Prüfers entspricht — lassen Sie es ohne Kommentar. Der Prüfer sollte eine korrekte Lösung genehmigen, auch wenn er sie selbst anders geschrieben hätte.

Wie man Code Review annimmt: Tipps für den Autor

Code Review anzunehmen ist eine nicht weniger wichtige Fähigkeit als das Prüfen von Code. Der Autor sollte offen für Kommentare sein und sie als Möglichkeit zur Verbesserung der Lösung betrachten. Die erste Regel — nehmen Sie Kommentare nicht als persönliche Kritik. Code Review prüft den Code, nicht den Entwickler. Zweitens — wenn ein Kommentar unklar ist, fragen Sie nach Klarstellung, anstatt sofort zu korrigieren.

Laut LeadDev, 2024 muss der Autor vor dem Einreichen zum Review seinen eigenen Code prüfen: Tests ausführen, die Checkliste durchgehen, sicherstellen, dass es keine Debug-Logs oder auskommentierten Code gibt. Der MR/PR sollte eine klare Beschreibung mit Kontext der Änderungen enthalten. Je besser die Beschreibung, desto schneller und produktiver wird das Review sein.

Psychologische Sicherheit bei Code Review

Ein wichtiger Aspekt von Code Review ist die psychologische Sicherheit im Team. Wenn ein Entwickler Angst vor harscher Kritik oder Spott hat, wird er Probleme verstecken, anstatt sie zu diskutieren. Google Project Aristotle (2017) zeigte: Teams mit hoher psychologischer Sicherheit sind 25% produktiver. Regeln: Kritisiere den Code, nicht den Autor; stelle Fragen statt Anschuldigungen; danke für gute Lösungen.

Wichtige Regel für den Autor — überstürzen Sie sich nicht, Kommentare zu schließen. Wenn der Prüfer Änderungen angefordert hat, müssen diese umgesetzt werden, nicht nur mit „ok“ antworten und ohne Korrektur lassen. Nach Durchführung der Korrekturen — erneut Review anfordern. GitLab und GitHub unterstützen Re-request Review zur Benachrichtigung des Prüfers.

Automatisierung von Code Review: Linter und statische Analyse

Die Automatisierung von Code Review reduziert die Belastung der Entwickler, indem sie die Prüfung formaler Regeln eliminiert. Linter (ktlint, SwiftLint, ESLint) prüfen Codestil, Formatierung und grundlegende Fehler. Statische Analysatoren (Detekt, SonarQube, Infer) finden potenzielle Fehler, Speicherlecks und Sicherheitsprobleme, bevor der Code zur menschlichen Prüfung gelangt.

Laut detekt Documentation, 2024 werden in CI/CD-Pipelines Linter und Analysatoren automatisch beim Erstellen eines MR/PR ausgeführt. Wenn die Prüfung fehlschlägt, wird der MR durch den Merge-Button blockiert. Dies stellt sicher, dass Code, der zur menschlichen Prüfung gelangt, bereits grundlegende Checks bestanden hat. Der Prüfer konzentriert sich auf Architektur, Logik und Lesbarkeit, nicht auf Leerzeichen und Einrückungen.

// Beispiel für eine detekt-Konfiguration für ein Android-Projekt
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Tools für Code Review in mobilen Projekten

Code-Review-Tools in der mobilen Entwicklung unterteilen sich in plattformbasierte (GitLab, GitHub, Bitbucket) und spezialisierte (Gerrit, Reviewable, Crucible). GitLab und GitHub bieten integrierte Funktionalität: Diff-Vergleich, Zeilenkommentare, Threads, Approve/Changes Requested-Status, CI/CD-Integration. Die Wahl des Tools hängt von der Teamgröße und der Review-Richtlinie ab.

Laut GitLab Docs, 2025 bietet Gerrit für große Teams (50+ Entwickler) eine strengere Kontrolle: obligatorische CI-Verifikation vor dem Merge, gewichtete Genehmigungen (Verified + Code-Review) und detaillierte Zugriffsrechte. Für kleine und mittlere Teams sind GitLab und GitHub die optimale Wahl: Die Konfiguration von Required Approvals, Code Owners und Merge Checks dauert Minuten.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, integriertes CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests für Mercurial/Git, Approvals mit Diff-Kommentaren
• Gerrit — strenger Verifikationsprozess, gewichtete Bewertungen, Jenkins-Integration

Häufige Fehler bei Code Review

Fehler bei Code Review verringern dessen Effektivität und demotivieren das Team. Erster — Prüfung eines zu großen Änderungsvolumens auf einmal. Wenn ein MR mehr als 2000 Zeilen enthält, übersieht der Prüfer bis zu 70% der Fehler. Zweiter — subjektive Kommentare, die nicht auf Codestil oder Architektur basieren. Kommentare wie „ich hätte es anders geschrieben“ ohne Begründung bringen keinen Nutzen.

Laut Google Engineering Practices, 2024, dritter Fehler — Tests ignorieren. Wenn ein MR keine Tests für die neue Funktionalität enthält, sollte der Prüfer sie anfordern, nicht mit „später“ genehmigen. Vierter — Prüfung am Ende des Tages oder Sprints, wenn die Aufmerksamkeit nachlässt. Die beste Zeit für Reviews ist die erste Tageshälfte, mit 30–60 Minuten gewidmeter Zeit ohne Aufgabenwechsel.

Reviewsicherheit — der fünfte häufige Fehler: Prüfer prüfen nicht, ob der Code hartcodierte Geheimnisse, unsichere WebViews mit JavaScript oder verwundbare Bibliotheken enthält. In mobilen Projekten ist dies kritisch: Ein API-Schlüsselleck kann das gesamte Backend gefährden.

Code Review in verteilten Teams

Für remote Teams ist Code Review der primäre Kanal für Wissensaustausch. Ein asynchrones Format über MR mit klaren Fristen wird empfohlen: maximal 24 Stunden für das Review. Verwenden Sie Bildschirmaufnahmen (Loom) für komplexe Architekturdiskussionen. In verteilten Teams ist die schriftliche Dokumentation von Entscheidungen in MR-Kommentaren besonders wichtig, damit der Kontext bei Zeitzonenwechseln nicht verloren geht.