Outils d'analyse de code : "Pure Player" ou "Tout en un" ?

Quand on aborde l'outillage des développeurs pour contrôler la qualité du code, on entre souvent dans un débat entre opérationnels et managers : faut-il un outil global pour gérer l'ensemble des langages/domaines qualité, ou un outil dédié pour chaque technologie ?

J'aurais tendance à dire "les deux, mon capitaine !".
Dans cette chronique, je vous propose d'aborder les avantages d'avoir un seul outil intégrant les spécificités et règles de chaque technologie ou aspects qualité.

D'un côté, il y a les "contre", réticents à n'avoir qu'un seul outil pour gérer l'ensemble de la qualité du code des projets de développement. Dans ce groupe, probablement constitué en majorité par les développeurs eux-mêmes, nous entendrons souvent les objections suivantes :

• Chaque projet est unique et nécessite des règles différentes, donc des outils différents. FindBugs sera plus orienté "bug", alors qu'un PMD fait le focus sur les bonnes pratiques de programmation.
• Moi je suis un "addict" de JSLint. J'y suis habitué et j'ai pas envie d'utiliser un autre outil. Je serais d'ailleurs moins productif...
• Avec un outil trop généraliste, il sera difficile d'adresser les problématiques qualité propre à un langage, un framework, un aspect qualité précis... on aura pas les règles qui identifient les vrais problèmes de qualité.

Bien évidemment, de l'autre côté (ne parlons tout de même pas de camps !), se trouvent les partisans d'un outil qui centraliserait les fonctionnalités et règles de programmation pour contrôler la qualité du code. Les arguments avancés sont plus économiques et managériaux que purement techniques. Ils n'en sont pour autant pas moins fondés :

Alors, quelle est la meilleure approche ? En fait -et c'est un peu l'esprit général de cet article- tout le monde a raison ! Pour réconcilier les pros et les antis, la clé réside dans l'intégration. Dans les quelques lignes ci-dessous, nous allons développer 5 bénéfices clés induits par le déploiement d'un outil d'analyse de code unifié.

Bénéficier des meilleures règles de chaque outil dans une interface unique

Au niveau de maturité actuel de l'industrie open source en termes d'analyse de code, les règles issues d'outils comme PMD, Checkstyle, PHP Code Sniffer ou JSLint sont devenues de facto des références. Utiliser (ou imposer) un outil unique - bien souvent sous licence commerciale - qui n’intégrerait pas ces règles en standard est à mon sens une erreur. Vous vous priveriez d'un capital de plusieurs dizaines d'années hommes de recherche dans le domaine.

Même si, finalement, beaucoup de règles se recouvrent (ex: CloseResource de PMD et ODR_OPEN_DATABASE_RESOURCE de Findbugs), l'intégration de ces règles dans un outil unique comme Scertify, permet de disposer d'un catalogue de plus 1600 règles. Bien évidemment, toutes ne sont pas à activer dans votre profile qualité, au risque de vous arracher les cheveux à vouloir toutes les corriger ! Néanmoins, ce catalogue permet de construire un profil qualité relativement complet couvrant l'ensemble des différents domaines qualité.

On sait par exemple que les règles de FindBugs sont davantage orientée "fiabilité" (ex: BC_IMPOSSIBLE_CAST, J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION), alors qu'un Checkstyle, comme son nom l'indique, supporte essentiellement les règles de programmation liées à la maintenabilité et la lisibilité (ex: AbstractClassNameCheck,  ConstantNameCheck). Un outil unifié permet donc de contrôler ces différents types de règles sans imposer à l'utilisateur d'analyser son code successivement avec les deux outils.

Garantir un niveau de conformité minimal por tous les projets

Un outil unique permet de déployer facilement un référentiel commun de règles "mandatory" applicables à l'ensemble des projets d'un même langage. Ces règles sont alors beaucoup plus faciles à faire respecter par l'ensemble des développeurs : la définition est claire car donnée par un seul outil. Ce référentiel, qui peut comprendre un scope d'une vingtaine de règles ou métriques au début, peut alors évoluer en intégrant progressivement davantage de contrôles.

• Bonnes pratiques liées à des frameworks spécifiques (par exemple Hibernate)
• Gestion des exceptions
• Libération des ressources base de données/fichiers
• Complexité maximale par méthode
• Conventions de nommage

Un seul outil pour des projets multi-technologies (ex: Java / Javascript)

Dans le monde J2EE, et plus généralement dans l'industrie logicielle, les développements ne se font pas en silo technologique. Dans un projet, les composants Java, Javascript, SQL ... cohabitent. Dès lors, avoir un seul outil pour contrôler la qualité de l'intégralité du code est un réel avantage : là encore, pas besoin de passer d'un outil à un autre pour identifier les problèmes.

Imaginez juste le confort de n'avoir qu'un seul outil pour contrôler le code d'une application web Java / Javascript, qui accèdes aux données d'une base MySQL via Hibernate.

Cohérence entre le poste du développeur et les analyses effectuées Intégration Continue

Un contrôle qualité homogène entre le poste du développeur et le reporting qualité "macroscopique" garantit également l'efficacité des plans d'actions.

Dans la plupart des cas, les plans d'action pour améliorer la qualité du code sont mis en œuvre à chaque sprint ou release, à partir du des résultats synthétiques fournis par les outils d'analyse en intégration continue.
De ce fait, si le profil qualité (règles activées et à respecter dans le code) est synchronisé entre les outils du développeur et ceux de l'Usine Logicielle, c'est autant de temps de gagné pour l'application des plans d'action qualité et la correction effective des violations. Aujourd'hui, quel développeur utiliserait une vieille carte routière pour trouver son itinéraire alors qu'il pourrait utiliser son GPS ?

Coût de formation, déploiement, maintenance réduits à un seul outil

Nul besoin de s'attarder davantage sur ce point : il est évident qu'un seul outil permet de rationaliser les coûts induits pas la formation aux outils et méthodes. De même, les évolutions fonctionnelles de l'outil choisi seront synchronisées pour l'ensemble des utilisateurs. Enfin, l'intégration de cet outil à d'autres, déjà communément utilisés par les développeurs (comme Eclipse et Maven), réduit grandement l'effort nécessaire à l'apprentissage et à l'adoption de l'outil.

Par expérience, ces coûts de formation -même s'ils sont marginaux sur un projet de développement- sont loin d'être négligeables sur le coût total d'un projet de qualimétrie et jouent un rôle prépondérant dans l'adoption de l'outil ET de la démarche qualité. Ce serait une erreur de ne pas prendre ce point en considération. Ce sera d'ailleurs le thème d'une série d'articles à venir prochainement : les pièges courants à éviter lors de la mise en place d'un projet de qualimétrie.