Git guilt, blame et revue du code

Tim Petterson
Tim Petterson
Retour à la liste

Récemment, j'ai beaucoup voyagé à l'occasion de la deuxième partie de la tournée Getting Git Right. C'était vraiment génial de rencontrer des développeurs du monde entier. J'ai été particulièrement étonné de voir à quel point Git a été adopté par les participants au cours des derniers mois, depuis la première partie de la tournée. Lorsque nous avons effectué la présentation en juillet, presque tous les participants ont levé la main lorsque nous avons demandé : « Qui utilise Git ? ».

Toutefois, un certain blanc se faisait sentir à chaque session lorsque je posais la question : « Qui effectue une revue du code au travail ? »

En général, moins de la moitié des participants lèvent la main.

Cela m'attriste, car la revue du code m'a été d'une grande aide pendant ma carrière. En fait, je recommanderais la revue du code plus que toute autre pratique ou technologie pour améliorer la qualité d'une base de code donnée. Du reste, l'implémentation DVCS de la revue du code (la pull request) est un outil particulièrement étonnant.

Voici les trois grandes raisons :

Meilleur code

La première raison est vraiment évidente : disposer de développeurs avec différents niveaux d'expérience, différentes spécialisations techniques et différentes perspectives intégrant votre code implique une augmentation des risques de bugs et de dettes techniques, avant que votre code ne soit livré à vos clients. Si vous utilisez des pull requests, ces problèmes sont découverts avant même que votre code ne parvienne dans la branche principale : les problèmes découverts n'ont donc d'impact sur personne. Autrement dit, la qualité de votre base de code et du produit livré s'améliore.

Partage de connaissances

The second reason is a bit more subtle. Those developers that are reviewing your code aren't just providing you a free service with no benefit to themselves – they're learning too! As a junior developer, sitting on code reviews taught me more about software patterns and libraries than any book that I've read or presentation that I've attended. As a senior developer, code reviews have unlocked a lot of tribal knowledge that is specific to a particular software project or team. Each application has its own stack, patterns, and idiosyncrasies that shape the best way to patch a bug or implement a feature. Code review does a really good job at spreading this information around the team.

Propriété commune

The third reason is the most overlooked, but arguably one of the most important for the long term health of your product. If you're a developer, you've probably shipped a bug to a customer at some point. It is a terrible feeling. You see the bug report pop up in Jira during a triage session, you read the oddly-familiar description with a sinking feeling and realize that the code that you authored and shipped is causing a customer (probably multiple customers) a world of pain.

Toutefois (et c'est un petit secret), si vous intégrez la revue du code dans votre processus de développement, ce bug ne sera pas de votre faute ! En tout cas, pas juste de votre faute. La formule de culpabilité pour les développeurs est la suivante :

g = 1 / n + 1

Si n développeurs ont signé la revue, vous n'êtes responsable qu'à 1 / n + 1 du bug livré.

I am (sort of) kidding. But more practically speaking, if n developers have signed off on a review, then you have n developers who can jump in and fix the bug if the original author has left the company / is asleep in another timezone / whatever, while you have customers wide awake and screaming down the phone or on your issue tracker.

Voici donc les trois raisons principales pour lesquelles la revue du code est intéressante pour toutes les équipes de plus d'une personne. Et nous passons ainsi sans transition à la principale raison pour laquelle j'ai écrit ce billet ! J'ai récemment publié un petit outil facilitant la revue du code (avec Git).

L'une des difficultés associées à la création d'une pull request réside dans l'identification des ressources idéales pour réviser votre code. Parfois, c'est évident. Si vous travaillez avec une petite équipe ou si vous faites partie de la même équipe depuis un certain temps, vous savez qui est l'expert approprié pour la partie de la base de code que vous avez modifiée. Mais si vous êtes nouveau dans une équipe, si vous travaillez avec un grand nombre de personnes ou si vous contribuez à un projet en dehors de votre travail, la décision peut s'avérer un peu plus délicate.

Présentation de git-guilt

git-guilt is a little tool I wrote that lets you see the transfer of blame in a repository caused by a range of commits. For example, if you wanted to see how blame shifted from one author to another during your last commit, you can run the command:

git guilt HEAD~1
Terminal — bash — 98×28 2014-07-17 18-17-48 2014-07-17 18-49-07

La sortie indique que, dans mon dernier commit, j'ai ajouté 239 lignes de code, que j'ai supprimé 2 lignes au préalable attribuées à Patrick, 5 lignes de Séb, 13 lignes d'Anders et toute une série de lignes de JD. C'est plutôt amusant si vous aimez la compétition, mais de manière plus pratique, les développeurs qui apparaissent dans la sortie sont de bons candidats pour revoir la pull request que je créerai pour faire un merge de ces changements dans la branche master.

La logique sous-jacente est que les développeurs dont vous réécrivez le code auront probablement leur mot à dire à ce sujet. ;)

git-guilt est intitulée ainsi, car elle permet de visualiser le transfert du blame (ou guilt) d'une base de code entre les commits. À l'instar d'autres commandes de la suite Git, elle accepte n'importe quel commit ou réf comme argument. Par exemple, si vous utilisez la commande merge-base pour déterminer la pointe de la branche, vous pouvez afficher le blame d'une branche de fonctionnalité complète en procédant comme suit :

git guilt `git merge-base master my-feature-branch` my-feature-branch
Terminal

Ou le blame change au fil du temps :

git guilt `git log --until="3 days ago" --format="%H" -n 1
terminal

Installation

git-guilt se présente comme un module nmp. Si vous souhaitez l'essayer, il est facile à installer :

  • Make sure you have Git, Node.js and npm installed
  • Run npm install -g git-guilt (you may need sudo)
  • Exécutez git-guilt HEAD~1 dans n'importe quel dépôt git pour afficher le delta blame pour le commit le plus récent. En outre, vous pouvez l'installer facilement comme un hook post-commit pour visualiser le transfert de blame de code en temps réel au moment de créer de nouveaux commits en local. Il vous suffit de répéter la commande suivante dans .git/hooks/post-commit :
#!/bin/sh
git guilt HEAD~1

Vérifiez également que le fichier est exécutable :

chmod a+x .git/hooks/post-commit

La prochaine fois que vous ferez des commits, vous verrez la sortie git-guilt indiquer le changement du blame.

Fix it profile

La source est disponible sur Bitbucket si vous souhaitez la consulter ou y contribuer.

Vous êtes fan de Bitbucket Server ?

If you find this useful and you're using Bitbucket Server for git hosting, you may enjoy the free Bitbucket Server Reviewer Suggester add-on that I built for a ShipIt competition a while back. It implements a similar algorithm for suggesting reviewers (with a couple of embellishments) and is nicely integrated in the Bitbucket Server Pull Request creation UI.

PS : je suis sérieux.

Si vous faites partie des 50 % de développeurs qui lisent ce billet et n'effectuent pas de revue du code, commencez dès maintenant. Vous ne le regretterez pas ! Vous pourriez découvrir un bug (et épargner de nombreux soucis à vos clients) et découvrir des choses sur votre base de code en moins de temps qu'il ne vous en a fallu pour lire ce billet. :)

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant