D'accord, je sais que vous pourriez être sceptique : d'autres guides ont promis des revues de code sans douleur pour finalement révéler que leur solution nécessite une stack technique hyper-spécifique ou un outil de développement payant. Je ne vous ferai pas ça.
Ce guide fournit un modèle simple et flexible pour les revues de code que vous pouvez appliquer à votre équipe d'ingénierie. La seule exigence est que le code de votre application soit open source.
Vous pouvez tester un workflow TypeScript, Java, Python, PHP, Ruby ou même une stack web farfelue que vous avez inventée. Et peu importe si vous développez sur Windows, Linux ou Mac. Le mieux, c'est que vous n'avez pas à effectuer de configuration compliquée ni à installer de logiciel au-delà d'un fichier yaml.
Je travaille dans l'ingénierie depuis les 15 dernières années, et les revues de code ont mauvaise réputation. Nous avons tous été témoins ou avons vécu des histoires d'horreur où parfois on a l'impression que chaque ligne précédente est déchirée en lambeaux.
Alors, que pouvez-vous faire différemment ? Comment pouvez-vous rendre la revue de votre code sans douleur afin que même le plus grand pinailleur de votre équipe n'ait que des éloges ?
Après avoir participé à des revues de code pendant une décennie, prendre les revues de code moins personnellement est la chose la plus importante que vous puissiez faire pour améliorer votre code. Pourquoi ? Parce que tout logiciel est itératif. Même le code "parfait" finira par devenir obsolète. Au lieu de le considérer comme un devoir noté, pensez-y comme faisant partie du processus.
Table des matières :
Prérequis
Ce tutoriel utilise des outils gratuits et open source. Vous aurez besoin d'un compte GitHub pour vous aider à rendre vos revues de code plus agréables et précieuses.
Qu'est-ce qu'une revue de code ?
Le terme "code review" peut désigner diverses activités, allant de la simple lecture de code par-dessus l'épaule de votre coéquipier à une réunion de 10 personnes où vous dissequez le code ligne par ligne. J'utilise ce terme pour désigner un processus formel et écrit, mais pas aussi lourd qu'une série de réunions en personne pour l'inspection du code.
Dans un projet où vous travaillez sur un dépôt avec d'autres développeurs, après avoir terminé votre travail, vous validez, poussez et créez une pull request sur le VCS, très probablement en utilisant des commandes Git. Ensuite, tout le monde examine la pull request pour déterminer si elle est acceptable à utiliser. Si c'est le cas, ils l'approuvent, et ce code est utilisé dans le projet.
Quel est le but d'une revue de code ?
Les revues de code sont un outil pour le transfert de connaissances. Elles aident à rendre les développeurs plus efficaces lorsqu'ils effectuent la maintenance sur une partie du système qu'ils n'ont pas écrite.
Lorsque vous examinez une pull request, c'est l'occasion de régler les problèmes avant qu'ils ne deviennent une dette technique.
Les revues de code peuvent également être un bon cadre pour le mentorat des développeurs juniors.
Maintenant, discutons de ce qui n'est PAS le but d'une revue de code :
- Trouver des bugs. C'est à cela que servent les tests (unitaires, d'intégration, e2e, api, etc.).
Pinaillez sur les problèmes de style - adoptez un style et utilisez des formateurs ou des outils d'IA pour le faire respecter. Gardez simplement à l'esprit qu'il y a beaucoup de choses qu'un outil d'IA ne peut pas vérifier. Les revues de code sont un excellent endroit pour s'assurer que le code est suffisamment documenté ou auto-documenté.
Voulez-vous savoir comment vous pouvez vérifier cela ? Retournez au code que vous avez écrit il y a 6-12 mois et essayez de comprendre ce qu'il était censé faire.
Si vous le comprenez rapidement, cela signifie qu'il est lisible, et que la revue de code a été faite correctement et de manière utile.
Pourquoi les revues de code sont-elles difficiles ?
Malgré leur importance, de nombreux développeurs n'aiment pas faire des revues de code - en partie parce qu'elles peuvent être difficiles, surtout si vous ne suivez pas les meilleures pratiques.
Voici quelques points douloureux que j'ai observés au cours de mes années de participation à des revues de code :
Lorsque les gens parlent de revues de code, ils se concentrent sur le relecteur. Mais le développeur qui écrit le code est tout aussi crucial pour la revue que la personne qui le lit.
Faire une revue de code n'est pas une routine automatique pour un développeur.
Le relecteur peut parfois ne faire qu'une revue partielle et ajouter de nouveaux commentaires à chaque passage, même sur le code des revues précédentes qui est resté intact.
Parfois, le relecteur de code peut ne pas exprimer clairement ses attentes.
Plusieurs relecteurs de code peuvent souvent avoir des opinions divergentes, ce qui conduit à des discussions (trop) longues.
Le développeur ne comprend pas les commentaires des relecteurs et nécessite des discussions aller-retour.
Le développeur traite les commentaires de la revue de code différemment de ce qui a été convenu pendant le processus de revue.
Ces points douloureux ralentissent souvent notre vitesse de développement. Mais les récentes avancées dans les outils de revue de code assistés par IA ont commencé à résoudre ces points de friction courants dans nos workflows de PR.
Explorons comment les outils alimentés par l'IA, ainsi que certaines meilleures pratiques, peuvent résoudre ces défis de revue et optimiser votre workflow de développement.
L'IA peut-elle remplacer les revues de code ?
Bien que l'IA n'ait pas remplacé les revues de code humaines, elle est un puissant multiplicateur de force dans le processus de revue.
Voici comment : les revues de code par IA excellent en tant qu'outil de présélection, attrapant les problèmes courants avant que les relecteurs humains ne voient le code. Cela devient particulièrement précieux dans les projets open source où la bande passante des mainteneurs est limitée.
J'ai récemment commencé à utiliser des revues de code par IA au cas par cas pour mes projets.
Les outils d'IA améliorent mes workflows existants, réduisent les taux d'échec en détectant les erreurs de logique tôt, et augmentent la productivité. Je l'ai donc ajouté à mes pipelines CI/CD. Il n'a pas besoin d'être parfait pour détecter les erreurs de logique, tant que son taux de faux positifs est très faible (idéalement aussi proche de 0 que possible).
Plus important encore, les revues par IA respectent la règle d'or de "valoriser le temps de votre relecteur" en gérant les vérifications de routine. Cela permet aux relecteurs humains de se concentrer sur l'architecture, la logique métier et les cas limites complexes.
Cette approche positionne l'IA comme un outil complémentaire qui augmente plutôt que remplace l'expertise humaine dans le processus de revue de code.
Sur quoi se concentrer lors d'une revue de code
Lorsque vous examinez du code, essayez de prioriser ce qui compte le plus en utilisant la Pyramide de Revue de Code. C'est un cadre qui vous aide à concentrer votre attention là où elle crée le plus de valeur.
Pensez-y comme à la construction d'une maison - commencez par les fondations avant de vous soucier des couleurs de peinture.
La pyramide a cinq couches, de la plus critique (bas) à la moins critique (haut) :
Sémantique de l'API : Décisions de conception de base qui affectent les utilisateurs
Sémantique de l'implémentation : La fonctionnalité, la sécurité et la performance du code
Documentation : Explication claire de la manière d'utiliser le code
Tests : Vérification que tout fonctionne comme prévu
Style de code : Conventions de formatage et de nommage
Source : The Code Review Pyramid by Gunnar Morling
Rappelez-vous : si vous voulez attraper des problèmes/bogs, il existe des processus plus appropriés pour cela. C'est pourquoi nous avons des tests automatisés, des versions canaries, des environnements de test, etc.
À mon avis personnel, utiliser les revues de code comme outil de détection de bugs est quelque peu un anti-pattern où vous compensez pour un processus de développement qui peut manquer de certaines étapes/processus clés.
Pour moi, une revue de code est bien plus une question de gestion de la dette technique et de garantie que la qualité est produite, tout en livrant plus de fonctionnalités.
En faisant une revue de code, vous devez vous assurer que :
Le code est lisible
Il a des tests unitaires appropriés
Le développeur a utilisé des noms clairs pour tout
Le code est bien conçu et n'est pas plus complexe que nécessaire
Les cas de test sont sensés et ont une couverture complète
C'est quelque chose que l'équipe peut maintenir à long terme
Il n'y a pas de problèmes architecturaux qui bloqueront l'équipe
Le code correspond à l'idée de qualité de l'équipe
Vous pensez à ce que vous pouvez apprendre de la PR
Vous partagez toute connaissance que le développeur pourrait utiliser dans sa PR
Vous pensez à la manière dont vous pouvez responsabiliser le développeur grâce à vos commentaires positifs
La PR a une description claire de la liste des changements
Meilleures pratiques et processus de revue de code
Il n'existe pas de règle générale en ingénierie pour les revues de code, car ce sur quoi vous devrez vous concentrer dépend de nombreux facteurs. Vous pouvez et devez configurer le processus selon les normes de votre entreprise et la manière de travailler en équipe.
Voici quelques facteurs auxquels vous devrez penser avant de configurer un processus de revue de code :
La taille et le type d'entreprise dans laquelle vous vous trouvez (par exemple, une startup vs une grande entreprise)
Le nombre de développeurs dans votre équipe
Votre budget
Le cadre temporel avec lequel vous travaillez
Vos charges de travail et celles de votre équipe
La complexité du code
Les capacités et compétences du ou des relecteurs
La disponibilité du ou des relecteurs
Par exemple, dans mon travail, nous avons une règle très simple : TOUS les changements de code doivent être revus par au moins un développeur avant une fusion ou un commit dans le tronc.
Les revues de code nécessitent une approche systématique, mais maintenir la cohérence dans chaque PR est un défi. Il est utile de laisser les ordinateurs gérer les vérifications répétitives (style, formatage) tandis que les humains se concentrent sur ce qui compte le plus : l'architecture et la logique. Cette approche équilibrée rend les revues à la fois approfondies et durables.
Prenez un exemple. Il montre comment nous pouvons optimiser notre processus de revue de code en déléguant intelligemment les tâches entre les humains et les outils automatisés. Le diagramme ci-dessous illustre un workflow typique de revue de style de code, comparant les étapes de revue manuelle humaine aux outils automatisés.
Le diagramme montre un problème réel auquel nous sommes tous confrontés dans les revues de code. Voyez le côté gauche ? C'est nous, les humains, qui faisons des vérifications de formatage manuelles : trouver des espaces bizarres, corriger les indentations, écrire des commentaires à ce sujet... des choses assez fastidieuses. Mais regardez le côté droit : c'est là que des outils comme Prettier corrigent automatiquement ces problèmes de formatage.
Pas de réunions, pas d'allers-retours - juste fait. C'est pourquoi j'ai commencé à utiliser CodeRabbit, qui est un outil de développement qui a attiré mon attention récemment.
Qu'est-ce que CodeRabbit ?
La documentation de CodeRabbit décrit l'outil de manière assez efficace, alors je vais juste laisser cela ici :
CodeRabbit est un relecteur de code alimenté par l'IA qui fournit des commentaires contextuels sur les pull requests en quelques minutes, réduisant le temps et l'effort nécessaires pour les revues de code manuelles. Il offre une nouvelle perspective et attrape les problèmes qui sont souvent manqués, améliorant la qualité globale de la revue. - de la documentation de CodeRabbit
Comment CodeRabbit aide-t-il ?
Laissez-moi vous guider à travers un exemple réel. Lorsque vous soumettez une PR, CodeRabbit :
Effectue un résumé de la PR à la volée :
Tout d'abord, il vous donne un aperçu rapide de ce qui a changé.
Il explique également l'impact en anglais simple (génial pour les non-techniques de votre équipe).
Ensuite, il inclut une visite détaillée des changements de fichiers.
Effectue une "Revue de Code Intelligente" :
Il dépose des commentaires directement sur les lignes spécifiques qui nécessitent de l'attention.
Il suggère également des corrections au format diff que vous pouvez appliquer d'un seul clic.
Et il montre quels commits et fichiers il a vérifiés (ce qui est utile pour suivre la couverture de la revue).
Vous donne des commentaires interactifs :
Vous pouvez discuter avec lui directement dans les commentaires de la PR.
Vous pouvez lui poser des questions sur des changements de code spécifiques pour obtenir plus de détails.
Et il se souvient des modèles et préférences de votre équipe, ce qui est super utile pour la cohérence (dont j'ai parlé ci-dessus).
Fonctionnalités supplémentaires utiles :
CodeRabbit valide les changements par rapport aux problèmes GitHub/GitLab liés.
Il crée des diagrammes de séquence pour visualiser les changements.
Et il peut effectuer des corrections en un clic sur les applications pour des problèmes simples.
J'ai découvert CodeRabbit pour la première fois le mois dernier alors que je cherchais autre chose sur GitHub. Je suis tombé dessus par accident et j'ai été surpris par le nombre de personnes qui l'utilisent déjà.
Je me suis inscrit instantanément parce que je cherchais exactement une telle solution qui pourrait m'aider, moi et mon équipe, avec nos revues.
J'ai lu la documentation de CodeRabbit et j'ai été très impressionné.
Commencer à l'utiliser est un processus presque plug and play.
Dans la section suivante, nous allons passer par les étapes rapides que vous pouvez suivre pour activer CodeRabbit en utilisant un dépôt exemple.
Inscrivez-vous sur coderabbit.ai en utilisant votre compte GitHub.
Allez à Ajouter Votre Dépôt.
Et c'est tout. CodeRabbit commence à examiner vos PR automatiquement.
Un dépôt GitHub à tester
En tant qu'exemple de dépôt GitHub à tester, nous allons utiliser devtoolsacademy : mon blog sur tout ce qui concerne les outils de développement géniaux.
Tout d'abord, visitez la page de connexion de CodeRabbit et connectez-vous via GitHub.
Ensuite, ajoutez CodeRabbit à certains de vos dépôts GitHub publics.
Maintenant, CodeRabbit est entièrement intégré et prêt à effectuer des revues de code sur votre dépôt sélectionné.
Oui : c'est aussi simple et rapide. Et à mon avis, c'est l'une des principales raisons pour lesquelles l'outil est si utile.
Voici quelques exemples de PR pour que vous puissiez vérifier :
Exemples supplémentaires
Conclusion
Le code de tout le monde a besoin d'être revu. Juste parce que quelqu'un est la personne la plus senior de l'équipe ne signifie pas que son code n'a pas besoin d'être revu.
Dans cet article, j'ai parlé des revues de code ainsi que de certains points douloureux courants. J'ai ensuite montré comment vous pouvez tirer parti de CodeRabbit pour itérer rapidement à travers vos revues de code et vous concentrer davantage sur les affaires.
Lecture supplémentaire
Dans cet article, j'ai parlé de l'introduction de base à CodeRabbit, car c'était mon cas d'utilisation avec mon blog.
Pour des fonctionnalités plus avancées, consultez la documentation officielle de CodeRabbit ou lisez leur blog.
Avant de terminer
J'espère que vous avez trouvé utile d'apprendre à utiliser les outils d'IA pour les revues de code.
Si vous aimez mon écriture, voici quelques-uns de mes autres articles les plus récents.
Suivez-moi sur Twitter pour rester informé de mes projets open source.