Code Review: Best Practices für Teams | Enjyn Gruppe
Hallo Welt
Hallo Welt
Original Lingva Deutsch
Übersetzung wird vorbereitet...
Dieser Vorgang kann bis zu 60 Sekunden dauern.
Diese Seite wird erstmalig übersetzt und dann für alle Besucher gespeichert.
0%
DE Zurück zu Deutsch
Übersetzung durch Lingva Translate

235 Dokumentationen verfügbar

Wissensdatenbank

Code Review Best Practices

Zuletzt aktualisiert: 20.01.2026 um 10:03 Uhr

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

Weitere Informationen

Enjix Beta

Enjyn AI Agent

Hallo 👋 Ich bin Enjix — wie kann ich dir helfen?
120