J’évoquais dans mon post précédent l’utilité d’automatiser l’installation et la configuration des environnements de développement pour éviter que les outils visant au maintien de la qualité ne sombrent dans l’oubli à l’occasion d’une péripétie quelconque du projet, un renouvellement de l’équipe par exemple. Je prenais l’exemple de Checkstyle pour illustrer mon discours. Mais avec Checkstyle, une fois réglée la question de l’installation, on est vite confronté à un autre problème : son côté intrusif, à commencer par le grand nombre d’erreurs détectées d’emblée. “Ça va prendre du temps pour tout corriger.” “C’est quoi la complexité cyclomatique ?” “Il faut écrire la JavaDoc de toutes les méthodes ?” “Pas très pratique, lorsqu’on est en train de coder, de faire le tri entre les erreurs de style et les erreurs de compilation.” Autant de contraintes et de questions qui peuvent, petit à petit, décourager une équipe de développement. Il peut aussi arriver d’avoir à faire face à des remarques déroutantes du genre : “Pas grave, c’est juste un warning !”.
Pour éviter d’être pris au dépourvu, limiter les désagréments et faire en sorte …
