Code ReviewChecklistePull RequestReview ChecklistSoftwarequalität

Code Review Checkliste: Strukturierte Prüfung von Pull Requests

Code Review Checkliste: Logik, Sicherheit, Performance, Tests, Dokumentation und Best Practices für effektive Reviews.

schutzgeist

July 5, 2026

Updated July 5, 2026

3 min read

Code Review Checkliste

Eine strukturierte Checkliste hilft, Code Reviews konsequent und effizient durchzuführen. Dieser Artikel bietet eine umfassende Checkliste für alle Aspekte eines Pull Requests.

In a Nutshell

Code Review Checkliste: Prüfe Logik, Sicherheit, Performance, Tests, Dokumentation und Architektur. Kleine PRs, klare Beschreibungen und konstruktives Feedback sind Schlüssel zum Erfolg.

Kompakte Fachbeschreibung

Code Review Checklisten sind strukturierte Listen von Prüfpunkten, die sicherstellen, dass alle relevanten Aspekte eines Pull Requests systematisch betrachtet werden. Sie helfen Reviewern, konsistente Qualität zu gewährleisten, und Autoren, sich auf die wichtigsten Punkte zu konzentrieren. Eine gute Checkliste deckt funktionale Korrektheit, Sicherheit, Performance, Testabdeckung, Dokumentation und Architektur ab.

Die Checkliste

1. PR-Beschreibung und Kontext

Klare Beschreibung: Was wurde geändert und warum?
Ticket-Verweis: Issue/Task ist verlinkt
Test-Strategie: Wie wurde getestet?
Screenshots: Bei UI-Änderungen vorhanden
Breaking Changes: Sind breaking changes dokumentiert?

2. Logik und Funktionalität

Korrektheit: Tut der Code das, was er soll?
Edge Cases: Grenzfälle und Fehlerfälle behandelt
Fehlerbehandlung: Exceptions werden richtig behandelt
Validierung: Eingaben werden validiert
Ressourcen-Cleanup: Dateien, Verbindungen werden geschlossen

3. Sicherheit

SQL Injection: Parameterisierte Queries verwendet
XSS: Benutzereingaben werden escaped
Authentifizierung: Nur autorisierte Zugriffe
Sensible Daten: Keine Secrets im Code
Input Validation: Alle Eingaben validiert

4. Performance

Datenbank-Queries: N+1 Problem vermieden
Caching: Wo sinnvoll, Caching verwendet
Algorithmus: Effizienter Algorithmus gewählt
Memory Leaks: Keine Speicherlecks
Async Operations: Nicht blockierende I/O

5. Code-Stil und Lesbarkeit

Namen: Aussagekräftige Variablen- und Funktionsnamen
Funktionen: Klein, eine Verantwortung
Kommentare: Nur für WARUM, nicht WAS
Duplikation: DRY eingehalten
Linter: Keine Linter-Fehler

6. Tests

Unit Tests: Neue Logik ist getestet
Integration Tests: API-Endpunkte getestet
Edge Cases: Tests für Grenzfälle
Coverage: Testabdeckung ausreichend
Flaky Tests: Keine instabilen Tests

7. Dokumentation

README: README bei Bedarf aktualisiert
API-Docs: API-Änderungen dokumentiert
Inline-Docs: Komplexe Funktionen dokumentiert
Changelog: Changelog aktualisiert
Migration Guide: Breaking Changes dokumentiert

8. Architektur und Design

SOLID: Prinzipien eingehalten
Kohäsion: Zusammengehöriges in einem Modul
Kopplung: Lose Kopplung zwischen Modulen
Abstraktion: Richtige Abstraktionsebene
Scalability: Design skaliert mit Anforderungen

9. Git-Praktiken

Commit-Messages: Konventionelle Commits
Branch-Name: Deskriptiver Branch-Name
Commits: Logisch zusammengehörige Commits
Merge-Strategie: Rebase oder Merge konsistent
WIP-Commits: Keine WIP-Commits im finalen PR

10. CI/CD

CI grün: Alle Checks bestanden
Build: Build erfolgreich
Tests: Alle Tests bestanden
Lint: Keine Linter-Fehler
Security Scan: Keine Sicherheitslücken

Beispiel-Review

## Code Review: JWT Authentication

### ✅ Gut
- Klare Trennung von Auth-Logik und Controller
- Umfassende Unit Tests
- PR-Beschreibung ist detailliert

### ⚠️ Verbesserungen
- Secret sollte aus Umgebungsvariablen gelesen werden
- Token-Validierung könnte in einen Service ausgelagert werden
- Integration Tests für API-Endpunkte fehlen

### ❏ Fragen
- Warum wurde JWT statt OAuth2 gewählt?
- Ist der Token-Refresh-Flow implementiert?

### ✏️ Änderungen erforderlich
- [ ] Secret aus ENV lesen
- [ ] Integration Tests hinzufügen

Priorisierung

Priorität	Kategorie	Fokus
Kritisch	Sicherheit, Logik	Blockiert Merge
Hoch	Performance, Tests	Sollte behoben werden
Mittel	Stil, Dokumentation	Kann nachgeholt werden
Niedrig	Nitpicks	Optional

Prüfungsrelevante Stichpunkte

Strukturierte Checkliste für konsistente Reviews
Kategorien: Logik, Sicherheit, Performance, Tests, Dokumentation
Priorisierung: Kritisch > Hoch > Mittel > Niedrig
CI/CD-Integration als Quality Gate
Breaking Changes müssen dokumentiert sein

FAQ

1. Was ist eine Code Review Checkliste?

Strukturierte Liste von Prüfpunkten für konsistente Code Reviews.

2. Welche Kategorien gehören in die Checkliste?

Logik, Sicherheit, Performance, Tests, Dokumentation, Architektur, Git, CI/CD.

3. Wie priorisiert man Feedback?

Kritisch > Hoch > Mittel > Niedrig. Kritisch blockiert Merge.

4. Was sind kritische Punkte?

Sicherheitslücken, Logikfehler, fehlende Tests.

5. Was gehört in die PR-Beschreibung?

Was, Warum, Tests, Screenshots, Breaking Changes.

6. Wie prüft man Sicherheit?

SQL Injection, XSS, Auth, Secrets, Input Validation.

7. Wie prüft man Performance?

N+1 Queries, Caching, Algorithmus, Memory Leaks, Async.

8. Was bei Tests?

Unit Tests, Integration Tests, Edge Cases, Coverage, keine Flaky Tests.

9. Was bei Dokumentation?

README, API-Docs, Inline-Docs, Changelog, Migration Guide.

10. Was bei Git-Praktiken?

Konventionelle Commits, deskriptive Branches, logische Commits.

11. Was bei CI/CD?

CI grün, Build, Tests, Lint, Security Scan.

12. Wie lange sollte ein Review dauern?

Mit Checkliste 15-30 Minuten für kleine PRs.

13. Sollte jede Checkliste angepasst werden?

Ja, an Projekt und Team anpassen.

14. Was bei Breaking Changes?

Dokumentieren, Migration Guide, Changelog.

15. Automatisierte Checks?

Linter, Security Scan, Tests in CI/CD automatisieren.

Weiter im Softwarequalität Lernpfad

Der nächste Artikel im Softwarequalität Lernpfad behandelt Static Code Analysis Tools — automatisierte Tools zur Code-Qualitätsprüfung wie ESLint, SonarQube und Pylint.