10 conseils incontournables pour une revue de code efficace

Contexte

‍
J'ai récemment eu l'opportunité de travailler sur un projet extrêmement technique et complexe avec une équipe composée de 5 développeurs à temps plein et d'un responsable technique. Nous avions des niveaux de familiarité variés avec le projet, certains d'entre nous ayant travaillé dessus depuis ses débuts, tandis que d'autres y étaient impliqués depuis entre 1 et 12 mois. Le projet était difficile en raison de son domaine très technique et de la complexité du code, qui avait évolué au fil des ans avec l’augmentation de la portée du projet et les multiples changements architecturaux et réécritures nécessaires. En même temps, nous avions un produit logiciel réussi qui dépassait les attentes des parties prenantes. Notre feuille de route était toujours remplie de nouvelles fonctionnalités à développer.

Défi

‍
Comme c’est souvent le cas avec les équipes de développement d'Osedea, nous avions une grande vélocité de mise en œuvre. Il n’était pas rare de publier 10 à 12 pull requests principales chaque jour entre les 6 membres de l’équipe. Le défi résidait dans l’examen et la fusion de ces PR. Tandis que les revues de PR ad-hoc fonctionnaient bien avec une équipe de 2 développeurs, mon arrivée sur le projet a coïncidé avec un triplement de la taille de l’équipe en l’espace d’un mois. Cela a entraîné l’effet de goulot d’étranglement de la revue de code au fur et à mesure - des PR plus longues et des revues incohérentes. Dans cet article, nous allons examiner les étapes que nous avons suivies pour transformer la revue de code d’un obstacle à l’outil puissant qu’elle est censée être.

À éviter

• Ne pas sauter les sessions de raffinage en équipe (bien que cela ne soit pas directement lié à la revue de code…). Les sessions de raffinage sont cruciales pour s’assurer que les développeurs aient au moins une compréhension de haut niveau de toutes les histoires dans un sprint et pour éviter les silos de connaissances. Cela est particulièrement important dans un projet très technique et complexe avec des développeurs ayant des niveaux de connaissance et d’expérience variés. La revue de code devient difficile quand on ne comprend pas ce qui se passe.

• Ne pas être trop pointilleux. Si c’est le cas, commencez par “Nit :” Dans la revue de code, il faut garder le focus sur les retours importants et les demandes de changement. Les petits détails (nits) apportent du bruit et démoralisent. Beaucoup de ces nits sont liés au formatage - utilisez des outils de linting automatisés et des vérifications dans votre pipeline CI, si vous en avez un.

• Ne pas négliger les sessions de revue de code en direct, surtout pour les PR plus complexes. Il faut éviter un ping-pong inefficace dans les commentaires de PR. Si la lecture d’une PR soulève beaucoup de questions et de retours, demandez une réunion rapide avec l’auteur. Les discussions en direct sont souvent plus productives et plus conviviales… ce qui nous amène au point suivant.

• ‍Ne pas laisser l’ego entrer dans la revue de code. Nous sommes des professionnels, des artisans et, surtout, des coéquipiers. Suffisamment dit ?

• Ne pas sauter les descriptions de PR, les tags, etc. Décidez en équipe d’un modèle et de normes pour l’ouverture des PR. Ces éléments n’ont pas besoin d’être longs ou compliqués (en fait, plus c’est simple, mieux c’est), mais ils sont là pour améliorer la productivité de la revue de code.

‍À faire

• Gardez les PR petites et contenues. Encore une fois, les sessions de raffinage sont importantes ici, car des histoires et sous-tâches bien définies facilitent cette tâche. Les PR brèves sont plus faciles à lire et à réviser. Du côté de l’auteur, cela permet de lutter contre l’étendue excessive du projet et de réduire les bugs introduits à mesure que la PR évolue avec les retours reçus.

• Réservez du temps pour la revue de code chaque jour dans votre emploi du temps. En raison de la taille de notre équipe, nous avons trouvé qu’il était plus efficace d’avoir deux créneaux de revue de code dans la journée. La plupart d’entre nous examinaient les PR une fois le matin et une fois l’après-midi. Trouvez le bon rythme pour votre contexte et restez cohérent.

• Révisez vos propres PR avant de demander à d'autres de les examiner. Assurez-vous d’avoir écrit une description décente de la PR et d’avoir utilisé les bons tags. Si possible, faites une petite pause après avoir codé, puis relisez le diff avec un regard critique. Vous serez surpris de voir combien de choses vous pouvez repérer sans que quelqu’un d’autre n’ait besoin de vous les signaler.

• Posez des questions quand vous ne comprenez pas quelque chose dans une PR. Un code propre doit être lisible, et si vous êtes confus, l’auteur doit le savoir. De plus, les PR et la revue de code sont un excellent moyen de partager des connaissances.

• Faites des retours à la fois constructifs et positifs. Nous savons tous que les retours constructifs sont essentiels pour la qualité du code et la croissance individuelle des développeurs. Cependant, les retours positifs sont également cruciaux. Quand vous repérez un code de bonne qualité et un bon travail d’équipe, soulignez-le et célébrez-le ! Cela encourage non seulement l’auteur de la PR à continuer de viser cette qualité, mais cela enseigne aussi aux autres réviseurs à faire de même.

Conclusion

‍
Nous espérons que nos 10 conseils et pièges à éviter vous seront utiles dans vos projets. Nous concluons par cette réflexion finale : une bonne revue de code va de pair avec une bonne culture d’équipe. Il est essentiel de développer la confiance et le respect, tant dans le code qu’en dehors, tout en cultivant un fort souci de la qualité du code et de la croissance des membres de l’équipe pour créer des logiciels performants. Si vous souhaitez concevoir un logiciel innovant avec une équipe qui valorise la qualité et la collaboration, contactez-nous dès aujourd’hui.