Certains développeurs préfèrent la revue de code « interdiff »

Pourquoi certaines personnes aiment la revue de code « interdiff »

Évaluation de l’outil de revue de code Gerrit

• Gerrit est un outil open source de revue de code qui fonctionne avec des dépôts Git
• Il est possible d’écrire des patchs dans le dépôt et de les soumettre pour revue
• On peut examiner le code écrit par d’autres et signaler les problèmes à corriger
• La revue de code est généralement une bonne idée
• Dans les projets open source, le code peut être fusionné, ce qui accroît la responsabilité et la dette technique

Différents outils de revue de code

• Il existe divers outils comme Gerrit, GitHub, Phabricator, le téléversement de fichiers .patch dans un bug tracker, ou l’envoi par e-mail via git send-email
• Chaque outil peut fonctionner à des degrés divers

Série de patchs idéale

• Une série de 3 patchs représente l’évolution de la base de code étape par étape
• Les changements doivent être séparés logiquement, et chaque patch doit pouvoir se lire comme s’il avait été appliqué individuellement
• La revue de code sert à examiner cette série idéale

La méthode de revue de code de GitHub : « diff soup »

• À l’origine, GitHub encourageait la revue en ajoutant de nouveaux commits au-dessus des commits existants
• Cela découle de la conception de l’UX et de plusieurs autres raisons
• Quand plusieurs commits sont ajoutés pendant la revue, les relations implicites entre eux deviennent complexes
• Cela rend l’usage des outils git blame et git bisect plus difficile

Une meilleure approche : la revue « interdiff » (alias git range-diff)

• Au lieu d’ajouter de nouveaux commits, on publie une nouvelle version des commits d’origine
• On utilise git range-diff pour comparer les différences entre les versions des commits
• Le reviewer peut faire une revue incrémentale sans avoir à relire tout le diff
• Les outils git blame et git bisect fonctionnent alors de manière plus fiable

Explication intermédiaire : stratégies de fusion de patchs

• La méthode ci-dessus est indépendante de la stratégie de fusion (par ex. git rebase vs commit git merge à parents multiples)

Explication intermédiaire : savoir si git rebase est mauvais

• git rebase est acceptable. Il ne faut simplement pas l’utiliser sur une branche publique sur laquelle d’autres personnes vont baser leurs commits

Autres notes

Conclusion

• Un système de revue interdiff encourage des patchs plus petits et fusionnés plus rapidement dans la branche principale
• Il offre une meilleure expérience de revue de code, à la fois pour les reviewers et pour les auteurs

Résumé de GN⁺

• Cet article propose une analyse approfondie des outils et méthodologies de revue de code
• La méthode de revue interdiff peut améliorer considérablement l’efficacité de la revue de code
• Elle aide à résoudre le problème du « diff soup » de GitHub
• Il présente des éléments importants à prendre en compte lors du choix d’un outil de revue de code
• Parmi les outils offrant des fonctions similaires, on trouve GitHub, Gerrit et Phabricator

[GN⁺]

Avis Hacker News

• Le workflow principalement utilisé sur GitHub demande beaucoup de travail et n’est pas très clair pour les collaborateurs

  • Il permet au relecteur de voir la différence intégrant les retours, sans casser git blame ni git bisect
  • Lors de l’intégration des retours du relecteur, utilisation de git commit --fixup <hash du commit à mettre à jour>
  • Une fois la PR approuvée, utilisation de git rebase --interactive origin/main --autosquash pour fusionner les commits fixup avec les commits d’origine
  • Enfin, fusion avec git push --force-with-lease
  • Utilisation de l’autocomplétion pour saisir facilement les longues commandes

• La manière dont GitHub gère la revue de code est inefficace, et cela était traité manuellement avec Phabricator

  • Une UI explicite serait préférable

• Souhait d’un meilleur système que la revue de code de GitHub

  • Volonté de fusionner rapidement de petits patchs de correction de bugs et de réduire le périmètre de revue
  • Certains affirment qu’il faut en faire des revues/PR séparées, mais cela crée des problèmes de dépendances entre patchsets

• Il est toujours intéressant de voir de nouvelles approches de revue de code

  • L’idée de diviser les patchs en PR dépendantes séparées a déjà été envisagée
  • Des outils comme GitContext permettent de garder de petites PR tout en conservant les dépendances
  • L’IA peut être utilisée pour résumer les PR et les revues, et générer des messages de commit précis
  • Le relecteur ne peut voir que les changements depuis la dernière revue

• Review Board a introduit les interdiffs en premier, et c’est très utile pour la revue de code

  • Les commits de fix-it ne sont pas une alternative appropriée
    1. Ils ne permettent pas de connaître les changements en amont
    2. Ils complexifient le graphe des commits
    3. Tout le monde n’utilise pas Git
  • Les interdiffs permettent au relecteur de suivre toutes les mises à jour depuis la première demande de revue
  • C’est utile lorsqu’on publie plusieurs commits dans une seule demande de revue

• Expérience d’utilisation du système de revue de code Gerrit, et la revue de code GitHub est inefficace

  • Gerrit permet d’empiler plusieurs patchs, ce qui facilite la revue de petits patchs
  • L’interface de GitHub ressemble à un fil de forum et ne permet pas de suivre les rebases

• Expérience avec divers systèmes de revue de code, chacun ayant ses avantages et ses inconvénients

  • Critique est optimisé pour le monorepo de Google et son VCS personnalisé
  • Gerrit est agréable pour les relecteurs, mais inconfortable pour les auteurs
  • GitHub est convivial pour les auteurs, mais inefficace pour les relecteurs et les équipes
  • Il est important d’utiliser de meilleurs outils de revue de code

• Après avoir utilisé le système de revue de code Gerrit, les PR stackées de GitHub semblent peu pratiques

  • GitHub n’affiche pas correctement les modifications liées aux commentaires de revue de code
  • Quelques scripts ont été utilisés pour faciliter le travail avec des PR stackées
  • Des outils comme ejoffe/spr et spacedentist/spr sont utiles