Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Studien zeigen: Code-Reviews finden 60-90 % der Bugs VOR Production. Plus: sie verbessern Kollegen-Wissen + Code-Qualität langfristig.
Die Idee in einem Satz
Code-Review: Strukturierte Prüfung von Code-Änderungen durch einen oder mehrere andere Entwickler, VOR dem Merge.
Ziele eines Code-Reviews
| Ziel | Beschreibung |
|---|---|
| Bugs finden | Logik-Fehler, Edge-Cases, Sicherheits-Lücken |
| Code-Qualität | Lesbarkeit, Wartbarkeit, Architektur-Konsistenz |
| Wissens-Verbreitung | Mehrere Köpfe kennen den Code → Bus-Faktor steigt |
| Mentoring | Junior lernt von Senior und umgekehrt |
| Standards durchsetzen | Coding-Conventions, Architektur-Entscheidungen |
Ablauf eines typischen Code-Reviews
┌─────────────────────────┐
│ 1. Entwickler erstellt │
│ Pull Request (PR) │
└────────────┬─────────────┘
↓
┌─────────────────────────┐
│ 2. CI-Pipeline läuft │
│ (Tests, Linting) │
└────────────┬─────────────┘
↓
┌─────────────────────────┐
│ 3. Reviewer schaut Code │
│ + hinterlässt Kommentare│
└────────────┬─────────────┘
↓
┌─────┴─────┐
↓ ↓
Approved Changes
│ Requested
│ │
│ ↓
│ ┌─────────────┐
│ │ 4. Entwickler│
│ │ ändert Code │
│ └──────┬───────┘
│ ↓
│ (zurück zu 3)
↓
┌─────────────────────────┐
│ 5. Merge in main │
└─────────────────────────┘
Was prüft ein Reviewer?
Funktionalität
- Korrektheit: Tut der Code, was er soll?
- Edge-Cases: Null-Werte, leere Listen, Grenz-Werte?
- Fehler-Behandlung: Werden Errors sinnvoll behandelt?
Lesbarkeit
- Verständlich: Würde ich den Code in 6 Monaten noch verstehen?
- Namen: Sind Variablen + Methoden klar benannt?
- Kommentare: Erklären sie WARUM, nicht WAS?
Architektur
- Konsistenz: Folgt der Code dem bestehenden Stil?
- Komplexität: Ist der Code unnötig komplex?
- Abstraktion: Sind die richtigen Ebenen gewählt?
Tests
- Coverage: Sind die wichtigen Pfade getestet?
- Edge-Cases: Test für Null, leer, Grenzen?
- Lesbarkeit: Sind Tests selbst lesbar?
Sicherheit
- Input-Validierung: Werden Nutzer-Inputs validiert?
- SQL-Injection: Parametrisierte Queries?
- Secrets: Keine API-Keys im Code?
Performance
- N+1-Queries: DB-Performance OK?
- Memory-Leaks: Resources korrekt freigegeben?
- Algorithmen: Sinnvolle Komplexität?
Die wichtigsten Review-Regeln
Für Reviewer
- Sei freundlich. Code kritisieren, nicht den Entwickler.
- Erkläre das Warum. "Bitte X ändern, weil Y" statt nur "X ändern".
- Schlage Lösungen vor. Wenn du was kritisierst, biete Alternativen.
- Trenne wichtig von Nice-to-have. "Blocker" vs. "Nitpick".
- Lobe gutes. Positive Kommentare motivieren.
- Zeitnah reviewen. Lieber 30 Min. heute als 2 Stunden in 3 Tagen.
Für Entwickler (PR-Author)
- Kleine PRs. Max ~400 Zeilen Änderung. Reviewer ermüden bei großen PRs.
- Self-Review zuerst. Geh deinen Code selbst durch, bevor du PR erstellst.
- Gute PR-Beschreibung. Was? Warum? Wie? Screenshots bei UI-Änderungen.
- Tests inklusive. Niemand merged Code ohne Tests.
- Reagiere auf Feedback. Auch wenn du anderer Meinung bist, diskutiere.
- Bedanke dich. Reviewer investieren Zeit für dich.
Code-Review-Tools
| Tool | Wo? |
|---|---|
| GitHub Pull Requests | GitHub-basierte Projekte |
| GitLab Merge Requests | GitLab-basierte Projekte |
| Gerrit | Google, Android, Chromium |
| Crucible | Atlassian-Stack |
| Reviewable | Github + ergänzendes UI |
Qualitätssicherung (QS), über Code-Reviews hinaus
Code-Reviews sind nur EIN Teil der QS. Weitere wichtige Bestandteile:
| Element | Beschreibung |
|---|---|
| Automated Tests | Unit, Integration, E2E |
| Linting | ESLint, RuboCop, Pylint, automatische Stil-Prüfung |
| Static Analysis | SonarQube, CodeClimate, Code-Smells finden |
| Type-Checking | TypeScript, mypy, Typfehler vor Laufzeit |
| Code-Coverage | Coverage-Reports mit Threshold (z.B. 80 %) |
| Pair Programming | 2 Entwickler an einem Rechner, Review live |
| Pre-Commit Hooks | Lint + Test vor jedem Commit |
| Mutation Testing | Prüft, ob Tests wirklich Bugs finden |
Häufige Review-Kommentare
| Kommentar | Wann? |
|---|---|
| LGTM | "Looks Good To Me", alles in Ordnung |
| Nit: | "Nitpick", kleines Detail, nicht blockierend |
| Question: | "Frage", möchte verstehen, kein Vorwurf |
| Suggestion: | "Vorschlag", Alternative, nicht zwingend |
| Blocker: | "Muss geändert werden", vor Merge fixen |
Anti-Patterns
Rubber-Stamping
Reviewer schaut nicht wirklich rein, klickt einfach "Approve". Schlecht, verschwendet die Vorteile des Reviews.
Bikeshedding
Stundenlange Diskussion über Variablennamen, ignoriert dabei kritische Bugs. Schlecht, Prioritäten setzen!
Persönliche Angriffe
"Du verstehst echt gar nichts!", Niemals. Code kritisieren, nicht den Entwickler.
Reviewer-Bottleneck
Nur EINE Person darf reviewen, alle warten auf sie. Schlecht, Wissen verteilen, mehrere Reviewer.
Klausur-Faustregeln
1. Code-Reviews finden 60-90 % der Bugs vor Production.
2. Pull Request (PR) ist die Code-Einheit, die reviewed wird.
3. Reviewer prüft: Funktionalität, Lesbarkeit, Architektur, Tests, Sicherheit, Performance.
4. Kleine PRs (max ~400 Zeilen).
5. Sei freundlich: Code kritisieren, nicht den Entwickler.
6. QS ist mehr als Review: Tests + Linting + Static Analysis + Type-Checking.
Häufige Stolpersteine
1. PRs zu groß. Tausend-Zeilen-PRs werden nicht sinnvoll reviewt, Reviewer skim+approve. Lieber 5x kleine PRs als 1x große.
2. Reviewer als Schuldzuweisung sehen. Reviews sollen Code besser machen, nicht Schuld zuweisen. Wenn jeder reviewt UND wird reviewt, gibt es keine Hierarchie.
3. "Wer reviewt, der merged." Anti-Pattern in vielen Teams. Besser: 2-Reviewer-Regel oder Code-Owners definieren.
4. CI-grün = Review-OK. Falsch. CI prüft Tests + Linting. Review prüft Verständlichkeit, Architektur, Edge-Cases, die CI nicht sehen kann.
5. Pair Programming statt Reviews ist OK. Stimmt teilweise, Pair-Programming ist Live-Review. Aber das Review-Dokument fehlt für Nachvollziehbarkeit.
Interaktiv verstehen
Review-Kommentare üben
Du bist Reviewer. Klassifiziere die Kommentare nach Schwere (Blocker / Vorschlag / Nit / Frage / Lob).
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Bei Code-Review-Fragen IMMER 3 Ebenen erwähnen: Funktionalität (tut der Code was er soll?), Qualität (ist er gut lesbar?), Sicherheit (gibt es Sicherheits-Risiken?). Plus eine 4. Ebene Performance bei Senior-Klausuren.
Praxis-Übung
Code-Reviews, Praxis-Übung
6 Aufgaben zu Review-Prozess, Best-Practices und Anti-Patterns.
Klausurfragen mit Lösungen (6)
- F1.Was ist das primäre Ziel eines Code-Reviews?
Antwort: Bugs früh zu finden, Code-Qualität zu erhöhen + Wissen zu verbreiten
Erklärung: Code-Reviews haben mehrere Ziele gleichzeitig: 1) Bugs finden VOR Production (60-90% laut Studien), 2) Code-Qualität erhöhen, 3) Wissen verbreiten (Bus-Faktor erhöhen), 4) Mentoring (Junior↔Senior). Das ist viel mehr als nur Style-Vereinheitlichung, und definitiv nicht 'kritisieren'.
- F2.Was bedeutet 'LGTM' in einem Code-Review?
Antwort: Looks Good To Me
Erklärung: LGTM = 'Looks Good To Me'. Standard-Kürzel beim Code-Review, wenn der Code OK aussieht. Andere wichtige Kürzel: PTAL = 'Please Take Another Look' (Reviewer-Bitte). WIP = 'Work In Progress' (noch nicht reviewbar). Nit = 'Nitpick' (kleines Detail).
- F3.Ordne die Review-Kommentar-Typen ihrer Bedeutung zu.
Zuordnungen:
- Nit: → Nitpick, kleines Detail, nicht blockierend
- Blocker: → Muss geändert werden VOR Merge
- Question: → Frage zum Verständnis, kein Vorwurf
- Suggestion: → Alternative, nicht zwingend
Erklärung: Wichtige Kommentar-Präfixe für klare Priorisierung: Blocker (muss-fix) > Suggestion (nice-to-have) > Nit (klein) > Question (Klärung). Diese Prefixe helfen dem PR-Autor zu erkennen, was kritisch ist und was nicht. Ohne Prefix: Reviewer muss alles als Blocker behandeln, was Frust erzeugt.
Typ: Zuordnung
- F4.Welche Größe wird für Pull Requests empfohlen?
Antwort: Max. ~400 Zeilen Änderungen
Erklärung: Studien (Google, SmartBear) zeigen: Reviewer können effektiv max. 200-400 Zeilen reviewen, bevor Aufmerksamkeit nachlässt. Größere PRs werden 'durchgewunken' = Review-Wert sinkt. Best Practice: PR < 400 Zeilen. Wenn größer: in mehrere kleine PRs splitten. Lieber 5x klein als 1x riesig.
- F5.Code-Reviews ersetzen automatisierte Tests komplett.
Antwort: Falsch
Erklärung: FALSCH. Code-Reviews und Tests sind KOMPLEMENTÄR, nicht austauschbar. Tests prüfen automatisiert das VERHALTEN (Funktioniert der Code?). Reviews prüfen das DESIGN (Ist der Code gut?). Beides braucht man. Reviews finden Lesbarkeits-, Architektur- und Edge-Case-Probleme, die Tests nicht finden. Tests finden Regressionen, die Reviewer-Augen übersehen.
Typ: Wahr/Falsch
- F6.Welche Aussage über Code-Reviews ist FALSCH?
Antwort: Sie machen den Code zu 100 % bug-frei
Erklärung: FALSCH ist 'zu 100% bug-frei'. Reviews finden VIELE Bugs (60-90% laut Studien), aber NIEMALS alle. Bugs können trotz Review durchrutschen, vor allem bei Race-Conditions, komplexen Edge-Cases oder Integration-Problemen. Reviews + Tests + Static Analysis + Monitoring sind alle wichtig, keine einzige Praktik ist Allheilmittel.
Klausur-Quiz
Code-Reviews & QS, Klausur-Quiz
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
- F1.Was ist ein 'Pull Request' (PR)?
Antwort: Eine Code-Änderung, die zum Merge in den Haupt-Branch vorgeschlagen wird
Erklärung: Pull Request (PR) ist die Einheit, die in Code-Reviews überprüft wird. Der Entwickler 'requested' (bittet darum), dass seine Änderungen 'pulled' (in den Haupt-Branch gemerged) werden. GitLab nennt das 'Merge Request' (MR), gleicher Inhalt. Standard-Workflow seit ~2010 in fast jedem Software-Team.
- F2.Was sollte ein Reviewer NICHT tun?
Antwort: Persönliche Angriffe auf den Entwickler
Erklärung: Persönliche Angriffe sind ABSOLUTES NO-GO. Regel: Code kritisieren, nicht den Entwickler. Stattdessen: 'Diese Funktion hat einen Bug bei X' statt 'Du verstehst das nicht'. Andere Punkte (freundlich, Lösungen, Lob) sind richtige Verhaltensweisen.
- F3.Studien zeigen, dass Code-Reviews bis zu {{1}} % der Bugs vor Production finden. Ein typischer PR sollte nicht größer als {{2}} Zeilen sein. Das Kürzel 'LGTM' bedeutet '{{3}}'.
Lösungen pro Lücke:
- {{1}}: 90
- {{2}}: 400
- {{3}}: Looks Good To Me
Erklärung: 60-90% der Bugs werden in Reviews gefunden (laut SmartBear/Cisco-Studien). 200-400 Zeilen ist die Effektivitäts-Grenze für Reviewer-Aufmerksamkeit. LGTM = 'Looks Good To Me' ist die Standard-Abkürzung für Review-Approval.
Typ: Lückentext
- F4.Bringe die Schritte eines typischen Code-Review-Prozesses in die richtige Reihenfolge.
Richtige Reihenfolge:
- Entwickler erstellt Pull Request
- CI-Pipeline läuft (Tests, Linting)
- Reviewer schaut Code an + hinterlässt Kommentare
- Reviewer approved oder fordert Changes
- Merge in den main-Branch
Erklärung: Reihenfolge: 1) PR erstellen, 2) CI prüft automatisiert (Tests, Lint), 3) Reviewer schaut Code, 4) Approve oder Changes Requested (eventuell mehrere Iterationen), 5) Merge. Wichtig: CI VOR Review, sinnlos zu reviewen wenn Tests rot sind.
Typ: Reihenfolge
- F5.Was ist 'Bikeshedding' im Kontext von Code-Reviews?
Antwort: Stundenlange Debatte über Trivialitäten, während wichtige Issues ignoriert werden
Erklärung: Bikeshedding (auch 'Parkinson's Law of Triviality'): Eine Gruppe diskutiert lange über simple Dinge (Variablennamen, Einrückung), während komplexe wichtige Themen unbeachtet bleiben. Anti-Pattern in Reviews. Faustregel: Wenn 3 Kommentare zu 'Lib import order' aber keine zu der komplexen DB-Migration → Bikeshedding-Verdacht.
- F6.Wenn die CI-Pipeline grün ist, ist der Code review-OK.
Antwort: Falsch
Erklärung: FALSCH. CI-Pipeline prüft Tests, Linting, Type-Checks, alles automatisierbares. Code-Review prüft Lesbarkeit, Architektur, Edge-Cases, Domain-Logik, alles MENSCHLICHES URTEIL. CI grün bedeutet: 'Code crasht nicht, kein Style-Verstoß'. Review bedeutet: 'Code ist gut'. Beides ist nötig. CI-grün ohne Review = riskant.
Typ: Wahr/Falsch
