Code Review Best Practices
Code Review: Best Practices für Teams
Gute Code Reviews verbessern Code-Qualität und Teamwissen. Lernen Sie, wie Sie effektiv Reviews geben und empfangen.
Warum Code Reviews?
| Vorteil | Beschreibung |
|---|---|
| Bugs finden | Zweites Augenpaar findet Fehler |
| Wissenstransfer | Team lernt verschiedene Codebereiche kennen |
| Konsistenz | Code-Standards werden eingehalten |
| Mentoring | Junior-Entwickler lernen von Seniors |
| Dokumentation | PR-Diskussionen als Wissensquelle |
Für Reviewer
Review-Checkliste
☐ Funktionalität - Erfüllt der Code die Anforderungen? - Edge Cases berücksichtigt? - Fehlerbehandlung vorhanden? ☐ Design - Passt in die Architektur? - Keine unnötige Komplexität? - Single Responsibility? ☐ Lesbarkeit - Verständliche Namen? - Kommentare wo nötig? - Logische Struktur? ☐ Tests - Ausreichend getestet? - Edge Cases getestet? - Tests lesbar? ☐ Security - Input validiert? - Keine Secrets im Code? - SQL Injection, XSS geschützt? ☐ Performance - N+1 Queries? - Unnötige Berechnungen? - Caching berücksichtigt?
Feedback geben
# ❌ Schlecht "Das ist falsch." "Warum hast du das so gemacht?" "Das ist hässlich." # ✅ Gut "Hier könnte ein Edge Case auftreten wenn X null ist. Wie wäre es mit: `if (x?.value)`?" "Ich verstehe den Ansatz noch nicht ganz. Könntest du erklären, warum du Y statt Z gewählt hast?" "Für die Lesbarkeit könnten wir diese Funktion in kleinere Teile aufteilen. Was denkst du?"
Kommentar-Präfixe
# Verwendet Präfixe für Klarheit [blocker] Muss gefixt werden vor Merge "[blocker] Diese Query ist anfällig für SQL Injection." [suggestion] Verbesserungsvorschlag, optional "[suggestion] Hier könnte ein früher Return die Verschachtelung reduzieren." [question] Verständnisfrage "[question] Wird dieser Fall durch den Test abgedeckt?" [nit] Kleinigkeit, nice-to-have "[nit] Trailing whitespace auf Zeile 42" [praise] Lob! "[praise] Sehr elegante Lösung für das Caching-Problem!"
Für Autoren
PR vorbereiten
# Gute PR-Beschreibung ## Summary Fügt Pagination zur User-Liste hinzu, um Performance bei großen Datenmengen zu verbessern. ## Changes - Neuer `Pagination` Component - API-Endpoint akzeptiert `page` und `limit` Parameter - Unit Tests für Pagination-Logik ## Testing - [x] Unit Tests hinzugefügt - [x] Manuell getestet mit 10.000 Usern - [x] Mobile responsive geprüft ## Screenshots [Screenshot der neuen UI] ## Related Fixes #123
PR-Größe
# Ideal: 200-400 Zeilen # Maximum: 500 Zeilen # Zu groß? Aufteilen: PR 1: Database Migration PR 2: API Endpoint PR 3: Frontend Component PR 4: Integration
Auf Feedback reagieren
# ✅ Gut "Guter Punkt! Habe ich gefixt in commit abc123." "Danke für den Vorschlag. Ich habe es so gelassen weil X, aber ich bin offen für andere Lösungen." "Ich verstehe die Bedenken. Lass uns kurz darüber sprechen." # ❌ Vermeiden "Das war schon so." "Funktioniert doch." [Kommentar ignorieren]
Review-Prozess
1. Autor erstellt PR ↓ 2. CI läuft (Tests, Linting) ↓ 3. Reviewer assigned ↓ 4. Review (max 24h) ↓ 5. Feedback einarbeiten ↓ 6. Re-Review wenn nötig ↓ 7. Approval ↓ 8. Merge
Automatisierung
# GitHub Actions - Auto-Assign Reviewer
# .github/workflows/assign-reviewer.yml
name: Auto Assign Reviewer
on:
pull_request:
types: [opened]
jobs:
assign:
runs-on: ubuntu-latest
steps:
- uses: kentaro-m/auto-assign-action@v1
with:
configuration-path: '.github/auto-assign.yml'
# .github/auto-assign.yml
addReviewers: true
reviewers:
- reviewer1
- reviewer2
numberOfReviewers: 1
# Automatische Checks
# .github/workflows/pr-checks.yml
name: PR Checks
on: pull_request
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
size-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check PR size
run: |
ADDITIONS=$(gh pr view ${{ github.event.number }} --json additions -q '.additions')
if [ "$ADDITIONS" -gt 500 ]; then
echo "::warning::PR is large ($ADDITIONS lines). Consider splitting."
fi
Team-Kultur
💡 Kultur-Tipps:
- Review den Code, nicht die Person
- Fragen statt Anweisungen
- Lob aussprechen, nicht nur Kritik
- Zeitnah reviewen (< 24h)
- Bei Unklarheiten: kurzer Call statt lange Kommentar-Threads