• Article
  • 27.Juil.2010

Revue de code pour les équipes trop occupées

  • 27.Juil.2010
  • Temps de lecture mins

En juin 2010, lors de l’Atlassian Summit, j’ai assisté à une conférence intéressante sur le change management nécessaire pour accompagner un déploiement des techniques de revue de code par les pairs et d’analyse statique du code. J’ai pensé qu’une retranscription de mes notes pourrait être intéressante pour la communauté francophone.

Introduction

Le développement logiciel génère du code source dont la qualité est essentielle à la cohérence, la performance et la maintenabilité des applications. Il existe plusieurs activités permettant de contrôler et améliorer cette qualité, la revue de code en est une.
Un rapport Gartner de 2008 propose quelques conclusions intéressantes sur le sujet.

Extraits :

Conclusions

  • L’intégration de revues par les pairs et d’analyses statiques du code dans le processus de build a pour résultat une amélioration majeure de la qualité du code.
  • Les revues par les pairs créent un environnement de compréhension mutuelle et de collaboration autours du code.
  • L’analyse statique permet l’application d’un ensemble cohérent de standards.

Recommandations

  • Implémenter un processus de build incluant l’analyse statique et la revue par les pairs pour tout nouveau code intégré dans le build.
  • Coupler l’analyse statique et la revue par les pairs pour accroître le périmètre et la profondeur des revues de code.

De l’utilité de la revue de code

Le coût des bugs

Le code peut potentiellement contenir des défauts majeurs, et générer des erreurs graves et très couteuses pour le métier. Plus tôt les défauts sont détectés et corrigés, moindre est le coût total des effets et de la correction.

La maintenabilité du code

Le code doit aussi pouvoir être maintenu, généralement par des tiers : lisibilité et respect des règles de codage sont de rigueur.

Les méthodes pour améliorer la qualité de son code

Des activités permettent d’améliorer la qualité de ce code en amont ou pendant sa production. On parle d’activités pro-actives.

  • Faîtes par les hommes :
    • Définition de règles de codage
    • Formation des développeurs
    • Modèle de code
    • Pair programming
  • A l’aide d’outils, généralement intégrés dans les IDE :
    • Coloration syntaxique
    • Auto-complétion
    • Contrôle de références

Une fois le développement terminé, l’analyse statique permet d’effectuer des contrôles automatisés : complexité du code, respect de règles de coding, taux de couverture des tests unitaires…

Cependant ces outils ne sauront pas répondre à des questions plus abstraites :

  • Pertinence par rapport aux exigences
  • Efficience de l’architecture
  • Anticipation de changements technologiques futurs
  • Réutilisabilité
  • Bonne connaissance métier

Afin d’avoir cette hauteur de vue, une relecture systématique du code par des pairs est la seule solution. En plus de répondre à ces questions, la revue apportera :

  • Une réduction du nombre de défauts
  • L’appropriation du code par l’équipe
  • La formation des développeurs

Toutefois la mise à disposition du code source aux relecteurs et la consolidation des annotation est quelque chose de difficile à réaliser dans la pratique. Les « Formal Code Inspections » décrites par Michael Fagan, manager de développement produit chez IBM, en 1986 apportent un formalisme difficile à mettre en pratique :

  • Impression du code et annotation sur papier
  • Processus rigide et réunions en face à face entre le développeur et les relecteurs
  • Lenteur
  • Impraticable pour des bases de code importantes

Afin de conserver les effets positifs de ces revues tout en allégeant leur formalisme pour les rendre réalistes quel que soit le contexte, un outil est pratiquement indispensable.

Problèmes logistiques mis à part, l’autre point critique de la mise en œuvre est le changement induit dans les habitudes des équipes de développement. Il existe plusieurs leviers pour avancer vers cette culture de l’échange autours du code :

  • Rendre l’activité de développement visible
  • Partager le code source
  • Encourager les discussions autours du code

Les outils pour appliquer ces méthodes

Analyse statique

Les programmes suivants sont quelques exemples d’outil d’analyse statique :

Peer Review et discussions autours du code

Atlassian Crucible outille la revue de code de façon simple et flexible :

  • Revues asynchrones
  • Workflows et notifications
  • Enregistrement des échanges
  • Classification des défauts
  • Création de revues à partir de JIRA

Il permet l’enregistrement des échanges autours d’une partie du code ou d’un change set :

  • Demande de feedback quand nécessaire
  • Annotations intégrées dans les revues
  • Enregistrement de commentaires dans des fils de discussion
  • Suggestion intelligente du meilleur reviewer

A savoir que la nouvelle fonction « snippet » permet désormais d’effectuer des revues sur du code non commité, à l’aide d’un simple « copier-coller » du source à relire dans l’interface Web.

Visibilité du code source

Atlassian Fisheye donne de la visibilité sur le contenu a priori obscur des repositories de code source grâce à ses fonctions de navigation en ligne ; et sur l’activité de développement à l’aide de sa fonctionnalité « activity stream » listant l’ensemble des commits d’un projet, avec la date, le committer, le commentaire saisie et les fichiers modifiés immédiatement consultables.

Fisheye est également une solution de partage du code puisqu’il fournit un accès en lecture à l’ensemble du code sans nécessité d’installation ou de téléchargements massifs. On accède rapidement et en ligne aux révisions, aux diffs, aux change sets.

Comment démarrer sans heurt ?

Démarrer progressivement

Pour démarrer sans heurt, on suggère d’y aller pas-à-pas en employant tout ou partie des patterns suivants au démarrage :

  • Ne revoir que les parties du code les plus complexes
  • Ne revoir le code que sur demande du développeur
  • Ne revoir le code que des développeurs débutants

Une fois la pratique entrée dans les meurs, il sera facile, voire évident, de l’étendre de façon systématique si besoin.

Gérer le changement humain

Il faut aussi penser à traiter la conduite du changement vis-à-vis des développeurs qui auront généralement les réactions suivantes :

  • Ca prend trop de temps !
  • Je ne veux pas sortir de mon IDE
  • Les revues peuvent prendre un ton désagréable et les commentaires devenir acerbes

Concernant le temps “perdu”, le rapport coût bénéfice est immédiat : voir l’introduction concernant le coût des bugs et la difficulté à maintenir un code illisible.

Concernant l’IDE, les outils proposés offrent des intégrations avec les principaux acteurs du marchés (Eclipse, Visual Studio, Rational Team Concert…)

Enfin concernant les risques de dégradation de l’ambiance et des relations, il existe quatre règles de base à respecter pour obtenir des revues positives.

Respecter les règles de base

1. Ne pas rentrer dans des combats d’ego

  • On évite les pronoms personnels
  • On pose des questions au lieu d’asséner des remarques
  • Utilisation d’un modérateur

2. Ne pas être pédant ou magistral

  • Les règles de base doivent être contrôlées par des outils automatisés, pas dans les revues
  • Avoir un point de vu général, ne pas être trop pointilleux : on regarde la forêt, pas les arbres

3. Trouver des problèmes, pas des solutions

  • Laisser le développeur trouver les solutions, c’est son job
  • A part pour les défauts mineurs
  • Préférer le pair programming si le besoin de proposer des solutions est trop important

4. Accepter les retours

  • Ils permettent d’apprendre
  • Ils enrichissent tout le monde

Voilà, j’espère que ces quelques lignes vous auront donné quelques idées pour votre propre organisation.
Bonnes revues de code ! 🙂

Ressources complémentaires

Voir toutes les ressources