Tags

, , , , , ,

L’utilisation d’un outil d’analyse de code tel que Checkstyle, PMD ou FindBugs permet d’assurer un certain niveau de qualité sur un projet : l’outil garantit un code homogène et permet aux développeurs débutants d’acquérir progressivement une partie des bonnes pratiques de la programmation en Java. Mais le caractère optionnel d’un tel outil met en péril son adoption sur certains projets.

En effet, comme ce genre d’outils n’est nullement indispensable à la progression des développements, il est facile d’oublier de les installer. Du coup leur utilisation tient souvent de la bonne résolution de début de projet et finit par être délaissée au fur et à mesure que celui-ci prend de l’ampleur. Alors que les développements s’intensifient, de nouveaux développeurs arrivent, l’équipe se renouvelle, et Checkstyle n’est bientôt plus qu’un lointain souvenir. C’est en fait le lot de la plupart des outils liés à l’amélioration de la qualité et cela contribue à alourdir la dette technique des projets concernés (plus de détails sur la notion de dette technique ici).

C’est pourquoi, à mon sens, la mise en place de tout process qualité dépend en grande partie de la capacité d’automatiser l’installation et la configuration des environnements de développement. En plus de garantir la pérennité des solutions choisies, l’utilisation d’un système de “provisioning” d’IDE apporte une sécurité et un gain de temps conséquent dans la vie d’un projet.

Une fois automatisées l’installation et la configuration des environnements de développement, il devient réellement envisageable de mettre en place cet outillage. Mais attention, Checkstyle, pour rester sur cet exemple, apporte également des contraintes qui peuvent décourager l’équipe projet si elles ne sont pas maîtrisées. Cela fera l’objet de mon prochain post.

Advertisements