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 Befähigung von Entwicklern und an Entwicklungsmanager. Er zeigt, wie man Code-Review-Übungen so gestaltet , dass diese Fähigkeit gezielt gefördert wird, anstatt darauf zu hoffen, dass die Reviewer sie von selbst erlernen. Er behandelt das Performance-Problem, die zu analysierenden Lücken, die Strukturierung von Vorbereitung und Übung, ein ausgearbeitetes Beispiel und die Überprüfung, ob die erlernte Fähigkeit in realen Reviews Anwendung findet. 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 legt nahe, über die reine Fehlersuche hinauszudenken. In einer Studie bei Microsoft beobachteten, interviewten und befragten Bacchelli und Bird Entwickler und Manager. Sie stellten fest, dass die Fehlersuche zwar weiterhin die Hauptmotivation für Reviews darstellte, diese aber weniger fehlerbezogen waren als erwartet. Sie lieferten auch weitere Vorteile wie Wissensaustausch, ein besseres Verständnis im Team und alternative Lösungsansätze. Die Forscher beschrieben das Verständnis von Code und Änderungen als zentralen Aspekt von Reviews ( Bacchelli und Bird, ICSE 2013 ). Da es sich um eine Studie mit den Teams eines einzelnen Unternehmens handelt, sollten Sie die Ergebnisse als Anstoß für die Entwicklung verständnisorientierter Reviews nutzen, nicht als Maßstab für Ihre eigenen.
Googles veröffentlichter Review-Standard geht in dieselbe Richtung. Er empfiehlt Reviewern, Änderungen zu genehmigen, sobald diese die allgemeine Codequalität eindeutig verbessern, selbst wenn der Code noch nicht perfekt ist. Außerdem heißt es, dass Reviews Entwicklern Neues beibringen können, weshalb hilfreiche Kommentare willkommen sind ( Google Engineering Practices ). Beide Quellen beschreiben Reviews als einen Ort, an dem Urteilsvermögen geübt und Feedback 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 Erinnerungsprüfung bestätigt lediglich die Voraussetzungen und ist kein Nachweis für die Review-Kompetenz.
Üben Sie. Verwenden Sie vorbereitete Änderungen mit einer kleinen Anzahl an potenziellen Problemen unterschiedlicher Art: einen Fehler in der Korrektheit, ein Wartbarkeitsproblem wie die unklaren Verantwortlichkeiten im Eingangsbeispiel, einen unklaren Namen oder einen fehlenden Test sowie fehlerfreien Code. Bitten Sie den Reviewer, seinen Kommentar zu verfassen, die Probleme zu priorisieren und anzugeben, welche weiteren Informationen er benötigt. Die praktische Anleitung von CodeRefinery veranschaulicht das Vorgehen: Nutzer erstellen einen Pull Request mit einem kleinen Tippfehler und einem größeren Fehler und überprüfen ihn anschließend als Peer ( CodeRefinery, Code-Review üben ). Erstellen Sie Ihre Anleitung anhand Ihrer eigenen Codebasis, damit die Konventionen und Abwägungen real sind.
Feedback. Stellen Sie einen Bezug zu den Entscheidungen des Prüfers her. „Sie haben das Rundungsproblem bemerkt, aber Ihr Kommentar lautete ‚Das sieht falsch aus‘, ohne anzugeben, welche Eingabe den Fehler verursacht“ ist hilfreicher als „2 von 4 gefunden“.
Live-Feedback 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. Eine asynchrone Überprüfung reicht aus, um Kommentare mit einer kommentierten Expertenprüfung zu vergleichen.
4. Arbeiten Sie ein realistisches Beispiel durch.
Beispielhaft. Ein technischer Leiter sollte den Anwendungsfall und die Antwortkriterien vor der Verwendung prüfen.
Fallbeispiel: Eine Änderung fügt einem Checkout-System eine Rabattberechnung hinzu. Sie besteht ihre Tests. 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 der 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 und erneuter Versuch. Der Moderator fragt: Welches Risiko birgt eine zukünftige Änderung dieser Funktion? Was würden Sie den Autor bitten, vor Ihrer Freigabe hinzuzufügen? Im nächsten Schritt wird zu jedem Problem ein konkreter Kommentar mit Begründung und Verbesserungsvorschlag erbeten.
Ein überzeugenderer 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. Ich bin mir nicht sicher, ob das Ereignis bei einem Gesamtbetrag von null ausgelöst werden soll, und würde daher den Autor fragen.“ Beachten Sie, dass dieser Kommentar das Problem benennt, den Grund angibt, einen konkreten Vorschlag macht und darlegt, was dem Prüfer unklar ist.
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 Bewertungsmatrix ist ein erster Vorschlag, kein validierter Bereitschaftsstandard. Weitere Informationen zur Begründung der Bewertung finden Sie in unserem Leitfaden zur 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 anhand von KI-generiertem Code schulen, lesen Sie unseren Begleitleitfaden zum Training von KI-generierten Code-Reviews . Dort geht es um die Prüfung der generierten Ausgabe. Dieser Beitrag hier behandelt, wie Menschen die Arbeit anderer prüfen und 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.
