Ein Entwickler erstellt einen Pull Request, der eine Rabattberechnung in einen Checkout-Service integriert. Die Tests sind erfolgreich und die Änderungen sind gering. Ein Reviewer genehmigt ihn innerhalb von zwei Minuten mit „LGTM“. Drei Monate später muss ein Teammitglied dieselbe Funktion ändern und stellt fest, dass sie Preisregeln, Rundungen und Datenbankzugriffe an einer Stelle vermischt. Niemand kann mehr mit Sicherheit sagen, was zulässig ist.
Dies ist ein beispielhaftes Szenario, kein dokumentierter Vorfall. Es zeigt, was eine Peer-Code-Überprüfung als Lernaktivität hervorbringen muss: einen Prüfer, der eine plausible Änderung erkennt, das Problem, das noch kein Fehler ist, aufspürt und es so erklärt, dass der Autor darauf reagieren kann.
Dieser Leitfaden richtet sich an Verantwortliche für die technische Unterstützung und an technische Manager. Er zeigt, wie man … Code-Review-Übungen Diese Fähigkeit sollte gezielt aufgebaut werden, anstatt darauf zu hoffen, dass Prüfer sie automatisch erkennen. Das Programm behandelt das Leistungsproblem, die zu diagnostizierenden Lücken, die Strukturierung von Vorbereitung und Übung, ein praktisches Beispiel und die Überprüfung der Anwendung der erlernten Fähigkeiten in realen Prüfungen. Lassen Sie jeden Fall, jeden Fehler und jedes Kriterium von erfahrenen Entwicklern validieren, bevor Sie es einsetzen.
Was sind Code-Review-Übungen?
Code-Review-Übungen sind strukturierte Aufgaben, bei denen Entwickler eine vorbereitete Änderung prüfen, ihre Feststellungen und deren Bedeutung erläutern und Feedback zur Qualität ihrer Erläuterung erhalten. Sie unterscheiden sich von den täglichen Code-Reviews Ihres Teams. Die Änderung wird im Voraus ausgewählt, die damit verbundenen Probleme sind bekannt, und das Ziel ist die Verbesserung der Fähigkeiten des Reviewers, nicht die Veröffentlichung der Änderung.
Schnelle Fakten
| Frage | Kurze Antwort |
|---|---|
| Was ist die Aufgabe? | Erläutern Sie die Ergebnisse der Überprüfung und geben Sie dem Autor Feedback, auf dessen Grundlage er handeln kann. |
| Welche Punktzahl erreichst du? | Genauigkeit der Ergebnisse und Nützlichkeit der Erklärung. |
| Genügt es, Fehler zu zählen? | Nein. Bei Rezensionen geht es um mehr als nur um Mängel; eine Übung, die nur die Anzahl der Fehler belohnt, fördert die falsche Gewohnheit. |
| Welche kognitiven Anforderungen werden gestellt? | Analysiere und bewerte einen Entwurf und erstelle anschließend einen besseren Vorschlag. |
| Wer bestätigt den Fall? | Ein Engineering Manager oder Senior Engineer, der die Codebasis verantwortet. |
| Was können Übungen nicht beheben? | Zeitdruck bei der Überprüfung, unklare Eigentumsverhältnisse und der Druck, schnell zu fusionieren. |
| Woran erkennt man, dass es funktioniert hat? | Eine neue, bisher unbekannte Änderung wurde anhand vereinbarter Kriterien überprüft, zusätzlich erfolgte eine Nachbesprechung anhand tatsächlicher Bewertungen. |
1. Beschreiben Sie das Leistungsproblem
Beginnen Sie mit der Aufgabenstellung in einem Satz: Der Prüfer erläutert anhand einer Änderung seine Feststellungen, deren Relevanz und mögliche Handlungsoptionen für den Autor. „Erläutert“ ist hierbei das entscheidende Wort. Ein Problem zu erkennen, ist die halbe Miete. Es so zu formulieren, dass ein Kollege mit anderer Sichtweise es versteht, abwägt und entsprechend handelt, ist die andere Hälfte.
Die Forschung zu modernen Code-Reviews unterstützt die Erkenntnis, dass es sinnvoll ist, über die reine Fehlersuche hinauszublicken. In einer Studie bei Microsoft beobachteten, interviewten und befragten Bacchelli und Bird Entwickler und Manager. Sie stellten fest, dass das Auffinden von Fehlern zwar immer noch die Hauptmotivation für Reviews war, dass es bei Reviews aber weniger um Fehler ging als erwartet. Sie lieferten auch andere Vorteile, wie Wissensaustausch, Teamverständnis und alternative Lösungsansätze. Die Forscher beschrieben das Verständnis von Code und Änderungen als den Schlüsselaspekt von Reviews.Bacchelli und Bird, ICSE 2013Es handelt sich um eine Studie über die Teams eines einzelnen Unternehmens. Nutzen Sie sie daher als Anlass, auf Verständnis zu setzen, und nicht als Maßstab für Ihre eigenen Teams.
Googles veröffentlichter Review-Standard geht in dieselbe Richtung. Er fordert Reviewer auf, Änderungen eher zu genehmigen, sobald diese die allgemeine Qualität des Codes eindeutig verbessern, selbst wenn sie nicht perfekt sind, und er besagt, dass Reviews Entwicklern etwas Neues beibringen können, daher sind Kommentare, die zum Lernen beitragen, willkommen.Googles EntwicklungspraktikenBeide Quellen beschreiben die Überprüfung als einen Ort, an dem Urteilsvermögen ausgeübt und weitergegeben wird. Genau das sollten Ihre Übungen trainieren.
2. Lern- und Kontextlücken diagnostizieren
Vergleichen Sie die Aufgabe mit dem, was in Ihrem aktuellen Programm praktiziert und bewertet wird.
- Wird in der aktuellen Praxis die reale Aufgabe berücksichtigt? Wenn neue Reviewer lernen, indem sie einen Styleguide lesen und anschließend Pull Requests live prüfen, üben sie an realen Projekten, ohne Fehler machen zu dürfen. Besteht die Bewertung hingegen nur aus einem Quiz zur Review-Etikette, misst sie das Wissen um die Regeln, nicht aber die Fähigkeit, diese auf eine Änderung anzuwenden.
- Welche kognitiven Anforderungen werden gestellt? In der überarbeiteten Bloomschen Taxonomie fällt die Beurteilung der Plausibilität eines Designs und die Abwägung seiner Vor- und Nachteile auf die Analyse- und Bewertungsebene, während das Vorschlagen einer besseren Struktur die Ebene des Erstellens erreicht. Wenn Ihre Übungen lediglich fragen: „Was macht dieser Code?“, bleibt es beim Verständnis. Unser Leitfaden zu Zuordnung von Lernaktivitäten zu Blooms Taxonomie zeigt, wie man die Aktivität dem jeweiligen Level zuordnet.
- Steht da etwas anderes als Können im Weg? Prüfen Sie die Prüfzeit, die verwendeten Tools, die Zuständigkeiten und die Teamnormen. Stehen Prüfern nur fünf Minuten pro Pull Request zur Verfügung, wird keine durchdachte Erklärung entstehen. Wenn Autoren jeden Kommentar als Kritik auffassen, werden Prüfer ihre Ergebnisse so weit abschwächen, dass sie nichts mehr sagen. Melden Sie diese Ursachen denjenigen, die sie beheben können.
3. Designvorbereitung, Übung und Feedback
Weisen Sie jeder Phase eine separate Aufgabe zu.
Vorbereitung. Prüfen Sie vor Beginn der Review-Phase, was die Reviewer benötigen: die Checkliste des Teams, die zugrunde liegenden Designprinzipien und wie man Diffs in den verwendeten Tools liest. Gestalten Sie diese Phase zeitsparend und in Ihrem eigenen Tempo. Eine kurze Überprüfung der Voraussetzungen bestätigt lediglich die Kenntnis des jeweiligen Teams und ist kein Nachweis für die Review-Kompetenz.
Praxis. Verwenden Sie vorbereitete Änderungen mit einer kleinen Anzahl an eingebauten Problemen unterschiedlicher Art: ein Fehler in der Korrektheit, ein Wartbarkeitsproblem wie die uneinheitlichen Verantwortlichkeiten im Eingangsbeispiel, ein unklarer Name oder ein fehlender Test sowie etwas fehlerfreien Code. Bitten Sie den Reviewer, den Kommentar zu schreiben, den er hinterlassen würde, die Probleme zu priorisieren und anzugeben, welche weiteren Informationen er benötigt. Die praktische Lektion von CodeRefinery zeigt das Vorgehen: Nutzer öffnen einen Pull Request mit einem kleinen Tippfehler und einem größeren Fehler und überprüfen ihn anschließend als Peer (CodeRefinery, Code-Review in der PraxisErstellen Sie Ihre eigene Version auf Basis Ihres eigenen Quellcodes, damit die Konventionen und Kompromisse real sind.
Feedback bekommen. Stellen Sie einen Bezug zu den Entscheidungen des Prüfers her. „Sie haben das Rundungsproblem bemerkt, aber in Ihrem Kommentar hieß es nur ‚Das sieht falsch aus‘, ohne anzugeben, welche Eingabe den Fehler verursacht“ ist hilfreicher als „2 von 4 gefunden“.
Live-Eingabe oder asynchrone Überprüfung? Live-Feedback ist besonders wertvoll, wenn ein Problem unklar ist und die Prüfer von den Erläuterungen eines erfahrenen Entwicklers profitieren, warum er es ansprechen oder ignorieren würde. Für den Vergleich von Kommentaren mit einem kommentierten Expertenbericht reicht eine asynchrone Prüfung aus.
4. Arbeiten Sie ein realistisches Beispiel durch.
Beispielhaft. Ein technischer Leiter sollte den Anwendungsfall und die Antwortkriterien vor der Verwendung prüfen.
Der Fall. Eine Änderung fügt dem Checkout-Prozess eine Rabattberechnung hinzu. Sie hat alle Tests bestanden. In einer Funktion werden prozentuale und feste Rabatte angewendet, das Ergebnis gerundet, in die Datenbank geschrieben und ein Ereignis ausgelöst. Es gibt einen Test für einen einzelnen prozentualen Rabatt.
Die Aufgabe. Der Gutachter verfasst die Kommentare, die er hinterlassen würde, ordnet seine Bedenken nach Priorität und gibt an, welche Informationen er vor einer Genehmigung benötigt.
Ein erster Versuch. „Sieht gut aus, der Test ist bestanden. Vielleicht aufteilen?“ Der Gutachter hat etwas bemerkt, aber nicht gesagt, was, warum es wichtig ist oder was zu tun ist. Der Autor kann darauf nicht reagieren.
Feedback geben und es erneut versuchen. Der Moderator fragt: Welches Risiko birgt eine zukünftige Änderung dieser Funktion? Was würden Sie den Autor bitten, vor Ihrer Genehmigung hinzuzufügen? Im Wiederholungsversuch wird zu jedem Bedenken ein konkreter Kommentar mit Begründung und Verbesserungsvorschlag erbeten.
Ein stärkerer Versuch. Die Funktion wendet zwei Arten von Rabatten an, rundet, speichert und veröffentlicht ein Ereignis. Eine Änderung der Rundung könnte daher die gespeicherten und veröffentlichten Daten gleichzeitig beeinflussen. Ich schlage vor, die Preisregeln in eine separate Funktion auszulagern, die wir eigenständig testen können. Der aktuelle Test deckt nur einen prozentualen Rabatt ab. Ich wünsche mir einen festen Rabatt und eine Bestellung, die den Gesamtbetrag auf null reduziert. Da ich mir nicht sicher bin, ob das Ereignis bei einem Gesamtbetrag von null ausgelöst werden soll, würde ich den Autor fragen. Dieser Kommentar benennt das Problem, nennt den Grund, macht einen konkreten Vorschlag und beschreibt die Wissenslücken des Prüfers.
5. Fähigkeiten einschätzen und Transfer planen
Als Nachweis der Kompetenz dient die Umsetzung einer neuen, dem Gutachter unbekannten Änderung. Bewerten Sie die Genauigkeit der Ergebnisse und die Nützlichkeit der Erklärung. Ein einfaches Bewertungsraster verwendet eine Skala von 0 bis 2 pro Kriterium.
| Kriterium | Sichtbare Beweise |
|---|---|
| Aufgabenausführung | Ermittelt die relevanten Bedenken im Zusammenhang mit der Veränderung und dokumentiert die jeweiligen Belege. |
| Argumentation | Erläutert, warum jedes einzelne Anliegen wichtig ist, bietet eine Alternative an und benennt, was noch unklar ist. |
| Boundaries | Hält sich an die Review-Regeln des Teams und bittet um Hilfe oder Informationen, wenn die Autorität oder der Kontext fehlt. |
Bewertungskriterien: 0 bedeutet fehlend oder nicht begründet, 1 bedeutet teilweise mit relevanten Auslassungen und 2 bedeutet vollständig und anhand vereinbarter Kriterien begründet. Kritische Fehler sollten separat definiert werden, z. B. die Genehmigung einer Änderung mit Datenverlustrisiko, damit ein guter Gesamtscore einen solchen Fehler nicht verschleiert. Die Kriterien sind mit dem technischen Leiter abzustimmen; diese Rubrik ist ein erster Vorschlag, kein validierter Bereitschaftsstandard. Weitere Informationen zur Bewertungsbegründung finden Sie in unserem Leitfaden. Gestaltung interaktiver Übungen mit hilfreichem Feedback.
Planen Sie den Transfer. Überprüfen Sie nach der Übung einige Wochen später anhand derselben Kriterien eine Stichprobe der tatsächlichen Bewertungen des Prüfers. Vergleichen Sie diese mit einer vor der Schulung erhobenen Ausgangsbasis und legen Sie die Zielgruppe und den Zeitraum im Voraus fest. Berücksichtigen Sie vor der Anrechnung der Übungen weitere Änderungen, die im selben Zeitraum stattgefunden haben, wie z. B. ein neues Bewertungstool oder eine Personalveränderung.
6. Führen Sie die Übung live oder in Ihrem eigenen Tempo mit AhaSlides durch.
Sie können die Übung in einem Workshop durchführen oder die Teilnehmer sie selbstständig bearbeiten lassen. In einer Live-Sitzung zeigen Sie die vorbereitete Änderung und verwenden interaktive Folien für die Diskussion:
- Antwort auswählen Bei der Frage „Welches Anliegen würden Sie zuerst ansprechen?“ stehen die vorgegebenen Anliegen als Antwortmöglichkeiten zur Verfügung. Zeigen Sie die Verteilung an, bevor Sie Ihre eigene Rangfolge preisgeben.
- Offen beendet Für „schreiben Sie den Kommentar, den Sie hinterlassen würden“. Rezensenten können ihre Formulierungen mit denen anderer vergleichen, wodurch sich die Fähigkeit zur Erklärung zeigt.
- Bewertungsskala um die Frage „Wie schwerwiegend ist das?“ zu stellen, damit die Gruppe erkennen kann, wo die Einschätzungen voneinander abweichen, und darüber sprechen kann, warum.
Für Gutachter, die nicht teilnehmen können, kann dieselbe Sequenz im Selbststudium genutzt werden, wobei die kommentierte Expertenbewertung nach jeder Antwort angezeigt wird. Behandeln Sie jegliche Aussagen zur Codeausführung, Integrationen oder KI-Funktionen als unbestätigt, bis Sie diese mit Ihrem eigenen Material getestet haben.
Wenn Sie auch Prüfer für KI-generierten Code schulen, lesen Sie unseren Begleitleitfaden zu diesem Thema. KI-generiertes Code-Review-TrainingDer vorherige Beitrag handelte von der Prüfung der erstellten Ergebnisse. Dieser hier handelt davon, wie Menschen die Arbeit anderer überprüfen und wie sie ihre Ergebnisse erläutern.
Einschränkungen, die möglicherweise bestehen bleiben
- Zeit für eine Überprüfung. Ein durchdachter Kommentar braucht länger als „LGTM“, und die Abgabetermine drängen zur Kurzfassung.
- Teamnormen. Wird Feedback als persönliche Kritik verstanden, werden die Gutachter ihre Ergebnisse abschwächen oder ganz fallen lassen.
- Fallabdeckung. Eine Übung verdeutlicht verschiedene Problemfelder. Eine Punktzahl beschreibt nicht generell das Urteil eines Gutachters.
- Übertragung. Die Leistung in einer Werkstatt ist nicht dasselbe wie die Leistung in einer stark frequentierten Warteschlange, daher sollten Sie auch echte Bewertungen berücksichtigen.
Weisen Sie die Sponsoren frühzeitig auf diese Punkte hin und planen Sie separate Korrekturen. Übungen verbessern die Wahrnehmung und Erklärbarkeit der Prüfer. Sie schaffen jedoch weder Zeit noch Normen.
Häufig gestellte Fragen
Was sind Code-Review-Übungen?
Es handelt sich um vorbereitete Übungsaufgaben, in denen ein Entwickler eine Änderung mit bekannten Problemen prüft, die entsprechenden Kommentare verfasst und Feedback zu Richtigkeit und Nützlichkeit erhält. Ziel ist es, die Fähigkeiten des Prüfers zu verbessern, nicht die Änderung zu veröffentlichen.
Wie lässt sich feststellen, ob sich das Urteilsvermögen eines Gutachters verbessert hat?
Geben Sie den Testpersonen eine neue, ihnen unbekannte Änderung und bewerten Sie die Ergebnisse und die Erklärung anhand vereinbarter Kriterien. Überprüfen Sie anschließend einige Wochen später eine Stichprobe echter Bewertungen. Ein Quiz zu den Bewertungsregeln dient lediglich der Bestätigung der Voraussetzungen.
Geht es bei Peer-Code-Reviews hauptsächlich darum, Fehler zu finden?
Das Aufspüren von Fehlern ist nach wie vor ein Hauptmotiv, doch eine Studie bei Microsoft ergab, dass sich Reviews weniger auf Fehler konzentrierten als erwartet und stattdessen Wissensaustausch und Teamverständnis förderten. Es empfiehlt sich, Übungen zu entwickeln, die neben der Fehleranzahl auch Erklärungen und Verständnis belohnen.
Wo soll ich anfangen
Wählen Sie eine Änderungsart, die Ihr Team häufig überprüft. Verfassen Sie die Leistungsbeschreibung, bitten Sie einen erfahrenen Entwickler, eine Änderung mit drei oder vier vorgegebenen Problemen vorzubereiten, und erstellen Sie eine dreistufige Bewertungsmatrix mit einer Skala von 0 bis 2 und einer Liste kritischer Fehler. Testen Sie das Verfahren mit einer kleinen Gruppe und vergleichen Sie anschließend die Ergebnisse der nächsten regulären Überprüfungen mit der Referenzgröße.
Um zu sehen, wie eine Überprüfungsübung live mit Ihrem eigenen Team durchgeführt und anschließend im eigenen Tempo wiederverwendet werden kann, erkunden Sie AhaSlides.
