Review de code: pros & cons

L’Afup met a disposition une série de vidéos de ses conférences. Parmi celles-ci, une présentation intéressante de Jean-Marc Fontaine au PHP Tour Nantes 2012 sur la review de code.

J’en profite pour souligner les avantages des reviews de code tels que décrits durant cette conférence:

Proche de l’agilité

  • pear-coding
  • responsabilité collective du code
  • valeur de courage

Pour quelle raison faire des review?

  • Parce qu’au bout d’un certain temps, on ne voit plus son propre code.
  • Complémentaire aux outils d’analyse qui ne sont pas adaptés aux problèmes fonctionnels et logiques.
  • Complémentaire aux tests unitaires.

Pros

  • Trouver des bugs.
  • Relever des problèmes de conception.
  • Contrôler le respect des bonnes pratiques, des conventions, des standards…
  • Harmoniser le code.
  • Vérifier la conformité à la demande et l’exhaustivité des fonctionnalités.
  • Participer au partage de connaissance technique et business.
  • Contribuer à maîtrise collective du code, à la responsabilité commune de l’ensemble du code.
  • Former les nouvelles recrues.
  • Apporter des idées neuves et hausser le niveau technique de l’équipe.

Cons

  • Coût.
  • Temps.
  • Freins humains.
  • Organisation.
  • Méthode non exhaustive.

3 réflexions au sujet de « Review de code: pros & cons »

  1. Hello,
    Je suis arrivé ici suite à ton tweet sur mon poste (http://blog.8thcolor.com/en/2014/04/5-reasons-you-are-not-doing-code-reviews).

    Chouette liste de « pros » et surtout dans des directions différentes. J’aime beaucoup la dernière « apporter des idées (un regard) neuf ».

    Pour les « cons », je pense que le temps & le coût sont une seule et même chose et souvent un argument fallacieux: j’aurais du mal à défendre de faire des review (ou toute autre « bonne pratique ») si je ne pensais pas (progressivement expériences à l’appui) qu’elle permet au final de délivrer plus et mieux (en tant qu’équipe de développement, cela reste le sens de notre boulot).

    Je serais intéressé par ton expérience sur comment faire face à ces freins justement ?

    Martin

    • Bonjour,

      Merci pour ton commentaire, et surtout merci pour ton article intéressant ;-) . Je ne savais pas que tu parlais français vu que l’article est en anglais, c’est une bonne surprise.

      Pour éviter toute ambiguïté, l’article que j’ai publié reprend essentiellement les thèmes évoqués dans une conférence de Jean-Marc Fontaine (donc pas de moi) qui est notamment un des auteurs du Livre blanc sur l’industrialisation de PHP. Par contre, je partage entièrement ces idées.

      La review de code et la gestion de la qualité du code dans son ensemble sont des thématiques qui m’intéressent beaucoup. J’ai eu l’occasion de reviewer du code de développeurs, et c’est une expérience enrichissante, qu’on review ou qu’on soit reviewé.

      Clairement, j’ai assisté à un upgrade assez important du niveau de qualité du code, et des exigences minimum de qualité qu’on puisse demander à une équipe de dev. Cela contribue aussi au partage des connaissances techniques et des règles business d’une app.

      Mais, à l’inverse, ce n’est pas toujours bien vécu, tant de la part des développeurs que des managers.

      Les développeurs sont remis en question et doivent revenir dans un code qu’ils pensaient avoir terminé. Dans ce cadre, je pense que l’important, c’est d’expliquer pourquoi on désire amener ce changement. Se focaliser sur la raison (le pourquoi), plus que sur la modification dans le code (le comment). En quoi ce changement peut être intéressant à terme. S’il se révèle une contrainte dans un premier temps (changer ses habitudes est toujours difficile, c’est la force de l’inertie), il va vite se transformer en atout. La qualité de codage consiste à arriver à un code évident et, au final, à simplifier la vie du codeur. C’est donc payant pour les développeurs.

      Quand aux managers, le temps c’est de l’argent… Le seul vrai argument en faveur de cette pratique, c’est donc que cela permet de réduire la dette technique de manière importante, et, en même temps, de réduire la dette de qualité. On peut voir ça à la fois comme une forme de refactoring tel que le prône XP, ainsi qu’une façon d’augmenter le savoir-faire des équipes tel que le prône aussi l’agilité. On a un code plus maintenable et des équipes plus compétentes, c’est ça la plus-value réelle pour l’entreprise.

      Je crois beaucoup au « refactoring continu » comme meilleur moyen pour minimiser la dette technique. Encore faut-il que le management ait conscience qu’une dette technique, au-delà d’embêter les développeurs, consiste en une véritable dette financière, d’autant plus importante que l’application vivra longtemps et devra continuer à être maintenue sur la longueur. Une dette technique sur un code qu’on ne retouche plus n’est pas trop importante. Mais une dette technique sur le coeur d’une app dont le business évolue peut avoir de graves conséquences et figer complètement son évolution. A ce propos, cet article résume bien la situation: http://www.infoq.com/fr/news/2014/04/managing-software-debt

      Par contre, même si j’en suis intimement persuadé, je pense qu’il est difficile de prouver de manière tangible qu’il s’agit d’une bonne chose pour l’entreprise. Le résultat est facilement visible dans le code, mais plus difficile au niveau de la gestion de projet. Il est difficile de sortir des chiffres objectivables. Et ça ne paie que sur le long terme. C’est un investissement qui demeure silencieux. Et un investissement c’est tojours une part de risque, mais c’est aussi vital si l’entreprise veut exister. On doit pouvoir bénéficier d’une confiance du management envers ses développeurs sans quoi cela risque de mal se passer.

      Donc pour résumer, ce qui permet de convaincre les gens:

      1/ réduction de la dette de qualité:
      - augmentation des compétences des dev.
      - parage du savoir entre dev.
      - meilleure considération du code et implication des dev dans le produit de l’entreprise.

      2/ réduction de la dette technique:
      - meilleure maintenabilité des applications.
      - un code plus agréable, plus lisible, plus gratifiant.

      Difficultés:
      - Il s’agit d’un investissement silencieux.
      - Il faut bénéficier de la confiance de tous.

      J’espère avoir répondu à ta question et t’avoir apporté quelques éléments pour nourrir ta réflexion. Je me rends compte que j’ai été un peu long, ça aurait presque mérité un nouvel article! ^^ N’hésite pas à me faire part de tes remarques.

      Raphaël

      • Hello,
        Merci beaucoup ! En te lisant je me disais: il devrait en faire un article à part entière, je vois qu’on se rejoint (honnêtement, fais le, je pense que c’est intéressant).

        D’accord avec toi sur la difficulté d’objectiver, je parle plus souvent d’expérience que de rapports Gartner ou équivalent.

        Tu notes un bon point sur la difficulté pour un développeur de revenir sur du code « fini ». C’est une des raisons pour lesquelles je trouve très important que la review vienne « vite ». Dans une équipe que je coach, nous avons une règle: s’il y a une issue qui est prête à être revue, elle a priorité sur le fait de commencer toute nouvelle tâche. Cela assure que les revues sont faites rapidement, et par la première personne disponible (et pas uniquement par un « expert »).

        Dans les conséquences dans la gestion de projet, j’en ai vu une claire et assez rapide: la capacité de l’équipe de passer d’un projet à l’autre, ou simplement de remplacer un membre parti en vacance, ce qui donne beaucoup de flexibilité, y compris côté gestion de projet.

        Merci encore pour l’échange (et vraiment, écris cet article).

        Martin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>