par Phil Miller
Vue d'ensemble
Les revues de code sont un élément essentiel d'une organisation saine de développement de logiciels, quelle que soit sa taille, et dans de nombreux cas, elles constituent une exigence organisationnelle ou réglementaire.
Voyons comment améliorer vos revues de code et créer la meilleure expérience possible pour toutes les personnes impliquées.
Dans ce billet, nous aborderons les points suivants :
- Pourquoi nous faisons des revues de code
- Ce qu'il faut prendre en compte avant de commencer
- Meilleures pratiques pour l'examen du code
- Conseils après l'examen
- Conseils à l'auteur
- Outils de révision du code
Pourquoi faire des revues de code ?
Dans le monde moderne et rapide du développement de logiciels, il peut sembler contre-intuitif de faire réviser tout son code alors qu'on pourrait simplement l'expédier. Cependant, le développement de logiciels est considéré comme un sport d'équipe, alors pourquoi ne pas impliquer quelques coéquipiers ? En fin de compte, l'objectif de l'écriture du code est de livrer une unité de valeur commerciale (par exemple, une nouvelle fonctionnalité, une correction de bogue importante) et d'introduire le moins de dette technique possible en le faisant. Les revues de code sont le meilleur moyen d'atteindre cet objectif.
Pour ce faire, nous procédons de la manière suivante :
- garantir la qualité du code et les normes de codage
- la capture et la correction de ces bogues insaisissables avant qu'ils ne soient expédiés
- le partage des connaissances au sein de nos équipes
C'est bien d'être un contributeur prolifique, mais si votre facteur bus est de 1, vous créez toujours un risque excessif pour vos coéquipiers actuels et futurs. L'examen du code est un excellent moyen d'améliorer tous ces aspects, car il vous oblige à discuter et à créer un nouveau contexte partagé.
Avant de procéder à l'examen
L'un des aspects les plus importants, et souvent négligé, d'un examen de code est de comprendre que vous fournissez des commentaires sur le code et non sur le codeur. En même temps, il est tout aussi important de reconnaître que la personne qui reçoit ce feedback est une vraie personne avec de vrais sentiments. L'état d'esprit par défaut doit donc toujours être positif. Votre but ultime est d'aider le codeur, et votre organisation de développement dans son ensemble, à s'améliorer, et ce feedback a beaucoup plus de chances d'aboutir s'il part d'un point de départ positif.
Maintenant que vous êtes dans le bon état d'esprit, il est temps d'obtenir le contexte approprié. Quelles sont les attentes concernant le code examiné (par exemple, que doit faire cette fonctionnalité, quelles sont les spécifications, quels sont les cas d'utilisation qu'elle doit gérer) et quel type de documentation existe pour ce code. Avec un peu de chance, l'auteur (ou tout outil automatisé) a déjà fourni des liens utiles vers des éléments tels que : un ticket dans le système de votre choix (ex. Linear, JIRA, GH Issues), des fichiers de conception (ex. Figma, Invision, Sketch), et tous les PR ou commits associés. Si ce n'est pas le cas, vous devrez peut-être le demander.
Enfin, vous devez prendre en compte les "morceaux" que vous espérez examiner et les limiter à des tailles digestes. Dans un monde parfait, l'auteur a déjà fait cela et vous avez un morceau de code de la bonne taille à examiner. Parfois, malheureusement, les revues de grande ampleur sont inévitables, et vous, en tant que réviseur, devrez déterminer ce qu'est un morceau de code approprié pour chaque partie de votre revue. Si les revues de code prennent plusieurs heures, cela indique que les morceaux sont trop grands ou qu'il peut y avoir d'autres problèmes dans le processus de développement.
Meilleures pratiques pour l'examen du code
Ok, vous vous êtes mis dans le bon état d'esprit. Vous avez lu tous les documents d'appui et vous avez réfléchi à la meilleure façon de diviser l'examen en morceaux digestes.
Vous êtes prêt à vous lancer.
Tout d'abord, vous devez avoir une bonne compréhension de cet ensemble de modifications. Parcourez les fichiers et réfléchissez à la structure et au flux globaux. Ce n'est que lorsque vous aurez fait cela une fois (ou deux !) que vous pourrez envisager de creuser un peu plus. Pour ce faire, il est préférable de consulter une liste de contrôle afin de garder les choses structurées. Considérez les éléments suivants :
- Normes de codage et meilleures pratiques
- Quelles sont les attentes au sein de notre organisation et de notre équipe ?
- Ce code les respecte-t-il ?
- Les modifie-t-il ?
- Est-ce nécessaire ?
- Gestion des erreurs et journalisation
- Les niveaux de journalisation sont-ils appropriés (Info, Avertissement, Erreur, etc.) ?
- Les messages sont-ils significatifs et identifiables ?
- Tests
- Quelles sont les attentes en matière de couverture des tests ?
- Ce code bénéficie-t-il d'une couverture appropriée ?
- Les types de tests sont-ils appropriés (par exemple, tests unitaires ou tests d'intégration) ?
> Chacun de ces éléments de la liste de contrôle mériterait probablement un article à part entière, et nous les étudierons dans de futurs articles !
Vous avez procédé à un examen approfondi du code et vous avez trouvé quelques éléments qui méritent d'être commentés. La façon la plus efficace d'aborder cette question est de laisser des commentaires constructifs. Qu'est-ce qu'un commentaire constructif ? En gardant à l'esprit la positivité dont nous avons parlé précédemment, un commentaire constructif devrait :
- Être clair et précis
- Poser des questions au lieu d'instruire
- Proposer des alternatives (le retour d'information exploitable est roi)
- Identifier sa propre importance (ex. Nitpick vs blocker)
- Pas de bassin à vélos
Parla suite, en considérant l'ensemble de vos commentaires, il est souvent préférable de fournir un résumé, tel qu'un commentaire général de RP résumant l'ensemble des commentaires et les principaux points à traiter. Ce commentaire général est particulièrement important s'il existe des thèmes transversaux ou des problèmes communs à tous les commentaires (par exemple, un problème qui survient ou un remaniement architectural qui a un impact sur de nombreux fichiers différents). Parfois, cela peut se faire de manière totalement asynchrone, mais d'autres fois, il peut être plus facile d'avoir un appel rapide (ou une réunion), pour fournir plus de clarté. Vous pouvez même faire du "pairing" pour raccourcir les cycles de retour d'information sur les commentaires exploitables et les traiter ensemble.
Enfin, une fois que l'auteur et l'évaluateur sont d'accord sur le fait que le retour d'information a été résolu, considérez les leçons tirées et partagez-les avec votre équipe afin que tout le monde puisse en bénéficier.
Conseils pour les auteurs de code
Comme nous l'avons déjà mentionné, le développement de logiciels est un sport d'équipe. En tant qu'auteur du code, vous devez donc penser à préparer vos réviseurs pour qu'ils réussissent. Comme indiqué dans la section "Avant...", assurez-vous de fournir tout le contexte nécessaire sous la forme de documents d'appui (tickets, éléments de conception, autres PR) et de fournir tout contexte général dans un commentaire récapitulatif. Si le PR est en bon état, il est souvent utile de faire savoir à l'auteur qu'il a fait du bon travail et que vous appréciez ses efforts.
Puisque vos évaluations doivent être positives, vous devez refléter cet état d'esprit. L'objectif de ce processus est d'améliorer le code grâce au retour d'information, et non de signaler les erreurs. En parlant de retour d'information, c'est à vous, en tant qu'auteur, de répondre à tout retour d'information qui nécessite un suivi et de le faire en temps voulu. L'attention d'un évaluateur est très probablement divisée, donc plus les cycles de retour d'information sont rapides, plus les évaluateurs sont susceptibles de conserver le contexte nécessaire.
Conclusion
Les revues de code sont le fondement de toute pratique moderne de développement de logiciels. Elles permettent de réduire le nombre de défauts que les équipes produisent immédiatement et à l'avenir. Elles permettent également à tous les membres actuels et futurs d'une équipe de partager le contexte et d'apprendre en permanence.
Nous espérons que les concepts présentés ici vous ont aidé à réfléchir à la manière dont vous pourriez améliorer votre processus de révision de code. Si nous avons oublié quelque chose, n'hésitez pas à nous contacter sur Linkedin.
Si vous voulez améliorer votre équipe et faire de meilleures revues de code avec l'IA, jetez un coup d'œil au Korbit AI Mentor et faites-nous savoir ce que vous en pensez. Nous apprécions vos commentaires !
.png)
