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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
Studien zeigen: Code-Reviews finden 60-90 % der Bugs VOR Production. Plus: sie verbessern Kollegen-Wissen + Code-Qualität langfristig.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Studien zeigen: Code-Reviews finden 60-90 % der Bugs VOR Production. Plus: sie verbessern Kollegen-Wissen + Code-Qualität langfristig.
Code-Review: Strukturierte Prüfung von Code-Änderungen durch einen oder mehrere andere Entwickler — VOR dem Merge.
| 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 |
┌─────────────────────────┐
│ 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 │
└─────────────────────────┘
| 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 |
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 |
| 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 |
Reviewer schaut nicht wirklich rein, klickt einfach "Approve". Schlecht — verschwendet die Vorteile des Reviews.
Stundenlange Diskussion über Variablennamen, ignoriert dabei kritische Bugs. Schlecht — Prioritäten setzen!
"Du verstehst echt gar nichts!" — Niemals. Code kritisieren, nicht den Entwickler.
Nur EINE Person darf reviewen, alle warten auf sie. Schlecht — Wissen verteilen, mehrere Reviewer.
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.
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.
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.
6 Aufgaben zu Review-Prozess, Best-Practices und Anti-Patterns.
Klausurfragen mit Lösungen (6)
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'.
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).
Zuordnungen:
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
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.
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
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.
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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