Critique - comment Google soulage la douleur du code review avec 97 % de satisfaction chez les développeurs

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

Beaucoup d’anciens de Google regrettent l’outil de code review de Google, « Critique » D’après une enquête interne chez Google, 97 % des développeurs se disent satisfaits de Critique Les lignes directrices de Google pour le code review Encourager l’amélioration continue plutôt que la perfection Maintenir ou améliorer l’état de la codebase Suivre le guide de style Toujours partager les connaissances : le code review encourage le partage de connaissances sur les fonctionnalités du langage, la codebase et d’autres artefacts associés Faire de petits changements (environ 200 lignes) Des critères stricts de légèreté : examiner les changements de code dans les 24 heures, avec si possible un seul reviewer Politesse et professionnalisme : il est important de maintenir une culture de confiance et de respect Critique : l’outil de code review de Google Il permet aux ingénieurs d’examiner efficacement les changements de code et de les soumettre Selon un article récent - Resolving code review comments with ML, Google utilise un outil complet de code review basé sur l’IA Lorsqu’un reviewer laisse un commentaire sur le code, Critique affiche des suggestions d’édition basées sur le ML L’auteur du code review peut appliquer une correction globale liée à ce commentaire d’un simple clic Flux du code review Étape 1 : rédiger le changement Le CL (ou Pull Request) est rédigé dans l’éditeur de code interne de Google, Cider Il est étroitement intégré à Critique et à d’autres outils internes Google pour améliorer la productivité des développeurs Outil de prereview : il affine les changements avant review et affiche les diffs, les résultats de build et de tests, ainsi que les vérifications de style Vue diff et visualisation : coloration syntaxique, références croisées, diff intralignes, option pour ignorer les espaces et détection des déplacements de code Affiche les résultats des analyseurs statiques pour mettre en évidence les éléments importants et proposer des corrections. Cela inclut les « presubmits », des tests automatisés exécutés dans Critique Étape 2 : demander une review Quand la pull request est prête à être revue, l’auteur du code ajoute des reviewers et l’envoie officiellement en review Quand la PR/CL est envoyée en review, les « Presubmits » sont exécutés s’ils ne l’ont pas encore été sur le snapshot actuel du code. Ainsi, toutes les personnes impliquées dans la review peuvent savoir si le code pose problème Il est aussi possible d’anonymiser le code review pour garder l’auteur anonyme vis-à-vis des reviewers. Mais Google n’a pas constaté de différence utile entre un code review anonyme et un code review « réel » Étapes 3 et 4 : comprendre les changements et commenter Tout le monde peut commenter les changements, avec des fonctions pour suivre l’avancement de la review et résoudre les commentaires Les commentaires non résolus représentent des éléments d’action que l’auteur du changement doit clairement traiter. Ils peuvent être marqués comme « résolus » lorsque l’auteur répond directement au commentaire Les commentaires résolus peuvent inclure des remarques optionnelles ou informatives qui ne nécessitent pas forcément d’action de la part de l’auteur Il existe un tableau de bord pour vérifier l’état des reviews et un « Attention Set » permettant aux participants d’une review donnée de savoir qui est actuellement en attente d’action Étape 5 : approuver le changement Comme mentionné plus haut, pour qu’une review soit validée, il faut obtenir au moins un LGTM (Looks Good To Me) d’un reviewer L’auteur peut marquer directement comme résolus les commentaires qu’il a lui-même traités, mais il doit rester 0 commentaire non résolu Il faut aussi l’approbation du propriétaire de la partie de la codebase concernée ainsi qu’une approbation de lisibilité Tout cela peut être assuré par un seul reviewer Étape 6 : commit du changement Les changements peuvent être soumis et commités directement dans Critique Critique reste utile même après la soumission du changement « Les chercheurs de Google ont trouvé des preuves solides que l’usage de Critique va au-delà du code review. Les auteurs de changements utilisent Critique pour examiner les diffs et consulter les résultats des outils d’analyse. Dans certains cas, le code review fait partie du processus de développement du changement, et les reviewers peuvent recevoir des changements incomplets afin de décider comment finaliser l’implémentation. Les développeurs utilisent aussi Critique après l’approbation d’un changement pour examiner l’historique des modifications soumises. » Les statistiques les plus récentes de Google sur le code review Fréquence de création de changements : Médiane : 3 changements par semaine 80 % des auteurs effectuent moins de 7 changements par semaine Fréquence des reviews : Médiane : review de 4 changements par semaine 80 % des reviewers traitent moins de 10 changements par semaine Temps consacré aux reviews par semaine : Moyenne : 3,2 heures par semaine Médiane : 2,6 heures par semaine Temps d’attente avant le premier feedback : Petits changements : moins d’1 heure en moyenne Très gros changements : environ 5 heures Durée totale du processus de review : Délai moyen, toutes tailles de code confondues : moins de 4 heures Comparaison avec d’autres entreprises : AMD : 17,5 heures (temps médian jusqu’à l’approbation) Chrome OS : 15,7 heures Projets Microsoft : 14,7 heures, 19,8 heures, 18,9 heures Microsoft (autre étude) : 24 heures Pourquoi les Googlers adorent Critique Analyse statique : Google dispose d’une suite complète d’outils d’analyse statique qui fournissent automatiquement un feedback exploitable sur le code. Cela fait gagner du temps à la fois à l’auteur et au reviewer, qui n’a pas besoin de signaler un par un les points évidents Concentration uniquement sur les fichiers modifiés les plus récents : on peut se focaliser uniquement sur le dernier « snapshot » du code. Les snapshots précédents, commits et changements antérieurs ne sont pas affichés, ce qui rend l’interface plus propre Interface side-by-side diff familière : par défaut, elle affiche les « différences depuis la dernière review » Suggestions basées sur le machine learning : la nouvelle fonction de suggestion ML de Google accélère énormément le code review Intégration étroite avec d’autres outils Google : Critique s’intègre très bien avec d’autres outils internes comme l’IDE de Google et le bug tracker, ce qui améliore la productivité. Cela inclut des liens faciles entre code, commentaires et tickets Suivi du « work set » : permet de savoir qui doit agir ensuite Gamification satisfaisante : Critique n’a pas été conçu comme un produit gamifié, mais les Googlers racontent qu’il était très agréable de voir Critique « passer au vert » quand la PR était prête à être soumise (tous les tests passés, LGTM du reviewer obtenu) Commentaires vus sur Reddit Des raccourcis clavier incroyables pour reviewer énormément de code de manière très efficace Affiche par défaut ce qui a changé « depuis la dernière review » La fonction de « détection des déplacements de code » permet de se concentrer sur les véritables changements Offre une excellente fonction indiquant qui doit agir, que l’on soit reviewer ou auteur Utilisé avec une extension Chrome, il est facile de recevoir des notifications et de consulter sa file de reviews En interne, tout le monde peut lancer des requêtes sur les données de code review pour en tirer des insights Liaison automatique entre le code et les commentaires (y compris avec tickets et déplacements/liens) Pour les PR comportant plusieurs rounds de code, il est bien plus facile de comprendre la progression grâce à une vue tabulaire de l’analyse de la PR, de son historique et des commentaires Les termes/tags des commentaires, comme optionnel ou remarque, sont très cohérents Réflexions et enseignements Beaucoup de ces fonctionnalités existent aujourd’hui dans d’autres outils, mais si celui-ci est autant apprécié, c’est probablement grâce à son intégration étroite et à son extrême « personnalisation » pour le workflow et la codebase propres à Google En même temps, cela signifie aussi qu’il est irréaliste pour toutes les entreprises de reproduire exactement Critique et ses outils associés. Par exemple, certains outils sont spécialisés dans des problèmes liés à une structure en monorepo Critique lui-même ne sera sans doute pas proposé en open source, mais Gerrit est un outil similaire à Critique. C’est lui aussi un outil open source de code review créé et maintenu par Google Mais Google semble investir beaucoup d’efforts et de réflexion dans la productivité des développeurs. L’entreprise publie librement ses recherches, et il est possible d’en tirer des enseignements utiles

(engineercodex.substack.com)

52 points par xguru 2023-12-11 | 5 commentaires | Partager sur WhatsApp

Beaucoup d’anciens de Google regrettent l’outil de code review de Google, « Critique »
D’après une enquête interne chez Google, 97 % des développeurs se disent satisfaits de Critique

Les lignes directrices de Google pour le code review

Encourager l’amélioration continue plutôt que la perfection
Maintenir ou améliorer l’état de la codebase
Suivre le guide de style
Toujours partager les connaissances : le code review encourage le partage de connaissances sur les fonctionnalités du langage, la codebase et d’autres artefacts associés
Faire de petits changements (environ 200 lignes)
Des critères stricts de légèreté : examiner les changements de code dans les 24 heures, avec si possible un seul reviewer
Politesse et professionnalisme : il est important de maintenir une culture de confiance et de respect

Critique : l’outil de code review de Google

Il permet aux ingénieurs d’examiner efficacement les changements de code et de les soumettre
Selon un article récent - Resolving code review comments with ML, Google utilise un outil complet de code review basé sur l’IA
- Lorsqu’un reviewer laisse un commentaire sur le code, Critique affiche des suggestions d’édition basées sur le ML
- L’auteur du code review peut appliquer une correction globale liée à ce commentaire d’un simple clic

Flux du code review

Étape 1 : rédiger le changement
- Le CL (ou Pull Request) est rédigé dans l’éditeur de code interne de Google, Cider
- Il est étroitement intégré à Critique et à d’autres outils internes Google pour améliorer la productivité des développeurs
- Outil de prereview : il affine les changements avant review et affiche les diffs, les résultats de build et de tests, ainsi que les vérifications de style
- Vue diff et visualisation : coloration syntaxique, références croisées, diff intralignes, option pour ignorer les espaces et détection des déplacements de code
- Affiche les résultats des analyseurs statiques pour mettre en évidence les éléments importants et proposer des corrections. Cela inclut les « presubmits », des tests automatisés exécutés dans Critique
Étape 2 : demander une review
- Quand la pull request est prête à être revue, l’auteur du code ajoute des reviewers et l’envoie officiellement en review
- Quand la PR/CL est envoyée en review, les « Presubmits » sont exécutés s’ils ne l’ont pas encore été sur le snapshot actuel du code. Ainsi, toutes les personnes impliquées dans la review peuvent savoir si le code pose problème
- Il est aussi possible d’anonymiser le code review pour garder l’auteur anonyme vis-à-vis des reviewers. Mais Google n’a pas constaté de différence utile entre un code review anonyme et un code review « réel »
Étapes 3 et 4 : comprendre les changements et commenter
- Tout le monde peut commenter les changements, avec des fonctions pour suivre l’avancement de la review et résoudre les commentaires
- Les commentaires non résolus représentent des éléments d’action que l’auteur du changement doit clairement traiter. Ils peuvent être marqués comme « résolus » lorsque l’auteur répond directement au commentaire
- Les commentaires résolus peuvent inclure des remarques optionnelles ou informatives qui ne nécessitent pas forcément d’action de la part de l’auteur
- Il existe un tableau de bord pour vérifier l’état des reviews et un « Attention Set » permettant aux participants d’une review donnée de savoir qui est actuellement en attente d’action
Étape 5 : approuver le changement
- Comme mentionné plus haut, pour qu’une review soit validée, il faut obtenir au moins un LGTM (Looks Good To Me) d’un reviewer
- L’auteur peut marquer directement comme résolus les commentaires qu’il a lui-même traités, mais il doit rester 0 commentaire non résolu
- Il faut aussi l’approbation du propriétaire de la partie de la codebase concernée ainsi qu’une approbation de lisibilité
- Tout cela peut être assuré par un seul reviewer
Étape 6 : commit du changement
- Les changements peuvent être soumis et commités directement dans Critique
- Critique reste utile même après la soumission du changement
- « Les chercheurs de Google ont trouvé des preuves solides que l’usage de Critique va au-delà du code review. Les auteurs de changements utilisent Critique pour examiner les diffs et consulter les résultats des outils d’analyse. Dans certains cas, le code review fait partie du processus de développement du changement, et les reviewers peuvent recevoir des changements incomplets afin de décider comment finaliser l’implémentation. Les développeurs utilisent aussi Critique après l’approbation d’un changement pour examiner l’historique des modifications soumises. »

Les statistiques les plus récentes de Google sur le code review

Fréquence de création de changements :
- Médiane : 3 changements par semaine
- 80 % des auteurs effectuent moins de 7 changements par semaine
Fréquence des reviews :
- Médiane : review de 4 changements par semaine
- 80 % des reviewers traitent moins de 10 changements par semaine
Temps consacré aux reviews par semaine :
- Moyenne : 3,2 heures par semaine
- Médiane : 2,6 heures par semaine
Temps d’attente avant le premier feedback :
- Petits changements : moins d’1 heure en moyenne
- Très gros changements : environ 5 heures
Durée totale du processus de review :
- Délai moyen, toutes tailles de code confondues : moins de 4 heures
- Comparaison avec d’autres entreprises :
  - AMD : 17,5 heures (temps médian jusqu’à l’approbation)
  - Chrome OS : 15,7 heures
  - Projets Microsoft : 14,7 heures, 19,8 heures, 18,9 heures
  - Microsoft (autre étude) : 24 heures

Pourquoi les Googlers adorent Critique

Analyse statique : Google dispose d’une suite complète d’outils d’analyse statique qui fournissent automatiquement un feedback exploitable sur le code. Cela fait gagner du temps à la fois à l’auteur et au reviewer, qui n’a pas besoin de signaler un par un les points évidents
Concentration uniquement sur les fichiers modifiés les plus récents : on peut se focaliser uniquement sur le dernier « snapshot » du code. Les snapshots précédents, commits et changements antérieurs ne sont pas affichés, ce qui rend l’interface plus propre
Interface side-by-side diff familière : par défaut, elle affiche les « différences depuis la dernière review »
Suggestions basées sur le machine learning : la nouvelle fonction de suggestion ML de Google accélère énormément le code review
Intégration étroite avec d’autres outils Google : Critique s’intègre très bien avec d’autres outils internes comme l’IDE de Google et le bug tracker, ce qui améliore la productivité. Cela inclut des liens faciles entre code, commentaires et tickets
Suivi du « work set » : permet de savoir qui doit agir ensuite
Gamification satisfaisante : Critique n’a pas été conçu comme un produit gamifié, mais les Googlers racontent qu’il était très agréable de voir Critique « passer au vert » quand la PR était prête à être soumise (tous les tests passés, LGTM du reviewer obtenu)
Commentaires vus sur Reddit
- Des raccourcis clavier incroyables pour reviewer énormément de code de manière très efficace
- Affiche par défaut ce qui a changé « depuis la dernière review »
- La fonction de « détection des déplacements de code » permet de se concentrer sur les véritables changements
- Offre une excellente fonction indiquant qui doit agir, que l’on soit reviewer ou auteur
- Utilisé avec une extension Chrome, il est facile de recevoir des notifications et de consulter sa file de reviews
- En interne, tout le monde peut lancer des requêtes sur les données de code review pour en tirer des insights
- Liaison automatique entre le code et les commentaires (y compris avec tickets et déplacements/liens)
- Pour les PR comportant plusieurs rounds de code, il est bien plus facile de comprendre la progression grâce à une vue tabulaire de l’analyse de la PR, de son historique et des commentaires
- Les termes/tags des commentaires, comme optionnel ou remarque, sont très cohérents

Réflexions et enseignements

Beaucoup de ces fonctionnalités existent aujourd’hui dans d’autres outils, mais si celui-ci est autant apprécié, c’est probablement grâce à son intégration étroite et à son extrême « personnalisation » pour le workflow et la codebase propres à Google
En même temps, cela signifie aussi qu’il est irréaliste pour toutes les entreprises de reproduire exactement Critique et ses outils associés. Par exemple, certains outils sont spécialisés dans des problèmes liés à une structure en monorepo
Critique lui-même ne sera sans doute pas proposé en open source, mais Gerrit est un outil similaire à Critique. C’est lui aussi un outil open source de code review créé et maintenu par Google
Mais Google semble investir beaucoup d’efforts et de réflexion dans la productivité des développeurs. L’entreprise publie librement ses recherches, et il est possible d’en tirer des enseignements utiles

5 commentaires

xguru 2023-12-17

Il semble qu’il y ait bien des tentatives pour intégrer ChatGPT à Gerrit.
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

Ce qui me frappe le plus, c’est que Critique permet de relire une série de CL consécutives. Sur GitHub, l’absence de prise en charge directe des chaînes de PR est gênante. Du coup, soit cela devient une seule grosse PR, soit il faut attendre que la PR précédente soit fusionnée.

tested 2023-12-11

GitHub a aussi quelque chose de similaire, mais on ne sait pas encore quand ce sera ouvert
> https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

Il n’y a pas d’analyse statique ni de suggestions basées sur le ML, mais d’après l’article, cela ressemble beaucoup à la fonctionnalité de review de GitHub. En tant qu’utilisateur régulier des reviews GitHub, j’aimerais que davantage de fonctionnalités proposées par Critique soient également adoptées.

xguru 2023-12-11

Guide de Google pour la revue de code [traduction coréenne]