Code Review Grundlagen

Code Reviews sind einer der effektivsten Wege, Softwarequalität zu sichern, Wissen im Team zu teilen und Fehler vor der Produktion zu finden.

In a Nutshell

Code Review ist der Prozess, bei dem andere Entwickler den Code vor dem Merge prüfen. Gute Reviews konzentrieren sich auf Logik, Lesbarkeit, Sicherheit und Architektur — nicht auf Stil oder persönliche Vorlieben.

Kompakte Fachbeschreibung

Code Review ist eine Qualitätssicherungsmaßnahme, bei der ein oder mehrere Entwickler den Quellcode eines anderen prüfen, bevor er in den Hauptzweig integriert wird. Der Prozess erfolgt typischerweise über Pull Requests (PR) oder Merge Requests (MR) in Versionsverwaltungssystemen wie GitHub, GitLab oder Bitbucket. Code Reviews dienen der Fehlererkennung, Wissensverteilung, Einhaltung von Coding-Standards und der kontinuierlichen Verbesserung der Codequalität.

Warum Code Reviews?

• Fehlerfindung: Studien zeigen, dass Reviews bis zu 60% der Fehler vor der Produktion finden
• Wissenstransfer: Alle im Team lernen vom Code anderer
• Konsistenz: Einheitliche Architektur und Coding-Standards
• Teamkultur: Gemeinsames Verantwortungsbewusstsein
• Onboarding: Neue Entwickler lernen durch das Review von bestehendem Code

Der Code Review Prozess

1. Vorbereitung

# Feature-Branch erstellen
git checkout -b feature/user-authentication

# Änderungen committen
git add .
git commit -m "feat: add JWT authentication"

# Push und Pull Request erstellen
git push origin feature/user-authentication

2. PR-Beschreibung

Eine gute PR-Beschreibung enthält:

• Was wurde geändert?
• Warum wurde es geändert?
• Wie wurde es getestet?
• Screenshots (bei UI-Änderungen)
• Verweise auf Tickets/Issues

## Änderungen
JWT-basierte Authentifizierung hinzugefügt.

## Warum
Sicherheit: Session-basierte Auth ist für mobile Clients ungeeignet.

## Tests
- Unit Tests für Token-Generierung
- Integration Tests für Login-Flow
- Manual Testing mit Postman

## Screenshots
[Login-Screenshot]

## Verweise
Closes #123

3. Review-Checkliste

• Logik: Tut der Code das, was er soll?
• Lesbarkeit: Ist der Code verständlich?
• Sicherheit: Gibt es Sicherheitslücken?
• Performance: Gibt es Performance-Probleme?
• Tests: Sind Tests ausreichend?
• Dokumentation: Ist Änderung dokumentiert?

4. Feedback geben

# Konstruktives Feedback

## Positiv
- Gute Trennung von Auth-Logik und Controller
- Tests sind umfassend

## Verbesserungsvorschläge
- Die Token-Validierung könnte in einen Service ausgelagert werden
- Die Secret-Konstante sollte aus Umgebungsvariablen gelesen werden

## Fragen
- Warum wurde hier JWT statt OAuth2 gewählt?

5. Merge

Nach Änderungen und Approval:

# Rebase auf main
git checkout main
git pull
git checkout feature/user-authentication
git rebase main

# Push und Merge
git push origin feature/user-authentication
# Merge in GitHub UI

Best Practices

Für Reviewer

• Fokus auf das Wesentliche: Priorisiere Logik und Sicherheit über Stil
• Kleine PRs: PRs unter 400 Zeilen sind leichter zu reviewen
• Schnelles Feedback: Review innerhalb von 24 Stunden
• Konstruktiv: Erkläre WARUM, nicht nur WAS
• Positiv: Beginne mit dem, was gut ist

Für Autoren

• Selbst-Review: Review deinen eigenen Code vor dem PR
• Kleine Commits: Logisch zusammengehörige Änderungen
• Klare Beschreibung: Erkläre Kontext und Entscheidungen
• Tests: Füge Tests für neue Funktionalität hinzu
• Reagiere: Antworte auf Feedback zeitnah

Häufige Fehler vermeiden

Fehler	Beschreibung	Lösung
Nitpicking	Fokus auf Formatierung statt Logik	Linter für Stil, Review für Inhalt
Delayed Reviews	Reviews werden nicht ausgeführt	SLA von 24 Stunden einhalten
Approval ohne Review	PR wird ohne Prüfung gemerged	Mindestens ein Reviewer erforderlich
Große PRs	Tausende Zeilen in einem PR	Aufteilen in kleine, logische PRs
Persönlich werden	Feedback als Kritik nehmen	Feedback als Verbesserung sehen

Code Review Tools

Tool	Plattform	Besonderheit
GitHub PR	GitHub	Integriert, weit verbreitet
GitLab MR	GitLab	Integriert, CI/CD-Integration
Bitbucket PR	Bitbucket	Jira-Integration
Phabricator	Self-hosted	Diffusion, Differential
Review Board	Self-hosted	Flexibel, Git-Integration

Prüfungsrelevante Stichpunkte

• Code Review als Qualitätssicherungsmaßnahme vor Merge
• PR/MR als typischer Prozess in Git-Workflows
• Fokus auf Logik, Sicherheit, Architektur — nicht Stil
• Kleine PRs (< 400 Zeilen) sind effektiver
• Konstruktives Feedback: erklären, nicht kritisieren
• Wissenstransfer als wichtiger Nebeneffekt

FAQ

Weiter im Softwarequalität Lernpfad

Der nächste Artikel im Softwarequalität Lernpfad behandelt Code Review Checkliste — eine detaillierte Checkliste für strukturierte Code Reviews.

Quellen

1. https://google.github.io/eng-practices/review/
2. https://github.com/features/pull-requests
3. https://martinfowler.com/articles/peer-review.html

Buchempfehlungen zur Softwarequalität

Wenn Du Dich weiter mit Code Reviews, Teamarbeit und Softwarequalität beschäftigen möchtest, empfehlen wir Dir die folgenden Bücher: