Diff unifié vs. diff scindé

• Explication des avantages et inconvénients de l’utilisation du diff unifié et du diff scindé lors de la revue de code
• Le diff unifié et le diff scindé conviennent aux changements simples et de petite taille
• Pour les changements volumineux et complexes, ni le diff unifié ni le diff scindé ne sont idéaux
• L’auteur préfère examiner l’ensemble de la base de code à un instant donné, en se concentrant sur les zones modifiées récemment tout en effectuant aussi une revue plus générale
• L’auteur propose qu’une vue de diff idéale affiche l’état actuel du code à gauche, et à droite le diff unifié de la base de code visible à cet instant, avec les modifications mises en évidence de manière subtile
• Il souligne que ce format de revue est mal pris en charge par les outils existants, qui se concentrent davantage sur la revue du diff que sur celle du code réel
• Pour ce style de revue, l’auteur utilise un workflow low-tech, avec un script qui récupère localement la pull request. Ce script supprime tous les commits de la pull request, mais conserve l’ensemble des modifications
• Son workflow permet de naviguer facilement dans les fichiers modifiés et de marquer les hunks déjà relus, mais il manque une synchronisation automatique entre le buffer d’état et le fichier actuellement ouvert dans l’éditeur
• L’auteur souhaite un outil qui facilite la revue de code de cette manière, sans devoir créer un outil ad hoc sur mesure
• Il note aussi que, même si l’article traite de la manière de faire une revue de code, l’objectif principal d’une revue de code n’est pas nécessairement de revoir le code lui-même, et il présente des billets connexes sur ce sujet via des liens

[GN⁺]

Commentaires Hacker News

• Cet article discute des différences entre le diff unifié et le diff scindé dans la revue de code.
• Certains commentateurs affirment que le type de revue varie selon l’équipe et le ticket : certains préfèrent une simple vérification mentale par une deuxième paire d’yeux, tandis que d’autres privilégient une revue approfondie et structurelle des fonctionnalités avant fusion.
• Un outil appelé difftastic est mentionné ; il utilise le diff structurel pour mettre davantage en évidence les différences fines.
• Certains commentateurs utilisent des scripts avec vim pour examiner les changements d’une PR ouverte en vue de sa revue.
• La difficulté de la revue de code dans les bases de code vastes et complexes est mise en avant, le problème relevant davantage de la culture et du partage des connaissances que des outils.
• Il est mentionné que l’une des fonctionnalités de GitHub, consistant à appuyer sur . pour entrer dans l’IDE complet dans le navigateur, est utile pour voir les changements dans le contexte du fichier entier.
• Certains commentateurs remettent en question la préférence de l’auteur pour la suppression du contexte inutile dans le diff scindé, tandis que d’autres regrettent les fonctionnalités d’autres outils comme p4merge.
• L’utilisation de VSCode de GitHub dans le navigateur pour afficher la vue diff est proposée afin de voir le fichier complet et des diffs complexes plus lisibles.
• Meld est proposé comme un outil qui fonctionne bien pour ce cas d’usage.