La revue de code représente une part importante du travail de tout développeur, mais la faites-vous bien ? Je vais vous expliquer comment faire une bonne revue de code et les meilleures pratiques que j’ai apprises au cours de mes années d’expérience en tant que développeur. Je parlerai également de ce qu’une personne qui demande une revue de code doit faire avant de la demander.
J’ai déjà écrit un article sur les inconvénients de la révision du code, et il s’agit d’une perspective légèrement différente. Si cela vous intéresse, vous pouvez le lire avant celui-ci pour vous faire une idée sur l’envers de la médaille.
Ok, sans plus attendre, allons-y.
Soyez rapide
Personne n’a envie d’attendre longtemps un retour d’information tout en perdant l’élan nécessaire pour revenir à la PR donnée. C’est pourquoi une revue de code devrait presque toujours être votre priorité. Je ne dis pas que vous devez abandonner tout ce que vous faites en ce moment pour commencer une revue de code. Cependant, si vous utilisez Pomodoro ou faites des pauses régulières, vérifiez s’il y a des PR à ce moment-là et ne laissez pas une autre personne vous attendre plus longtemps que prévu. Dans un scénario parfait, vous devriez effectuer la révision dans l’heure qui suit, afin que la personne qui soumet le code ait encore le temps de travailler sur les corrections nécessaires sans perdre trop de concentration.
Soyez votre propre QA
C’est peut-être un peu controversé, mais l’idée est d’aller dans la branche que vous révisez et de tester les fonctionnalités en direct. Cela peut prendre un certain temps, mais cela permet de s’assurer que les bogues les plus apparents n’apparaîtront pas sur l’application de test. Considérez cela comme un investissement qui vous fera gagner du temps plus tard. Laissez-moi vous expliquer. Si vous envoyez l’application avec un bogue, votre service d’assurance qualité perd du temps à examiner le problème, puis vous devez perdre du temps à corriger ce problème et le cycle continue. Une fois que j’ai commencé à le faire, j’ai commencé à penser que c’était l’une des parties les plus cruciales d’une revue de code, en particulier pour les applications frontales.
Discutez de l’essentiel
Chacun a sa propre façon d’écrire du code et c’est très bien ainsi ! Cependant, les légères différences ne valent généralement pas la peine d’être discutées, vous ne devriez donc pas les souligner, surtout si vous l’avez déjà fait lors de tentatives précédentes.
Cependant, il est également utile de se mettre d’accord sur certaines règles de style de code. Cela devrait réduire le nombre de différences aux plus insignifiantes – vous pouvez toujours ajouter quelque chose à cet endroit, si vous le trouvez gênant.
La meilleure pratique cruciale pour une revue de code est la lisibilité. Si vous ne comprenez pas un morceau de code ou si cela prend trop de temps, laissez un commentaire ou passez un appel pour en discuter. Parfois, même le débogage ou la révision du code dans un IDE peut aider (sauf si cela prend trop de temps), mais n’ayez pas peur d’exprimer votre confusion lorsque quelque chose n’est pas clair.
Automatisez les autres
L’ajout de lints ou d’autres options d’analyse peut vous faire gagner beaucoup de temps. Vous n’avez pas besoin de lire le code à la recherche de ces problèmes mineurs, car ils sont automatiquement détectés par le système, et non par un humain. Il en va de même pour le formatage. Vous pouvez vous assurer que tous les fichiers sont formatés en paramétrant certains githooks ou en ajoutant un script sur CI – je ne peux pas imaginer revoir du code non formaté.
Vérifiez deux fois les modifications
Cela peut être un peu controversé, car je suis d’accord pour dire que faire confiance à ses coéquipiers est fondamental, mais ce n’est pas une si grande méfiance que vous le pensez. Je ne parle pas de relire chaque ligne de code. Il s’agit plutôt de parcourir rapidement le code pour repérer les changements ou les erreurs. Et Github vous facilite la tâche dès lors que vous marquez les fichiers comme consultés.
Ce que vous devez faire avant de soumettre un PR
Rédigez une description
Fournissez une explication claire de ce sur quoi vous avez travaillé dans ce PR, car les titres peuvent aussi manquer de contexte. Il est également utile de créer un lien vers des documents de documentation connexes ou de réaliser une vidéo ou une capture d’écran des modifications.
Révisez vous-même le RP avant de demander une révision
Vous pouvez trouver toutes les erreurs mineures, les coquilles, etc., alors vérifiez deux fois le PR avant de demander à quelqu’un d’autre de le réviser. Il peut être très ennuyeux de demander à quelqu’un de réviser du code cassé ou quelque chose qui ne semble pas bon, mais que vous avez oublié et avez continué. Si vous ne pouvez pas effectuer les modifications maintenant, laissez un commentaire. C’est beaucoup mieux que de ne rien laisser du tout.
Assurez-vous que les tests n’échouent pas.
Je ne parle pas seulement des tests automatisés ni de l’exécution de l’application par vous-même. De nombreux programmeurs ne font pas cet effort, car ils pensent que c’est le travail du service d’assurance qualité. Pourtant, il est également de votre responsabilité de fournir et de garantir la qualité de vos modifications. C’est une bonne pratique que d’exécuter vos tests automatisés et vos analyses statiques avant chaque poussée et de formater vos changements avant de les commettre. Vous pouvez y parvenir rapidement en utilisant les git hooks. Vous trouverez plus d’informations à leur sujet ici.
Faites en sorte que vos PRs soient aussi petits que possible.
En fin de compte, à mon avis, il est beaucoup plus facile de réviser plusieurs petits lots de code plutôt qu’un gros, surtout s’ils ne concernent pas la même chose. Faites donc en sorte que vos poussées soient aussi petites que possible. Les gens vous remercieront plus tard.
Résumé
Si vous avez lu mon autre article, vous pouvez voir qu’il peu y avoir une différence sur certains points. En comparaison, l’autre article parle davantage des effets que la revue de code peut avoir sur une équipe. Je me suis entièrement concentré sur les bonnes pratiques de la revue de code sans examiner si elle est nuisible ou non, donc si vous êtes une personne qui préfère s’en tenir à faire des revues de code, alors j’espère que vous avez trouvé certains de ces conseils utiles.
