La revue de code peut être meilleure

• Les développeurs sont nombreux à être insatisfaits de l’expérience de revue de code sur GitHub, et de nouvelles tentatives sont en cours pour l’améliorer
• Un outil expérimental appelé git-review est conçu pour gérer la revue de code directement en local avec le code, plutôt que via une interface web dans le navigateur
• La revue est gérée sous la forme d’un seul commit ; les commentaires de revue sont laissés comme des annotations dans le code, et le relecteur comme l’auteur modifient ce commit à tour de rôle
• Cependant, si le code est modifié ou rebasé en cours de revue, cela crée des difficultés, notamment pour la gestion des conflits et l’usage de --force-with-lease, ce qui a empêché l’approche de rencontrer un grand succès
• En fin de compte, le retour à la revue via le web s’est imposé, mais l’idée d’inclure directement l’état de la revue dans le dépôt Git reste séduisante, et de meilleures alternatives pourraient émerger à l’avenir avec l’amélioration de Git, notamment via l’adoption d’un Change-Id à la Gerrit

---

Prise de conscience des problèmes des systèmes de revue de code

• Aujourd’hui, beaucoup de personnes sont mécontentes du processus de revue de code de GitHub
• Les principaux problèmes sont le manque de prise en charge des pull requests empilées et de la revue interdiff, ainsi que :
  • l’état de la revue n’est pas stocké dans le dépôt
  • la revue via une interface web orientée distant est obligatoire
• Le problème, à mes yeux, tient au manque de décentralisation de la revue et à l’inefficacité de l’interface

Comparaison des workflows d’écriture de code et de revue

• Lorsqu’ils écrivent du code, les gens utilisent un éditeur en local
  • c’est un environnement avec peu de latence mémoire et NVMe, optimisé pour les workflows particuliers de chacun
• Pour la revue de code aussi, il est préférable de pull la branche source en local pour travailler
  • avec des outils comme Magit, il est possible d’explorer non seulement le diff mais aussi tout le contexte du code
  • on peut profiter d’un environnement de développement puissant : exécuter les tests, aller à la définition du code, essayer des refactorings, etc.
• En revanche, pour laisser un retour sur une PR, il faut passer par le navigateur et une interface web lente, avec même une forte latence de saisie sur les gros diffs

Interface de revue de code idéale et structure de stockage

• En pratique, il est plus naturel de laisser des commentaires directement en ligne dans le code ou de modifier le code soi-même

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Lorsque les données sont stockées dans une base distante plutôt que dans le dépôt git local, cela entraîne aussi des problèmes de latence et de vendor lock-in

L’idée de git-review et le retour d’expérience réel

• L’idée de git-review est la suivante :
  • la revue de code prend la forme d’un commit unique au sommet de la branche de PR
  • des commentaires de code avec marqueurs spéciaux sont ajoutés dans ce commit
  • le relecteur et l’auteur modifient ce commit chacun leur tour, dans une collaboration fondée sur push --force-with-lease
  • quand tous les commentaires sont marqués comme résolus (//? resolved), un commit de revert est ajouté à la fin de la revue pour conserver une trace
• L’idée est simple et pratique, mais en réalité les problèmes suivants apparaissent :
  • lorsqu’on modifie le code pendant la revue, les conflits avec les commentaires sont fréquents dans les commits inférieurs ou les nouveaux commits
  • le processus de force-push augmente les frictions de collaboration et la complexité du travail
  • il devient difficile de gérer les désalignements entre l’historique des modifications du code et l’avancement de la revue, ainsi que les conflits de fusion

Nouveaux changements et possibilités futures

• À l’avenir, un Change-Id à la Gerrit dans Git upstream pourrait être introduit
  • cela faciliterait le suivi de l’historique des modifications par commit et étendrait probablement la prise en charge de la revue interdiff
  • mais cela pourrait aussi entrer en conflit sur certains points avec l’approche git-review
  • avec cette nouvelle structure de Change-Id, des approches originales comme l’ajout de commentaires de revue directement dans le commit pourraient devenir possibles

Conclusion et présentation de systèmes utiles à connaître

• Pour l’instant, la situation est donc revenue à une revue de code basée sur une interface web
• Le besoin d’une meilleure solution demeure
• Présentation de systèmes et d’outils connexes à connaître
  • Fossil : un système SCM qui conserve toutes les informations dans le dépôt
  • NoteDb : intègre dans git l’historique de stockage de l’état de revue de Gerrit
  • git-bug : stocke les informations d’issues dans git
  • git-appraise : conserve les informations de revue dans git lui-même
  • prr : implémente une interface de revue dans l’éditeur via l’API GitHub
  • How Jane Street Does Code Review : présente un exemple d’une réalité meilleure
  • git-pr : un projet qui remplace l’ensemble du workflow de PR par des fonctionnalités natives de git

Conclusion

• Il n’existe pas encore de solution parfaite, et les tentatives pour offrir une meilleure expérience développeur se poursuivent
• Les attentes sont fortes quant aux évolutions à venir