Les revues de code sont une étape essentielle du cycle de développement pour améliorer la qualité et la maintenabilité du code. Pourtant, de nombreuses équipes d’ingénierie renoncent aux revues de code et s’appuient plutôt sur les tests automatisés ou l’assurance qualité manuelle pour déterminer si un morceau de code est prêt à être livré.

La recherche a montré que l’inspection de la conception et du code offre un taux de détection des défauts bien plus élevé que les tests logiciels, comme l’indique le livre de Steve McConnel, CodeComplete.

Mais comment maximiser les avantages des revues de code — surtout lorsqu’on gère une équipe distribuée et asynchrone ?

Commencez par vous assurer que votre équipe suit quelques bonnes pratiques éprouvées. Ensuite, tirez parti d’outils modernes pour permettre une communication asynchrone collaborative. Entrons dans le vif du sujet :

Comment faire une revue de code : 5 conseils clés et bonnes pratiques

Vous n’avez pas besoin de réinventer la roue. Posez des bases solides en commençant par ces bonnes pratiques :

1. Établir une checklist pour la revue de code

Créez une checklist avec les critères que votre équipe doit respecter pendant la revue de code. Elle doit couvrir les points suivants :

Supprimer les commentaires redondants dans le code pour en améliorer la lisibilité.

• Suivez le principe KISS.
• Vérifiez que le nouveau code est conforme à votre guide de style existant.
• Traitez les vulnérabilités les plus récentes pour garantir la sécurité de l’application.
• Utilisez l’encapsulation et la modularisation pour séparer les responsabilités.
• Assurez-vous que la couverture de tests est suffisante.
• Lorsque cela a du sens, suivez le principe DRY : appliquez autant que possible des composants, fonctions et services réutilisables.

2. Définir une limite de temps de revue et de lignes de code (LoC)

Notre attention aux détails chute au bout d’environ 60 minutes ; il est donc préférable que les membres de l’équipe fassent plus souvent des sessions de revue de code plus courtes. Une durée plus courte signifie également que vous devez fixer une limite de LoC pour chaque session (par exemple, environ 200 à 400 lignes). En fait, un rapport de Cisco a révélé que la capacité des programmeurs à repérer les problèmes diminue après 200 lignes.

Entasser trop de modifications de code dans une seule revue peut affecter la qualité du résultat. Une recherche sur les revues de code entre pairs dans le développement logiciel distribué a montré qu’une augmentation de la taille des correctifs est associée à une diminution de l’efficacité du processus de revue. Les relecteurs sont moins engagés, apportent moins de contributions et sont plus susceptibles de passer à côté des cas limites.

Enfin, ne précipitez pas le processus. Une étude a constaté que les relecteurs qui examinent moins de 400 lignes par heure ont une capacité de détection de bugs supérieure à la moyenne. En revanche, ceux qui progressent plus vite que 450 lignes par heure obtiennent une densité de défauts inférieure à la moyenne.

3. Mesurer les progrès avec les bons indicateurs

Ce qui est mesuré se fait : des mesures objectives vous aident à suivre l’efficacité et l’efficience des revues de code, à analyser leur contribution au processus de développement logiciel et à comprendre le temps à prévoir pour mener un projet à bien. Voici les indicateurs clés à suivre et ce qu’ils signifient :

Taux d’inspection : le temps que met votre équipe pour revoir une certaine quantité de code. Il peut vous aider à évaluer la lisibilité du code. 

• Taux de défauts : la fréquence à laquelle votre équipe identifie un bug. Il peut vous montrer l’efficacité de votre méthode de revue.
• Densité de défauts : le nombre de défauts dans une quantité spécifique de code. Elle peut vous aider à identifier les composants vulnérables et à leur allouer davantage de ressources.

4. Offrir un retour d’information objectif et constructif

Les revues de code ne servent pas seulement à signaler ce qu’il faut corriger. Les relecteurs doivent s’attacher à créer un environnement collaboratif et bienveillant en prenant le temps d’expliquer la raison de chaque demande ou recommandation. Ils doivent également poser des questions ouvertes pour encourager la discussion et le partage de connaissances.

Une explication détaillée permet d’accélérer le processus de revue, car elle évite les allers-retours supplémentaires entre l’auteur et le relecteur.

5. Mettre en place des pipelines CI/CD robustes

L’erreur est humaine. Même les meilleurs programmeurs font des erreurs, et les relecteurs les plus méticuleux laissent passer des bugs. Dans le cadre de votre pipeline d’intégration continue/livraison continue (CI/CD), une revue de code systématique inclut des tests automatisés et des contrôles de sécurité pour garantir un produit de haute qualité.

De meilleures revues de code pour les équipes distribuées

Il est souvent plus difficile pour les équipes distribuées de mettre en œuvre les bonnes pratiques de revue de code en raison du manque de canaux de communication efficaces :

Partager des connaissances et des retours par écrit, par exemple par email, peut transformer quelque chose que l’on pourrait simplement montrer à l’écran en véritable roman. Les nuances se perdent souvent et les échanges qui suivent peuvent passer inaperçus au milieu d’interminables fils de « répondre à tous ».

• Et les captures d’écran ? Elles vous évitent d’écrire des pavés pour décrire des éléments visuels, mais une image statique ne vous aide pas à illustrer la façon dont les composants interactifs fonctionnent dans l’ensemble du parcours utilisateur.
• Le chat ou la messagerie directe ajoute de l’interactivité et favorise les discussions, mais le manque de structure peut générer beaucoup d’allers-retours. De plus, sur la plupart des plateformes de messagerie directe, il est facile de perdre un message ou un fil, ce qui complique le suivi.
• Les appels vidéo permettent un échange en temps réel, mais la planification peut être un véritable casse-tête. Les longues réunions vidéo épuisent les personnes et affectent la capacité des développeurs à identifier les problèmes.

En plus, les réunions ne sont peut-être pas la façon la plus rentable de mener une revue de code. Une étude a montré que les équipes de développement passent 75 % de leur temps en réunion et 25 % à lire. Pourtant, la lecture révèle 80 % des défauts, et les relecteurs sont 12 fois plus efficaces pour identifier des problèmes en lisant qu’en réunion.

Comment réaliser des revues de code efficaces dans des équipes asynchrones

Un processus de revue de code efficace doit laisser aux relecteurs plus de temps pour examiner le code et leur fournir les outils nécessaires pour communiquer efficacement leurs conclusions de manière asynchrone. Voici comment recréer l’immédiateté des interactions en personne sans réunions interminables :

Appliquer du contexte à la conversation

Les commentaires écrits se concentrent souvent sur des changements individuels et n’incitent pas les membres de l’équipe à prendre du recul pour considérer l’impact des modifications sur l’ensemble du système, les futures tâches de développement et la facilité de maintenance.

La nature linéaire de la plupart des méthodes de communication asynchrones limite souvent la portée de ces discussions, ce qui rend difficile l’intégration du contexte global et la mise en avant de chaque point comme il se doit. Si vous bifurquez vers un sujet différent, vous risquez de vous égarer au point que l’équipe perde de vue le sujet initial.

Bubbles facilite grandement l’ajout de hiérarchie et de contexte à votre revue de code en guidant votre équipe à travers vos commentaires via un partage d’écran. Vous pouvez passer d’un onglet à l’autre pour aborder les spécificités du code en question tout en illustrant la façon dont il s’inscrit dans la vue d’ensemble, sans perdre de vue la ligne de code concernée.

Les membres de l’équipe peuvent ajouter leurs commentaires, horodatés pour montrer à quoi ils se rapportent, afin de discuter des préoccupations liées au contexte plus large dans un fil associé, sans que tout le monde se demande, après quelques échanges, « comment en est-on arrivés là et quel est le lien avec cette ligne de code ? ».

Transformer une revue à sens unique en collaboration à double sens

Avec des dizaines de commentaires sur des centaines de lignes de code, comment gérer efficacement et de manière productive plusieurs fils de conversation pour que tout soit traité ?

Avec Bubbles, vous pouvez laisser des commentaires distincts, de sorte que chacun se rapporte à une ligne de code ou à un problème spécifique dans la vidéo. Les membres de l’équipe peuvent discuter de chaque point et assurer le suivi pour le résoudre, sans avoir à parcourir une longue liste de retours d’information dans un email ou un document. 

Chaque élément peut, si nécessaire, se ramifier en sa propre discussion afin de garder les commentaires gérables. Vous pouvez identifier les membres appropriés de l’équipe pour les faire participer à la conversation, plutôt que de forcer tout le monde à lire un long fil de « répondre à tous » qui ne fera qu’engendrer une énorme confusion et beaucoup de frustration (soyons honnêtes, qui lit tout ?).

Rendre le processus personnel, respectueux et conversationnel

Les commentaires perçus comme hostiles ou irrespectueux peuvent influencer la façon dont les membres de l’équipe reçoivent le retour d’information et leur moral. Nous pensons que les gens n’ont pas l’intention d’être durs ou impulsifs, mais que la plupart des méthodes de retour d’information ne laissent pas la possibilité ou l’espace aux relecteurs d’être réfléchis et empathiques.

Un retour d’information asynchrone via un outil de revue de code, un email ou une capture d’écran permet aux membres de l’équipe de tout parcourir avant de commenter. Mais ces méthodes manquent d’immédiateté pour communiquer les nuances de gestes et de ton, ce qui facilite la mauvaise interprétation du ton et de l’intention du commentaire par l’auditoire.

À l’inverse, les réunions synchrones (par exemple, les appels vidéo) aident les membres de l’équipe à saisir les nuances des commentaires. Mais la pression de devoir répondre immédiatement peut rendre les gens réactifs, de sorte que la conversation est guidée par la première pensée plutôt que par la meilleure.

Comment obtenir le meilleur des deux mondes ? Créez une Bubble pour capturer le contexte et les nuances en partageant votre retour d’information par vidéo. Parallèlement, la communication asynchrone signifie que les membres de l’équipe peuvent regarder l’intégralité de la vidéo et assimiler les commentaires avant de répondre, afin de partager leurs meilleures réflexions plutôt que la première chose qui leur vient à l’esprit.

Mettre en œuvre les bonnes pratiques de revue de code à grande échelle

La communication asynchrone permet aux équipes de mener des revues de code de manière efficace. Avec les bons outils, elles peuvent revoir plus de code en moins de temps et collaborer de manière constructive pour traiter le contexte global et améliorer la base de code au fil du temps.

Bubbles vous aide à améliorer les revues de code asynchrones en organisant les fils de discussion, en réduisant les malentendus et en encourageant la collaboration à double sens, afin que votre équipe puisse intégrer en continu le retour d’information pour créer un meilleur produit. 

Il n’y a aucune excuse pour ne pas créer une Bubble aujourd’hui : vous n’avez pas besoin de vous inscrire pour commencer et votre équipe n’a besoin de rien d’autre qu’un navigateur pour la consulter. Tout ce que vous avez à faire, c’est cliquer sur le lien et enregistrer votre première Bubble. Commencez avec Bubbles en téléchargeant notre extension Chrome et découvrez à quel point il est facile de mener une revue de code efficace.

‍

‍