La qualité du code source produit est essentielle pour assurer la cohérence, la performance et la maintenabilité des applications. Cette qualité peut être obtenue en continu via des outils d'analyse mais ce n'est pas toujours suffisant.

Les bugs trouvés en production restent les plus coûteux, c'est pourquoi il est primordial de pouvoir les déceler à temps de façon à pouvoir les corriger au plus tôt.

Les sources du projet doivent être correctement organisées, aisément lisibles et respectant les normes de codage pour en assurer la maintenance et les évolutions possibles. Il est fort probable que ça ne sera pas la même équipe qui s'occupera de la maintenance ou des évolutions qui seront faites tout au long du cycle de vie du projet.

Améliorer la qualité du code

Certaines tâches peuvent être facilement mises en œuvre voire automatisées via des outils d'intégration continue :

• Manuellement
  • Définition des normes de codage
  • Formation de l'équipe projet
  • Bonnes pratiques
• Via des outils (généralement déjà intégrés dans les IDE)

Outils et méthodes

Analyse statique

Quelques exemples d'outils d'analyse statique :

• Lint (et ses variantes selon les langages, ESLint, Pylint, etc.)
• Findbugs
• Checkstyle
• SonarQube, multi-langages, il permet de faire des mesures sur la qualité du code en continu (duplication de code, documentation, règles de programmation, détection de bugs potentiels, couverture de code par les tests unitaires, etc.)

Ces outils permettent d'effectuer des contrôles automatisés : complexité du code, respect de règles de codage, taux de couverture des tests unitaires, etc. Mais ils ne peuvent pas répondre à des questions plus abstraites :

• Pertinence par rapport aux exigences
• L'architecture choisie
• Éventuelles anticipations sur les changements technologiques qui peuvent venir
• Réutilisabilité
• La connaissance métier

Une relecture systématique du code au sein de l'équipe projet est la seule solution. En plus de répondre à ces questions, cette revue de code apportera :

• Une amélioration continue de la qualité du code grâce aux suggestions ;
• L'appropriation du code global du projet par l'équipe. C'est un excellent moyen pour enseigner indirectement aux autres membres de l'équipe projet les parties sur lesquelles ils auront à intervenir plus tard ;
• La formation en continue des développeurs. La revue de code peut encourager les personnes à apprendre les bonnes pratiques et voir de nouveaux aspects avec les autres membres de l'équipe ;
• Une validation globale des choix technologiques pour plus de clarté et de simplicité sur le projet.

Peer review

J'ai eu l'occasion d'utiliser sur un projet assez conséquent Phabricator notamment pour faire du peer review. Il en existe d'autres sur le marché comme par exemple Atlassian Crucible (payant) ou Gerrit (trop lié à Git et pas très souple pour l'avoir déjà utilisé). Phabricator a le mérite d'être libre et de couvrir parfaitement ce besoin.

Phabricator

Phabricator initialement développé pour Facebook est une collection d'applications web open source pour le développement logiciel.

La suite offre notamment :

• Differential : revue de code
• Diffusion : navigateur
• Herald : outil de surveillance des modifications
• Maniphest : suivi de problèmes
• Phriction : wiki
• Arcanist : interface en ligne de commande
• Conpherence : client de messagerie

Il gère les dépôts Git, Mercurial et Apache Subversion. Il est également possible de se connecter avec des dépôts existant comme GitHub ou Bitbucket.

Le gros avantage qu'il apporte aussi est qu'il joue le rôle de "proxy" envers le dépôt principal du projet. Seuls les changements validés sont "pushés" sur le depôt maître. Ça évite ainsi de polluer inutilement le projet avec des commits qui seraient rejetés par l'équipe.

Vous pouvez essayer la version de démonstration et ainsi voir toutes les possibilités offertes par la suite.

Comment démarrer et faire une bonne revue de code

On n'impose rien, on y va progressivement

Allez-y pas-à-pas en employant en partie les patterns suivants :

• Ne revoir que les parties du code les plus complexes, les plus critiques ;
• Ne revoir le code que sur demande du développeur ;
• Ne revoir le code que des développeurs débutants. Ce point n'est pas péjoratif envers les développeurs juniors mais c'est un bon moyen pour commencer et présenter notamment les bonnes pratiques à avoir et les bons patterns de développement à appliquer sans forcément être magistral dans ses propos.

Une fois la pratique entrée dans les mœurs, il sera alors plus facile de l'étendre de façon plus systématique au sein de l'équipe projet.

Gérer la conduite du changement

Il faut aussi penser à traiter la conduite du changement vis-à-vis des développeurs qui auront sans doute des réactions de rejet :

• Ça 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 …

À propos du temps "perdu", le rapport coût/bénéfice est immédiat : on connaît tous 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, IntelliJ IDEA, PyCharm, PhpStorm, etc.).

Des outils comme Phabricator permettent de faire la revue de code directement depuis une interface Web ce qui simplifie encore plus cette démarche surtout si on doit le faire en remote.

Enfin concernant les risques de dégradation de l’ambiance au sein de l'équipe, il existe quelques règles de base à respecter pour obtenir des revues positives :

Quelques règles de base à suivre

• Faites fréquemment des revues de code

Le faire à la fin, c'est bien dommage et souvent inutile car trop tard… Avoir des revues de code tardives présentent les inconvénients suivants :

• Plus il y a de code à examiner, plus il est probable que le développeur n'accepte pas qu'on lui suggère de refactorer son code ;
• Plus le code est "ancien", plus grande est la probabilité que le développeur soit personnellement attaché à son code (problème d'ego) ;
• Plus la deadline est proche (fin de sprint, livraison), moins on accorde d'importance aux améliorations du code pouvant entraîner du même coup une dette technique sur le projet.

• Faites des revues de code informelles et courtes

Elle ne doit porter que sur la tâche ou la feature à développer et rien d'autre :

• Ne pas chercher systématiquement des erreurs dans le code. C'est à la charge du développeur (par principe on ne doit jamais commiter un code qui ne compile pas !) ;
• Ne pas vérifier si les normes de codage sont respectées ou que le code est bien commentée ou non. Les outils d'analyses s'en chargeront ;
• Ne pas chercher systématiquement des solutions. C'est aussi à la charge du développeur.

Mener des revues de code courtes et informelles vous permettra d'engager des conversations ouvertes dans lesquelles la personne ne se sent pas "auditée", mais plutôt aidée et conseillée.

• Réalisez vos revues de code avec différentes personnes

 Si possible, essayez de changer régulièrement de membre de l'équipe pour faire la revue. Ceci a l'avantage de :

• pouvoir disposer des autres points de vue ;
• permettre un meilleure partage des connaissances au sein de l'équipe ;
• ce n'est pas une personne qui mène la revue de code mais l'équipe.

• Conservez une attitude positive

Essayez toujours d'avoir une attitude positive pour que la revue de code soit agréable et se déroule bien. Le développeur sera alors mieux à même d'accepter les retours pour le bien de toute l'équipe :

• Tous les membres de l'équipe y trouveront leur compte en partageant la connaissance ;
• L'apprentissage se fait en continu pour tout le monde.

• Apprenez à apprécier les revues de code

Aussi pour le bien de l'équipe où tout le monde se sentira plus engagé afin de proposer un code de qualité pour la bonne marche du projet.

Au-delà : La revue de code en continu

Parfois les contraintes liées au projet ne permettent pas vraiment de mettre en œuvre ces pratiques via un outil dédié permettant de faciliter la revue de code :

• Équipe trop réduite, donc intérêt discutable pour motiver les développeurs ;
• Contraintes de temps, donc un sentiment de perte de temps sur un petit projet.

L'approche qui peut être faite de manière informelle est de faire de la revue de code en continu en travaillant en binôme (pair programming). Cette approche peut être envisagée sur des aspects critiques du projet pour faciliter les échanges et de trouver la meilleure approche pour répondre aux besoins et aux contraintes du projet. Le pair programming offre des avantages certains :

• Bonne cohésion de l'équipe. On a un échange permanent au sein de l'équipe ;
• Partage aisée des connaissances ;
• Un meilleur code. En échangeant en permanence, il est plus facile de trouver la bonne approche concernant l'implémentation tout en vérifiant si elle peut répondre efficacement au besoin initial. La revue de code se faisant en permanence pendant le développement.

Avec deux inconvénients majeurs :

• Deux personnes sont mobilisées pour une seule tâche ;
• Ces deux personnes doivent savoir travailler en paire. Certaines personnes resteront plus efficaces en travaillant seules.