Informatik Softwareentwicklung – Code-Review und Pair Programming
Karteikarten zum Thema „Informatik“ · 15 Karten · von atrio. Beispiele: Was ist ein Code Review in der Softwareentwicklung? · Welche drei Hauptziele verfolgt…
Karten
15 KartenWas ist ein Code Review in der Softwareentwicklung?
Rückseite
Systematische Prüfung von Quellcode durch andere Entwickler vor dem Merge, um Fehler zu finden, Wissen zu teilen und Code-Qualität sicherzustellen.
Welche drei Hauptziele verfolgt ein Code Review?
Rückseite
Fehlererkennung vor Production, Wissensverteilung im Team und Einhaltung von Coding-Standards sowie Architekturentscheidungen.
Was versteht man unter Pair Programming?
Rückseite
Zwei Entwickler arbeiten an einem Arbeitsplatz gemeinsam an Code: einer tippt (Driver), der andere denkt strategisch nach und prüft (Navigator).
Welche Rollen gibt es beim Pair Programming und wie oft sollte gewechselt werden?
Rückseite
Driver (tastaturaktiv) und Navigator (denkend, prüfend); Rollenwechsel alle 15–30 Minuten hält beide engagiert und verteilt kognitive Last.
Welche messbaren Vorteile bringt Pair Programming gegenüber Solo-Arbeit?
Rückseite
15–30 % weniger Defekte, bessere Design-Entscheidungen, schnelleres Onboarding, geteiltes Code-Verständnis – bei ca. 15 % höherem Personaleinsatz.
Was gehört auf eine Code-Review-Checkliste?
Rückseite
Funktionalität, Lesbarkeit, Tests, Security, Performance, Error-Handling, Dokumentation, Architekturkonformität, keine Hardcodings, saubere Git-Historie.
Welche Obergrenze für Code-Review-Größe wird empfohlen?
Rückseite
Maximal 400 Zeilen Änderungen pro Review – größere Pull Requests werden oberflächlicher geprüft und enthalten signifikant mehr übersehene Fehler.
Wie lange sollte ein einzelnes Code Review maximal dauern?
Rückseite
60 Minuten am Stück; danach sinkt die Fehlererkennungsrate drastisch – große Reviews in mehrere Sessions aufteilen.
Nenne drei Anti-Patterns bei Code Reviews.
Rückseite
Nur Style-Kommentare (Bikeshedding), Reviews ohne Kontextverständnis, „LGTM“ ohne echte Prüfung, persönliche Kritik statt Code-Kritik, Reviews blockieren statt verbessern.
Welche Anti-Patterns treten beim Pair Programming auf?
Rückseite
Driver dominiert dauerhaft, Navigator schweigt passiv, beide tippen gleichzeitig, kein Rollenwechsel, Pairing bei trivialen Tasks (Overhead), Skill-Gap zu groß.
Welche Metriken messen Code-Review-Qualität?
Rückseite
Defect Detection Rate (Fehler pro 100 LoC), Review Coverage (% geprüfter Changes), Time to First Review, Rework-Rate, Review Participation pro Teammitglied.
Wann ist Pair Programming effizienter als Code Review?
Rückseite
Bei komplexen, risikoreichen oder neuartigen Aufgaben, bei Onboarding, Wissenssilos, architektonischen Entscheidungen – Code Review reicht für Routine-Änderungen.
Was ist der Hauptunterschied zwischen Code Review und Pair Programming?
Rückseite
Code Review ist asynchron, nachträglich, asynchrones Feedback; Pair Programming ist synchron, präventiv, kontinuierlicher Dialog während der Entwicklung.
Was bedeutet „Time to First Review“ und warum ist sie wichtig?
Rückseite
Zeit vom PR-Erstellen bis zum ersten Reviewer-Kommentar; lange Wartezeiten blockieren Deployment-Pipeline, erhöhen Merge-Konflikte und Frustration.
Wie fördert Pair Programming explizit Knowledge Sharing?
Rückseite
Beide Partner verstehen den gesamten Code, Bus-Factor steigt, implizites Wissen wird externalisiert, Junior lernt von Senior durch direktes Vorzeigen und Erklären.