On nous demande parfois en quoi notre solution, le Cockpit, diffère d’outils OpenSource existants. Notre meilleure réponse consiste généralement à réaliser une démonstration de notre outil, mais l’objectif ici est d’avancer des arguments plus précis.
Tout le monde sait maintenant que la mise en place d’outils Open Source fait apparaître des coûts cachés. Beaucoup d’argumentations marketing ont fleuri sur ce sujet pour appuyer la position d’outils propriétaires, avec une expression de FUD parfois assez marquée.
Notre plateforme est elle-même basée une infrastucture incluant des produits OpenSource, nous sommes donc bien placés pour savoir que l’OpenSource est une alternative souvent pertinente. Le propos ici est simplement de préciser la complexité de la mise en oeuvre d’un plan de suivi de la qualité à l’aide des produits OpenSource disponibles actuellement. L’objectif étant de montrer que l’effort ne réside pas tant dans l’installation de l’outil que dans toutes les tâches annexes nécessaires à l’amélioration réelle de la qualité.
Sélection des outils
Le choix des outils est évidemment critique du fait qu’il conditionne les étapes suivantes. L’offre des outils liés à la qualité présente quelques particularités à connaître :
- elle est foisonnante. Plusieurs dizaines d’outils existent pour différents langages. Voici par exemple une liste non exhaustive : http://www.laatuk.com/tools/review_tools.html.
- les outils sont difficilement comparables. Les outils mesurant les métriques, par exemple, proposent chacun leur propre jeu de métriques. Et si certaines métriques se recoupent entre différents outils, leur calcul n’est pas toujours le même
- l’analyse de la qualité étant un sujet de recherche très prisé, beaucoup d’outils sont réalisés dans le cadre d’études universitaires. Avec parfois comme conséquences que leur développement s’arrête à la fin d’une thèse ou que l’outil ne s’avère pas forcément adapté à une utilisation pratique sur des projets professionnels (quelques exemples : ckjm, JMT, iPlasma, …)
Installation et intégration
L’installation de ces outils présente un degré de complexité qui varie fortement suivant les cas. Elle est généralement assez simple, seuls les outils de mashup, qui combinent différents types de mesure, nécessitent parfois un vrai travail de paramétrage ou d’installation d’outils tiers (cf. XRadar, QALab, …).
Il faut cependant noter deux choses :
- l’utilisation de ces outils n’est vraiment efficace que lorsqu’elle est industrialisée, par exemple au sein d’un processus d’intégration continue. Il faut donc modifier la procédure d’industrialisation existante pour lancer ces outils, mais aussi publier leurs résultats pour qu’ils soient accessibles à toute l’équipe
- pour obtenir une vision complète de la qualité d’un développement, il faut généralement agréger plusieurs outils qui apportent chacun des mesures différentes. Il est donc difficile d’obtenir une synthèse cohérente à partir de ces résultats hétérogènes. Quelques outils orientés mashup offrent un premier niveau de réponse à cette problématique.
Il faut enfin penser à la mise à jour de ces outils, soit pour résoudre des bugs ou apporter des nouvelles fonctionnalités ou nouvelles règles.
Paramétrage du projet
Au-delà de l’installation et du paramétrage inhérent à l’outil, il faut également configurer le périmètre du code à analyser. Selon les outils, il peut s’agir des sources brutes et/ou des sources compilées. Il faut également être capable de fournir les librairies tierces, celles utilisées pour la compilation et/ou pour l’exécution (ce qui varie selon les outils). Enfin, il faut généralement exclure une partie du code de l’analyse : code généré, code tiers patché, code de test, …
Ce travail doit être effectué à l’initialisation du processus, mais il se poursuit tout au long de l’évolution du projet et nécessite une expertise à transmettre au fur et à mesure de l’évolution de l’équipe. La facilité de mettre à jour ce paramétrage doit être un critère essentiel lors de la sélection des outils. Dans tous les cas, elle met en exergue le fait qu’un développement doit toujours être bien structuré pour pouvoir être analysé automatiquement.
Paramétrage des règles
L’étape la plus critique consiste à sélectionner les règles de qualité. Certains outils proposent plusieurs centaines de règles. La conservation de toutes ces règles est rarement viable car les développeurs seront vite noyés sous une avalanche de violations, il faut donc opérer une sélection. Or ce travail est complexe :
- il demande une vraie expertise sur la technologie utilisée.
- une règle dépend fortement de son implémentation. Que ce soit une mauvaise pratique, une métrique, un copier-coller, les manières de les implémenter sont très variables selon les outils. Il faut donc expérimenter l’outil avant de déterminer si certaines règles sont vraiment pertinentes dans le contexte de son projet.
- concernant les métriques, le choix des seuils est toujours délicat. Par exemple, que choisir comme seuil maximal pour la complexité cyclomatique d’une méthode en Java ? Et en C# ?
- ce travail de sélection sera probablement sujet à polémiques au sein de l’équipe : pratiques discutées, seuils considérés comme trop exigeants, … Il doit donc être pris en charge par quelqu’un qui maîtrise parfaitement le sujet.
- le cas d’un code existant est particulièrement difficile à traiter : comment assurer la qualité des développements sans déstabiliser un code qui a déjà passé des tests fonctionnels ? Cette problématique est traitée dans un autre billet.
Dans tous les cas, les règles retenues doivent être échelonnées suivant leur priorité ou leur sévérité pour faciliter leur traitement.
Sensibilisation et formation
Afin de corriger les problèmes remontés et être capables d’éviter de les reproduire, les développeurs doivent être formés aux règles de qualité retenues. Deux stratégies sont possibles :
- réaliser une revue des règles an amont du projet, au travers une présentation orale, voir un guide de recommandation exhaustif
- laisser les développeurs découvrir les règles de qualité en consultant les résultats d’analyse. Les développeurs doivent alors disposer d’un accès facile vers la documentation de chaque règle, avec de préférence des exemples et des liens. L’objectif réel n’étant pas la seule correction des problèmes, mais le développement de leur expertise pour qu’ils ne reproduisent plus ces problèmes pour aboutir ainsi à un vrai processus d’amélioration continu.
Dans la pratique, on constate que la première solution est peu efficace, les développeurs ne retenant que peu des règles exposées. L’expérience de nos clients montre que la deuxième solution semble être la plus efficace, combinée à une présentation générale en amont du projet pour exposer les quelques règles structurantes qui gagnent à être appliquées dès les premiers développements.
Plan de corrections
La détection des violations des règles de qualité est une première étape, mais l’objectif est bien de corriger ces violations. Cet aspect est délaissé par la plupart des outils, alors qu’il est fondamental pour que le suivi de la qualité soit efficace et que l’équipe puisse mesurer l’application des règles de qualité.
Par plan de corrections, on entend notamment une notion de lotissement des points à corriger : par priorité, par développeur, par type, … Pourquoi ne pas gérer ces corrections comme des tâches à réaliser comme le proposerait un outil de suivi de bug ? Ceci permet à la fois de mieux intégrer la charge de correction dans le planning et de suivre à posteriori les corrections effectuées.
Conclusion
La mise en oeuvre d’un processus de suivi de la qualité à l’aide d’outils OpenSource est une vraie alternative, mais comparez bien tous les éléments nécessaires pour aboutir à des résultats efficaces. Car au-delà de montrer que le projet dispose bien d’un tel processus, l’objectif est bien d’atteindre un retour sur investissement concret.
No related posts.
