Code Reviews

Code Reviews sind ein unverzichtbarer Teil professioneller Softwareentwicklung. Dabei schaut sich ein anderer Entwickler deinen Code an, bevor er in den Hauptbranch gemergt wird. In diesem Kapitel lernst du, wie du gute Reviews schreibst und wie du selbst von Reviews profitierst.

Was ist ein Code Review?

Ein Code Review ist der Prozess, bei dem ein oder mehrere Entwickler den Code eines Teamkollegen ueberpruefen, bevor er gemergt wird.

Warum Code Reviews?

Vorteil	Beschreibung
Fehler finden	Vier Augen sehen mehr als zwei
Wissenstransfer	Das Team lernt voneinander
Code-Qualitaet	Einheitlicher, sauberer Code
Sicherheit	Potenzielle Sicherheitsprobleme entdecken
Mentoring	Juengere Entwickler lernen von Erfahrenen

Einen guten Review schreiben

Schritt 1: Den Kontext verstehen

Bevor du den Code anschaust:

1. Lies die PR-Beschreibung - was soll die Aenderung bewirken?
2. Schaue dir die verknuepften Issues an
3. Verstehe das Gesamtbild - wo passt diese Aenderung hin?

Schritt 2: Den Code ueberpruefen

Gehe im Tab Files changed durch alle Aenderungen:

+ function validateEmail(email) {
+     return email.includes('@');
+ }

Hier koenntest du kommentieren:

Die Validierung ist sehr einfach. E-Mails wie "test@" wuerden akzeptiert.
Vielleicht besser einen regulaeren Ausdruck verwenden?

```suggestion
function validateEmail(email) {
    const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    return pattern.test(email);
}

### Schritt 3: Das Review abschliessen

Klicke auf **Review changes** und schreibe eine Zusammenfassung:

Insgesamt sieht das gut aus! Das Kontaktformular funktioniert und ist gut strukturiert.

Zwei Punkte sollten noch angepasst werden:

1. E-Mail-Validierung verbessern
2. Fehlermeldungen fuer den Benutzer anzeigen

## Review-Kommentare richtig formulieren

### Die goldene Regel

Kritisiere den **Code**, nicht den **Entwickler**.

### Gute vs. Schlechte Kommentare

**Schlecht:**

Das ist falsch.

Warum hast du das so gemacht?

Das ist schlechter Code.

**Gut:**

Hier koennte es zu einem Fehler kommen, wenn email null ist. Vielleicht einen null-Check hinzufuegen?

Koennten wir hier stattdessen eine Map verwenden? Das wuerde die Performance bei grossen Listen verbessern.

Nit: Kleine Stilfrage - in unserem Projekt nutzen wir camelCase fuer Funktionsnamen.

### Kommentar-Praefix-System

Viele Teams nutzen Praefixe, um die Wichtigkeit zu signalisieren:

| Praefix | Bedeutung | Beispiel |
|---|---|---|
| **blocker:** | Muss geaendert werden | `blocker: SQL-Injection-Luecke` |
| **suggestion:** | Vorschlag zur Verbesserung | `suggestion: Hier waere ein try-catch sinnvoll` |
| **nit:** | Kleinigkeit (nice to have) | `nit: Leerzeile entfernen` |
| **question:** | Verstaendnisfrage | `question: Warum async hier?` |
| **praise:** | Lob! | `praise: Tolle Loesung!` |

### Code-Vorschlaege auf GitHub

GitHub hat eine eingebaute Vorschlagsfunktion:

```suggestion
// Statt:
const result = arr.filter(x => x > 0).map(x => x * 2);

// Vorschlag:
const result = arr.reduce((acc, x) => {
    if (x > 0) acc.push(x * 2);
    return acc;
}, []);

Der Autor kann den Vorschlag mit einem Klick uebernehmen - das spart Zeit!

Worauf du beim Review achten solltest

1. Funktionalitaet

• Tut der Code, was er soll?
• Werden Randfaelle behandelt?
• Gibt es potenzielle Fehlerquellen?

question: Was passiert, wenn der Benutzer das Formular
doppelt absendet? Gibt es einen Schutz dagegen?

2. Lesbarkeit

• Sind Variablen- und Funktionsnamen verstaendlich?
• Ist der Code gut strukturiert?
• Gibt es Kommentare, wo sie noetig sind?

suggestion: Der Name `d` ist nicht sehr aussagekraeftig.
Vielleicht `formData` oder `contactData`?

3. Sicherheit

• Gibt es Sicherheitsluecken?
• Werden Benutzereingaben validiert?
• Werden sensible Daten geschuetzt?

blocker: Benutzereingaben werden direkt ins HTML eingefuegt.
Das oeffnet eine XSS-Luecke. Bitte die Eingaben escapen.

4. Performance

• Gibt es unnoetige Berechnungen?
• Werden Ressourcen effizient genutzt?

suggestion: Diese Schleife iteriert 3x ueber das Array.
Mit einem einzigen Durchlauf waere es effizienter.

5. Konsistenz

• Passt der Code zum bestehenden Stil?
• Werden Konventionen eingehalten?

nit: Wir nutzen in diesem Projekt einfache Anfuehrungszeichen
fuer Strings statt doppelte.

Als Autor auf Reviews reagieren

Feedback annehmen

Guter Punkt! Habe die Validierung verbessert. Danke!

Wenn du anderer Meinung bist

Ich verstehe den Vorschlag, aber in diesem Fall habe ich mich
bewusst dagegen entschieden, weil [Begruendung]. Was denkst du?

Aenderungen einarbeiten

# Review-Feedback umsetzen
git switch feature/kontakt-formular

# Aenderungen machen
# ... Code anpassen ...

git add kontakt.html
git commit -m "fix: E-Mail-Validierung verbessert (Review-Feedback)"
git push

Der PR wird automatisch aktualisiert!

Alle Kommentare beantworten

Gehe jeden Kommentar durch und:

• Resolved: Wenn du die Aenderung umgesetzt hast
• Antworten: Wenn du eine Frage beantworten moechtest
• Reagieren: Ein Emoji genuegt manchmal

Review-Checkliste

Nutze diese Checkliste als Leitfaden:

## Review-Checkliste

### Allgemein
- [ ] PR-Beschreibung gelesen und verstanden
- [ ] Code laesst sich bauen/ausfuehren
- [ ] Alle Tests bestehen

### Code-Qualitaet
- [ ] Code ist lesbar und verstaendlich
- [ ] Keine unnoetige Komplexitaet
- [ ] DRY-Prinzip eingehalten (kein duplizierter Code)

### Funktionalitaet
- [ ] Feature funktioniert wie beschrieben
- [ ] Randfaelle werden behandelt
- [ ] Fehlermeldungen sind hilfreich

### Sicherheit
- [ ] Benutzereingaben werden validiert
- [ ] Keine sensiblen Daten im Code

### Stil
- [ ] Code-Konventionen eingehalten
- [ ] Einheitliche Formatierung

Code Reviews als Anfaenger

Als Reviewer

Auch als Anfaenger kannst du wertvolle Reviews schreiben:

• Frage nach, wenn du etwas nicht verstehst - das zeigt oft unklaren Code
• Teste den Code selbst
• Pruefe die README und Dokumentation
• Lobe guten Code!

Als Autor

• Nimm Feedback nicht persoenlich - es geht um den Code, nicht um dich
• Lerne aus jedem Review
• Bedanke dich fuer hilfreiches Feedback
• Frage nach, wenn ein Kommentar unklar ist

Uebungen

1. Schaue dir einen Pull Request in einem Open-Source-Projekt auf GitHub an
2. Erstelle einen eigenen PR und bitte einen Freund um ein Review
3. Ueberpruefe den Code eines Freundes und hinterlasse konstruktive Kommentare
4. Nutze die Suggestion-Funktion, um einen konkreten Code-Vorschlag zu machen
5. Erstelle eine Review-Checkliste fuer dein eigenes Projekt

Was kommt als Naechstes?

Im naechsten Kapitel lernst du, wie du mit Forks an Open-Source-Projekten mitwirken kannst. Du wirst deinen ersten Beitrag zu einem fremden Projekt leisten!

Zusammenfassung

• Code Reviews verbessern die Code-Qualitaet und foerdern den Wissenstransfer
• Kritisiere den Code, nicht den Entwickler
• Nutze Praefixe (blocker, suggestion, nit) fuer klare Kommunikation
• Die Suggestion-Funktion auf GitHub spart Zeit
• Pruefe Funktionalitaet, Lesbarkeit, Sicherheit und Konsistenz
• Als Autor: Nimm Feedback an und lerne daraus
• Auch Anfaenger koennen wertvolle Reviews schreiben