Critique – wie Google mit 97 % Entwicklerzufriedenheit den Schmerz von Code-Reviews lindert

xguru · 2023-12-11T10:32:02+09:00

Viele Ex-Googler vermissen Googles Code-Review-Tool "Critique" Laut einer internen Umfrage bei Google sind 97 % der Entwickler mit Critique zufrieden Googles Richtlinien für Code-Reviews Kontinuierliche Verbesserung statt Perfektion fördern Den Zustand der Codebasis erhalten oder verbessern Dem Styleguide folgen Wissen immer teilen: Code-Reviews fördern den Austausch von Wissen über Sprachfeatures, die Codebasis und andere relevante Artefakte Änderungen klein halten (etwa 200 Zeilen) Strenge Standards für Leichtgewichtigkeit (Codeänderungen innerhalb von 24 Stunden prüfen, möglichst nur ein Reviewer) Höflichkeit und Professionalität: Eine Kultur des Vertrauens und Respekts aufrechtzuerhalten ist wichtig Critique: Googles Code-Review-Tool Ermöglicht es Engineers, Codeänderungen effizient zu prüfen und zur Einreichung vorzubereiten Laut dem jüngsten Paper – Resolving code review comments with ML verwendet Google ein umfassendes AI-basiertes Code-Review-Tool Wenn ein Reviewer einen Kommentar im Code hinterlässt, zeigt Critique ML-basierte Bearbeitungsvorschläge an Der Autor des Code-Reviews kann den betreffenden Kommentar mit nur einem Klick im gesamten Umfang korrigieren Ablauf eines Code-Reviews Schritt 1: Änderung erstellen Ein CL (oder Pull Request) wird in Googles internem Code-Editor Cider erstellt Er ist eng mit Critique und anderen internen Google-Tools integriert und steigert so die Produktivität der Entwickler Prereview-Tool: Verfeinert Änderungen vor dem Review und zeigt Diffs, Build- und Testergebnisse sowie Style-Prüfungen an Diff-Ansicht und Visualisierung: Syntax-Highlighting, Cross-References, Intraline-Diffing, Ignorieren von Whitespace und Move-Erkennung Zeigt Ergebnisse von Static Analyzern an, hebt wichtige Resultate hervor und bietet Korrekturvorschläge. Einschließlich automatisierter Tests namens "presubmits", die innerhalb von Critique ausgeführt werden Schritt 2: Review anfordern Wenn der Pull Request zur Prüfung bereit ist, fügt der Autor Reviewer hinzu und sendet ihn formell zur Begutachtung Wenn ein PR/CL zur Prüfung gesendet wird, werden "Presubmits" ausgeführt, falls sie für den aktuellen Code-Snapshot noch nicht vorhanden sind. So können alle Beteiligten sehen, ob es Probleme im Code gibt Code-Reviews können auch anonymisiert werden, sodass der Autor gegenüber dem Reviewer anonym bleibt. Google hat jedoch keinen nützlichen Unterschied zwischen anonymen und "echten" Code-Reviews festgestellt Schritt 3 und 4: Änderungen verstehen und kommentieren Jeder kann Änderungen kommentieren, und es gibt Funktionen zum Verfolgen des Review-Fortschritts und zum Auflösen von Kommentaren Nicht aufgelöste Kommentare stehen für Aufgabenpunkte, die der Autor der Änderung definitiv bearbeiten muss. Solche Kommentare können als "gelöst" markiert werden, wenn der Autor direkt darauf antwortet Gelöste Kommentare umfassen optionale oder informative Anmerkungen, die möglicherweise keine Aktion des Autors erfordern Es gibt ein Dashboard zum Prüfen des Review-Status sowie ein "Attention Set", mit dem die Beteiligten eines bestimmten Code-Reviews sehen können, wer gerade an der Reihe ist Schritt 5: Änderung genehmigen Wie oben erwähnt, muss ein Review mindestens ein LGTM (Looks Good To Me) von einem Reviewer erhalten, damit es akzeptiert wird Der Autor kann Kommentare beim Kommentieren zwar direkt als gelöst markieren, es müssen aber 0 ungelöste Kommentare verbleiben Zusätzlich sind die Freigabe des Owners des betroffenen Teils der Codebasis sowie eine Lesbarkeitsfreigabe erforderlich All das kann von einem einzigen Reviewer erledigt werden Schritt 6: Änderung committen Änderungen können direkt in Critique eingereicht und committet werden Critique bleibt auch nach dem Einreichen der Änderungen nützlich "Google-Forscher fanden starke Hinweise darauf, dass der Einsatzzweck von Critique über Code-Reviews hinausgeht. Autoren von Änderungen verwenden Critique, um Diffs zu prüfen und Ergebnisse von Analyse-Tools nachzuschlagen. In manchen Fällen ist Code-Review Teil des Entwicklungsprozesses einer Änderung, wobei Reviewer unvollständige Änderungen senden können, um zu entscheiden, wie die Implementierung abgeschlossen werden soll. Außerdem nutzen Entwickler Critique auch nach der Genehmigung einer Änderung, um die Historie eingereichter Änderungen zu überprüfen." Googles aktuelle Statistiken zu Code-Reviews Häufigkeit beim Erstellen von Änderungen: Median: 3 Änderungen pro Woche 80 % der Autoren nehmen pro Woche weniger als 7 Änderungen vor Review-Häufigkeit: Median: 4 Änderungen pro Woche reviewen 80 % der Reviewer bearbeiten pro Woche weniger als 10 Änderungen Pro Woche für Reviews aufgewendete Zeit: Durchschnittlich 3,2 Stunden pro Woche Median 2,6 Stunden pro Woche Wartezeit bis zum ersten Feedback: Kleine Änderungen: durchschnittlich weniger als 1 Stunde Sehr große Änderungen: etwa 5 Stunden Dauer des gesamten Review-Prozesses: Durchschnittliche Verzögerung über alle Codegrößen hinweg: weniger als 4 Stunden Vergleich mit anderen Unternehmen: AMD: 17,5 Stunden (Median bis zur Freigabe) Chrome OS: 15,7 Stunden Microsoft-Projekte: 14,7 Stunden, 19,8 Stunden, 18,9 Stunden Microsoft (andere Studie): 24 Stunden Warum lieben Googler Critique? Statische Analyse: Es gibt eine vollständige Suite von Static-Analysis-Tools, die automatisch umsetzbares Feedback zum Code liefern. Das spart sowohl dem Autor als auch dem Reviewer Zeit, und Reviewer müssen offensichtliche Punkte nicht einzeln anmerken Fokus nur auf die zuletzt geänderten Dateien: Man kann sich nur auf den neuesten "Snapshot" des Codes konzentrieren. Frühere Snapshots, Commits und Codeänderungen werden nicht angezeigt, wodurch die Benutzeroberfläche aufgeräumter ist Vertraute Side-by-Side-Diff-Oberfläche: Standardmäßig wird "Unterschiede seit dem letzten Review" angezeigt Machine-Learning-basierte Vorschläge: Googles neue ML-basierten Vorschlagsfunktionen beschleunigen Code-Reviews enorm Enge Integration mit anderen Google-Tools: Critique ist sehr gut mit anderen internen Tools wie Googles IDE und Bug-Tracker integriert, was die Produktivität steigert. Dazu gehört auch die einfache Verknüpfung von Code, Kommentaren und Tickets Verfolgung des "Work Set": Man kann sehen, wer als Nächstes handeln muss Befriedigende Gamification: Critique wurde zwar nicht als gamifiziertes Tool entworfen, aber Googler berichten, dass es Spaß machte, wenn Critique "grün wurde" und der PR bereit zum Einreichen war (alle Tests bestanden, LGTM-Freigabe durch Reviewer) Kommentare auf Reddit Erstaunliche Tastaturkürzel, mit denen sich riesige Mengen Code sehr effizient reviewen lassen Zeigt standardmäßig "Unterschiede zum letzten Review" an Die Funktion zur "Code Move Detection" hilft dabei, sich auf die tatsächlichen Änderungen im Code zu konzentrieren Bietet großartige Funktionen, die zeigen, wer als Nächstes aktiv werden muss – Reviewer oder Autor In Kombination mit einer Chrome-Erweiterung lassen sich Benachrichtigungen leicht erhalten und die Review-Warteschlange prüfen Intern kann jeder Abfragen auf Code-Review-Daten ausführen und daraus Insights gewinnen Automatische Verknüpfung von Code und Kommentaren (einschließlich Tickets und Verschiebungen/Links) Analyse, Historie und Kommentare eines PR mit mehreren Review-Runden lassen sich tabellarisch anzeigen, wodurch sich der Fortschritt viel leichter verstehen lässt Die Terminologie/Tags für Kommentare wie optional, Hinweis usw. sind sehr konsistent Gedanken und Implikationen Viele dieser Funktionen sind heute auch in anderen Tools verfügbar, aber ich denke, dieses Tool wird vor allem wegen seiner engen Integration in Googles eigene Workflows und Codebasis sowie seiner extremen "Personalisierung" geschätzt Gleichzeitig bedeutet das auch, dass es für andere Unternehmen praktisch unmöglich ist, Critique und die zugehörigen Tools exakt zu kopieren. Einige Tools sind zum Beispiel speziell auf Probleme ausgelegt, die durch eine Monorepo-Struktur entstehen Critique selbst wird wahrscheinlich nicht als Open Source veröffentlicht, aber Gerrit ist ein Critique ähnliches Tool. Auch das ist ein von Google entwickeltes und gepflegtes Open-Source-Code-Review-Tool Ich denke aber, dass Google sehr viel Aufwand und Überlegung in die Produktivität seiner Entwickler steckt. Das Unternehmen veröffentlicht seine Forschung offen, und man kann aus seiner Arbeit nützliche Erkenntnisse gewinnen

(engineercodex.substack.com)

52 Punkte von xguru 2023-12-11 | 5 Kommentare | Auf WhatsApp teilen

Viele Ex-Googler vermissen Googles Code-Review-Tool "Critique"
Laut einer internen Umfrage bei Google sind 97 % der Entwickler mit Critique zufrieden

Googles Richtlinien für Code-Reviews

Kontinuierliche Verbesserung statt Perfektion fördern
Den Zustand der Codebasis erhalten oder verbessern
Dem Styleguide folgen
Wissen immer teilen: Code-Reviews fördern den Austausch von Wissen über Sprachfeatures, die Codebasis und andere relevante Artefakte
Änderungen klein halten (etwa 200 Zeilen)
Strenge Standards für Leichtgewichtigkeit (Codeänderungen innerhalb von 24 Stunden prüfen, möglichst nur ein Reviewer)
Höflichkeit und Professionalität: Eine Kultur des Vertrauens und Respekts aufrechtzuerhalten ist wichtig

Critique: Googles Code-Review-Tool

Ermöglicht es Engineers, Codeänderungen effizient zu prüfen und zur Einreichung vorzubereiten
Laut dem jüngsten Paper – Resolving code review comments with ML verwendet Google ein umfassendes AI-basiertes Code-Review-Tool
- Wenn ein Reviewer einen Kommentar im Code hinterlässt, zeigt Critique ML-basierte Bearbeitungsvorschläge an
- Der Autor des Code-Reviews kann den betreffenden Kommentar mit nur einem Klick im gesamten Umfang korrigieren

Ablauf eines Code-Reviews

Schritt 1: Änderung erstellen
- Ein CL (oder Pull Request) wird in Googles internem Code-Editor Cider erstellt
- Er ist eng mit Critique und anderen internen Google-Tools integriert und steigert so die Produktivität der Entwickler
- Prereview-Tool: Verfeinert Änderungen vor dem Review und zeigt Diffs, Build- und Testergebnisse sowie Style-Prüfungen an
- Diff-Ansicht und Visualisierung: Syntax-Highlighting, Cross-References, Intraline-Diffing, Ignorieren von Whitespace und Move-Erkennung
- Zeigt Ergebnisse von Static Analyzern an, hebt wichtige Resultate hervor und bietet Korrekturvorschläge. Einschließlich automatisierter Tests namens "presubmits", die innerhalb von Critique ausgeführt werden
Schritt 2: Review anfordern
- Wenn der Pull Request zur Prüfung bereit ist, fügt der Autor Reviewer hinzu und sendet ihn formell zur Begutachtung
- Wenn ein PR/CL zur Prüfung gesendet wird, werden "Presubmits" ausgeführt, falls sie für den aktuellen Code-Snapshot noch nicht vorhanden sind. So können alle Beteiligten sehen, ob es Probleme im Code gibt
- Code-Reviews können auch anonymisiert werden, sodass der Autor gegenüber dem Reviewer anonym bleibt. Google hat jedoch keinen nützlichen Unterschied zwischen anonymen und "echten" Code-Reviews festgestellt
Schritt 3 und 4: Änderungen verstehen und kommentieren
- Jeder kann Änderungen kommentieren, und es gibt Funktionen zum Verfolgen des Review-Fortschritts und zum Auflösen von Kommentaren
- Nicht aufgelöste Kommentare stehen für Aufgabenpunkte, die der Autor der Änderung definitiv bearbeiten muss. Solche Kommentare können als "gelöst" markiert werden, wenn der Autor direkt darauf antwortet
- Gelöste Kommentare umfassen optionale oder informative Anmerkungen, die möglicherweise keine Aktion des Autors erfordern
- Es gibt ein Dashboard zum Prüfen des Review-Status sowie ein "Attention Set", mit dem die Beteiligten eines bestimmten Code-Reviews sehen können, wer gerade an der Reihe ist
Schritt 5: Änderung genehmigen
- Wie oben erwähnt, muss ein Review mindestens ein LGTM (Looks Good To Me) von einem Reviewer erhalten, damit es akzeptiert wird
- Der Autor kann Kommentare beim Kommentieren zwar direkt als gelöst markieren, es müssen aber 0 ungelöste Kommentare verbleiben
- Zusätzlich sind die Freigabe des Owners des betroffenen Teils der Codebasis sowie eine Lesbarkeitsfreigabe erforderlich
- All das kann von einem einzigen Reviewer erledigt werden
Schritt 6: Änderung committen
- Änderungen können direkt in Critique eingereicht und committet werden
- Critique bleibt auch nach dem Einreichen der Änderungen nützlich
- "Google-Forscher fanden starke Hinweise darauf, dass der Einsatzzweck von Critique über Code-Reviews hinausgeht. Autoren von Änderungen verwenden Critique, um Diffs zu prüfen und Ergebnisse von Analyse-Tools nachzuschlagen. In manchen Fällen ist Code-Review Teil des Entwicklungsprozesses einer Änderung, wobei Reviewer unvollständige Änderungen senden können, um zu entscheiden, wie die Implementierung abgeschlossen werden soll. Außerdem nutzen Entwickler Critique auch nach der Genehmigung einer Änderung, um die Historie eingereichter Änderungen zu überprüfen."

Googles aktuelle Statistiken zu Code-Reviews

Häufigkeit beim Erstellen von Änderungen:
- Median: 3 Änderungen pro Woche
- 80 % der Autoren nehmen pro Woche weniger als 7 Änderungen vor
Review-Häufigkeit:
- Median: 4 Änderungen pro Woche reviewen
- 80 % der Reviewer bearbeiten pro Woche weniger als 10 Änderungen
Pro Woche für Reviews aufgewendete Zeit:
- Durchschnittlich 3,2 Stunden pro Woche
- Median 2,6 Stunden pro Woche
Wartezeit bis zum ersten Feedback:
- Kleine Änderungen: durchschnittlich weniger als 1 Stunde
- Sehr große Änderungen: etwa 5 Stunden
Dauer des gesamten Review-Prozesses:
- Durchschnittliche Verzögerung über alle Codegrößen hinweg: weniger als 4 Stunden
- Vergleich mit anderen Unternehmen:
  - AMD: 17,5 Stunden (Median bis zur Freigabe)
  - Chrome OS: 15,7 Stunden
  - Microsoft-Projekte: 14,7 Stunden, 19,8 Stunden, 18,9 Stunden
  - Microsoft (andere Studie): 24 Stunden

Warum lieben Googler Critique?

Statische Analyse: Es gibt eine vollständige Suite von Static-Analysis-Tools, die automatisch umsetzbares Feedback zum Code liefern. Das spart sowohl dem Autor als auch dem Reviewer Zeit, und Reviewer müssen offensichtliche Punkte nicht einzeln anmerken
Fokus nur auf die zuletzt geänderten Dateien: Man kann sich nur auf den neuesten "Snapshot" des Codes konzentrieren. Frühere Snapshots, Commits und Codeänderungen werden nicht angezeigt, wodurch die Benutzeroberfläche aufgeräumter ist
Vertraute Side-by-Side-Diff-Oberfläche: Standardmäßig wird "Unterschiede seit dem letzten Review" angezeigt
Machine-Learning-basierte Vorschläge: Googles neue ML-basierten Vorschlagsfunktionen beschleunigen Code-Reviews enorm
Enge Integration mit anderen Google-Tools: Critique ist sehr gut mit anderen internen Tools wie Googles IDE und Bug-Tracker integriert, was die Produktivität steigert. Dazu gehört auch die einfache Verknüpfung von Code, Kommentaren und Tickets
Verfolgung des "Work Set": Man kann sehen, wer als Nächstes handeln muss
Befriedigende Gamification: Critique wurde zwar nicht als gamifiziertes Tool entworfen, aber Googler berichten, dass es Spaß machte, wenn Critique "grün wurde" und der PR bereit zum Einreichen war (alle Tests bestanden, LGTM-Freigabe durch Reviewer)
Kommentare auf Reddit
- Erstaunliche Tastaturkürzel, mit denen sich riesige Mengen Code sehr effizient reviewen lassen
- Zeigt standardmäßig "Unterschiede zum letzten Review" an
- Die Funktion zur "Code Move Detection" hilft dabei, sich auf die tatsächlichen Änderungen im Code zu konzentrieren
- Bietet großartige Funktionen, die zeigen, wer als Nächstes aktiv werden muss – Reviewer oder Autor
- In Kombination mit einer Chrome-Erweiterung lassen sich Benachrichtigungen leicht erhalten und die Review-Warteschlange prüfen
- Intern kann jeder Abfragen auf Code-Review-Daten ausführen und daraus Insights gewinnen
- Automatische Verknüpfung von Code und Kommentaren (einschließlich Tickets und Verschiebungen/Links)
- Analyse, Historie und Kommentare eines PR mit mehreren Review-Runden lassen sich tabellarisch anzeigen, wodurch sich der Fortschritt viel leichter verstehen lässt
- Die Terminologie/Tags für Kommentare wie optional, Hinweis usw. sind sehr konsistent

Gedanken und Implikationen

Viele dieser Funktionen sind heute auch in anderen Tools verfügbar, aber ich denke, dieses Tool wird vor allem wegen seiner engen Integration in Googles eigene Workflows und Codebasis sowie seiner extremen "Personalisierung" geschätzt
Gleichzeitig bedeutet das auch, dass es für andere Unternehmen praktisch unmöglich ist, Critique und die zugehörigen Tools exakt zu kopieren. Einige Tools sind zum Beispiel speziell auf Probleme ausgelegt, die durch eine Monorepo-Struktur entstehen
Critique selbst wird wahrscheinlich nicht als Open Source veröffentlicht, aber Gerrit ist ein Critique ähnliches Tool. Auch das ist ein von Google entwickeltes und gepflegtes Open-Source-Code-Review-Tool
Ich denke aber, dass Google sehr viel Aufwand und Überlegung in die Produktivität seiner Entwickler steckt. Das Unternehmen veröffentlicht seine Forschung offen, und man kann aus seiner Arbeit nützliche Erkenntnisse gewinnen

5 Kommentare

xguru 2023-12-17

Es scheint tatsächlich Versuche zu geben, ChatGPT an Gerrit anzubinden.
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

Am stärksten fällt mir auf, dass man in Critique eine Reihe zusammenhängender CLs reviewen kann. Auf GitHub ist es umständlich, dass PR-Ketten nicht direkt unterstützt werden. Deshalb wird es entweder ein einzelner großer PR, oder man muss warten, bis der vorherige PR gemergt ist.

tested 2023-12-11

GitHub hat auch etwas Ähnliches; wann es veröffentlicht wird, ist noch offen
> https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

Es gibt zwar keine statische Analyse und keine ML-basierten Vorschläge, aber dem Artikel nach wirkt es GitHubs Review-Funktion doch ziemlich ähnlich. Aus der Perspektive von jemandem, der GitHub-Reviews häufig nutzt, wäre es schön, wenn auch die anderen Funktionen von Critique stärker übernommen würden.

xguru 2023-12-11

Googles Leitfaden für Code-Reviews [koreanische Übersetzung]