Augmentez l’efficacité des revues de code

Après avoir abordé les « quatre types de revues de code  », nous vous donnons des conseils pour améliorer votre processus. 

Au programme : 

• Être un meilleur réviseur
• Être un meilleur programmeur
• Établir une gouvernance de la revue de code

Être un meilleur réviseur

Voici quelques habitudes à prendre pour améliorer vos revues de code :

• Révisez entre 400 et 500 lignes à la fois, pas plus.
• Limitez vos révisions à des sessions d’une heure.
• Les revues de codes devraient être effectuées quotidiennement, idéalement à heure fixe.
• Utilisez des listes de vérification (ex. : les critères sont-ils tous respectés? l’unité de code a-t-elle été testée?
  le code présente-t-il des failles de sécurité? )
• En cas d’incertitude, posez des questions aux auteurs au lieu de trancher directement.
• Accompagnez vos commentaires de suggestions.
• Utilisez des supports visuels pour expliquer.
• Acceptez qu’un problème puisse avoir différentes solutions.
• Parfois, il n’y a rien à modifier, et c’est normal.
• Évaluez objectivement le code sans en juger l’auteur.

Félicitez l’auteur pour ses bons coups. Dans les mots d’April Wensel (EN) : « Demandez-vous toujours si vos rétroactions sont justes, nécessaires et bienveillantes. »

Être un meilleur programmeur

En tant qu’auteur de code, on s’investit souvent émotionnellement dans son travail. Voici quelques idées à garder à l’esprit quand vient le temps de la revue :

• Vous n’êtes pas votre code. Prenez du recul et rappelez-vous que le réviseur est là pour offrir une critique constructive sur le code, et non pour vous juger.
• Soyez humble. Rappelez-vous que votre objectif commun est de livrer du code bien écrit, concis et sans erreurs.
• Fournissez des supports visuels pour montrer les modifications apportées (captures d’écran avant/après et exemples de résultat), surtout si ces modifications portent sur une interface utilisateur. Ce faisant, vous faites gagner du temps au réviseur, qui n’aura pas besoin d’exécuter l’application pour vérifier les changements.
• Vous êtes le premier réviseur : gardez un œil critique sur votre propre travail. Avant de demander une revue, révisez votre code vous-même.
• Annotez les changements importants.
• Utilisez un titre concis incluant un numéro de suivi/de référence.
• Expliquez la raison des changements apportés (EN).

Établir une gouvernance de la revue de code

Pour plus d’efficacité, nous vous recommandons de suivre ces lignes directrices une fois que votre équipe s’est accordée sur un type de revue. Voici les étapes que nous avons suivies pour créer notre cadre de gouvernance de revue de code.

Charte de programmation d’équipe

Créez une charte de programmation d’équipe axée sur des méthodes quantitatives. Elle pourrait comprendre les principes suivants :

• Exigez que le code soit écrit de manière itérative. Cette approche encourage des rétroactions tôt dans le processus et permet d’établir un cycle continu de tests et d’intégration.
• Gérez les critères en tenant compte de leur nature dynamique et évolutive.

Pratiques exemplaires

Établissez et respectez des pratiques exemplaires. Quelques exemples :

• Nomenclature pour les variables, les modules, les API, etc.
• Règles et style d’indentation
• Commentaires et information de l’en-tête

Compartimentation

Une équipe qui compartimente son code aura plus de facilités à trouver les détails les plus minuscules. Cette approche allège également le fardeau du réviseur.

• Compartimentez le code en modules pour mieux répartir les tâches.
• Modélisez visuellement le logiciel à l’aide d’un des nombreux outils existants. Le but, c’est de préparer une feuille de route à laquelle toute l’équipe peut se référer.

Créez un modèle de revue/une liste de critères de validation

Créez un modèle de revue avec la méthode de votre choix (en fonction des pratiques et de la structure de votre entreprise). Celui-ci aidera aussi les nouveaux employés à comprendre ce qu’ils doivent faire.

Pensez à inclure une liste de critères de validation à ce modèle. Quelques exemples de questions à intégrer à cette liste :

• Le code est-il dupliqué dans un autre module?
• Le code remplit-il plusieurs fonctions? Chaque module de code ne devrait avoir qu’un seul objectif.
• Le module de code est-il trop long ou complexe? (trop de lignes ou trop de fonctions)

Automatisation

Facilitez la vie de votre équipe en automatisant le plus de processus possible. Automatiser les tâches de base est toujours une bonne idée :

• Analyse statique. Utilisez un programme d’analyse statique pour repérer les erreurs de code qui auraient pu vous échapper.
• Créez des scripts de test pour vérifier les unités et leur intégration.

Test de la qualité

La qualité doit rester le mot d’ordre. Les auteurs du livre Understanding and Controlling Software Costs (EN) (Comprendre et gérer les coûts en développement logiciel) expliquent que les erreurs de code (bogues) sont d’une centaine à un millier de fois plus coûteuses à corriger après le déploiement. La solution : porter une attention particulière à la sécurité et à la qualité dans la programmation et les revues de code.

Conclusion

Les revues de code font partie intégrante du cycle de développement logiciel. Les programmeurs qui s’attendent à une revue créent du code de plus grande qualité : non seulement les pratiques exemplaires guident les nouveaux, mais elles assurent aussi l’uniformité des produits.

Les réviseurs qui peuvent se référer à une feuille de route se concentrent plus facilement sur leurs tâches. Ils peuvent s’atteler aux revues sans douter de ce qui est attendu d’eux.

Les retombées des pratiques exemplaires de revue de code sont à la fois immédiates et cumulatives. Certains avantages se feront ressentir tout de suite, tandis que d’autres se manifesteront après quelques semaines ou quelques mois.

Pour faire simple, une bonne revue de code est synonyme d’un bon produit.