Ce billet inaugure notre blog, qui vise à partager notre expérience sur la qualité des développements C# et Java. Cette expérience est celle des membres de notre équipe R&D, mais aussi celle qu’accumule chaque jour notre plateforme Cockpit, à partir des millions de lignes de code analysées sur les projets de nos clients.
Nous avons créé le Cockpit après avoir constaté qu’aucun outil ne proposait de piloter la qualité des développements Java ou C# de manière aussi simple et pragmatique que nous recherchions. Il y a pourtant un large potentiel d’amélioration dans la domaine de la qualité technique des développements. On trouve schématiquement deux grandes catégories d’outils sur ce marché :
- des agents d’analyse, souvent OpenSource pour le monde Java, qui sont généralement spécialisées sur certains types de détections (métriques, styles, mauvaises pratiques, duplications de code, …), et pour un langage particulier
- des produits, presque toujours commerciaux, qui agrègent les différents types de mesure et adressent plusieurs langages de natures parfois très différentes (objet, procédural, langages de requêtage, …).
Les premiers s’adressent majoritairement aux profils techniques : développeurs, architectes, chefs de projet techniques, … Leur mise en oeuvre est plus ou moins complexe mais l’effort demandé apparaît surtout lors des étapes suivantes : paramétrage des règles et des seuils, intégration dans un processus automatisé, sensibilisation et formation des développeurs, définition et suivi d’un plan d’amélioration pour corriger les alertes remontées, maintenance de la configuration et des mises à jour de l’outil, … Je détaillerai tous ces à-côtés dans un prochain billet.
Concernant les produit commerciaux, les deux freins que nous avions identifiés et qui nous ont été confirmés par nos clients sont le coût et la complexité d’utilisation. Ce type de produits a généralement un coût de licence assez élevé (plusieurs dizaines de K€), auquel il faut parfois ajouter des frais d’installation, de paramétrage, de mise à jour, de conseil et de support. Peu de projets peuvent dégager les budgets nécessaires. Ce coût s’explique souvent par la richesse de fonctionnalités offertes à l’utilisateur, ou par sa flexibilité de paramétrage. Mais ces caractéristiques rendent également l’utilisation du produit plus complexe.
Dans les deux cas, de nombreuses tentatives de mise en oeuvre échouent, pour des raisons diverses :
- les développeurs ne maîtrisent pas assez les indicateurs qui sont remontés
- ils se considèrent noyés sous les alertes
- les informations présentées sont trop techniques, elles n’offrent pas une vision compréhensible de la qualité pour les chefs de projet et les manageurs qui ne peuvent l’intégrer dans la gestion des projets
- chacun a du mal à mesurer le retour sur investissement de ce processus qualité
Dans ces conditions, le suivi de la qualité apparaît plus comme une contrainte qu’une aide à l’amélioration du projet.
Ce constat peut sembler caricatural, beaucoup de projets se satisfont sûrement des outils qu’ils ont adoptés et jugent leur propre processus efficace. Il nous semble malgré tout assez représentatif, c’est pourquoi nous avons réfléchi à une approche de la qualité différente, qui puisse vraiment être perçue comme positive par tous les acteurs du projet, et non pas comme un seul gage théorique :
- le suivi de la qualité doit être simple. C’est pourquoi nous avons privilégié un modèle SaaS où l’utilisateur n’installe rien dans son infrastructure et peut initialiser une première analyse en quelques heures. Ce suivi doit s’intégrer dans le processus de développement de l’entreprise (agile, cycle en V, intégration continue, etc…).
- le suivi de la qualité doit être pragmatique. Les exigences qualité doivent être adaptées aux besoins et au contexte du projet. Tous les projets n’ont pas les mêmes exigences qualité, et la sur-qualité est coûteuse. Il vaut mieux travailler sur un objectif réaliste que l’équipe est capable d’atteindre, quitte à affiner ses exigences au fur et à mesure.
- les différents acteurs du projet doivent partager la même vision de l’état de la qualité. Pour cela l’angle de vision sous lequel les informations sont présentées doit être différent selon les acteurs qui le consultent, par exemple un directeur de projets et un développeur, mais il doit exprimer le même constat. Le fait de recourir à un service tiers externe au projet facilite d’ailleurs l’adoption de cette vision commune.
- les règles de qualité doivent être à jour et adaptées à l’état de l’art en cours. Les technologies de développement évoluent (langages, frameworks, …), les règles doivent suivre cette évolution. Disposer d’une base de statistiques alimentée quotidiennement à partir du code des projets analysés nous semblait un point-clé pour garantir un référentiel de règles actualisé et pertinent.
Voilà pour introduire notre approche. Nous travaillons depuis plus de 3 ans sur notre technologie. Nous avons pu valider notre approche, valider son utilisation par nos clients, et avons maintenant matière pour partager nos résultats avec vous. Les prochains billets seront donc plus concrets et traiteront plus directement de ce retour d’expérience.
