Tags

,

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 que Checkstyle soit reconnu sur le projet comme vraiment “utile”, mieux vaut préparer le terrain à l’avance.
Pour cela nous pouvons jouer sur deux fronts :

  • les règles checkstyle ;
  • les possibilités offertes par notre IDE. J’aborderais ce point dans la seconde partie de cet article, avec le cas d’Eclipse.


Définir judicieusement les règles Checkstyle

Faut-il définir les règles Checkstyle comme des erreurs ou des warnings ?
Checkstyle permet de fixer le degré de criticité de chaque règle utilisée. Les options possibles sont : “ignore”, “info”, “warning”, “error”. Étant donné le grand nombre de problèmes signalés, et afin d’éviter de trop perturber les développements, on pourrait être tenté de définir les problèmes Checkstyle en tant que warnings. C’est à mon sens une erreur pour deux raisons. D’abord parce que les warnings sont facilement ignorés du fait des habitudes acquises avec les problèmes de compilation. Et parce que la mise en place de Checkstyle sur un projet en perturbe nécessairement les développements : il faudra bien corriger les problèmes un jour ou l’autre. Il est préférable d’organiser des actions de correction spécifiques plutôt que d’espérer voir les problèmes se volatiliser petit à petit. Ces “actions qualité” ont plusieurs avantages. Elles impliquent et sensibilisent tous les développeurs en officialisant l’utilisation de checkstyle, et ouvrent le dialogue sur le sujet. Ainsi, personne ne se sent lésé (“Cet outil nous donne du travail en plus !”). En fait, erreurs et warnings sont complémentaires, et de même que les deux notions sont utiles pour la phase de compilation, elles le sont aussi pour signaler les problèmes syntaxiques. Les erreurs désignent les problèmes inacceptables alors que les warnings servent à déconseiller certaines pratiques. Comme Checkstyle offre la possibilité de modifier à volonté la criticité de ses règles, il est possible d’utiliser des warnings pour les cas qui feront l’objet d’une future “action qualité”. A cette occasion, ces warnings seront convertis en erreurs.

Un précepte fondamental avec Checktyle : les erreurs doivent être corrigibles !
Il faut bannir les règles hors contexte ou irréalistes et alléger les règles trop contraignantes. Cela paraît logique a priori et pourtant l’exercice remet parfois en cause des concepts que l’on pensait établis.

Prenons l’exemple de la complexité cyclomatique : valeur obtenue en calculant le nombre de “chemins” possibles dans une méthode, dépendant du nombre de “if”, “while”, “for” et autres ramifications qu’elle contient.
La documentation de Checkstyle considère une complexité cyclomatique supérieure à 10 comme excessive. L’outil fait donc de cette limite sa valeur par défaut. Dans ces conditions, que faire si mon projet présente à un moment donné trois cents méthodes dont la complexité cyclomatique est supérieure à 10, sachant qu’un “refactoring” peut s’avérer long et risqué ? Réponse : estimer notre capacité à corriger. S’il est possible, étant donné les contraintes du projet, de mener une “action qualité” dédiée… parfait. Sinon, aussi sage et avisée qu’ait été la méthode employée pour calculer cette limite de 10, il faut envisager de l’augmenter car s’il est impossible de corriger les erreurs associées, cette valeur nous est inutile. Par contre, en la fixant à 15 ou à 20, nous mettrons en évidence les méthodes les plus critiques, sur lesquelles un refactoring aura une grande plus-value pour un temps de travail acceptable. Je profite de l’occasion pour ouvrir une parenthèse et rappeler l’utilité du pattern de refactoring « Extract Method » qui adresse directement le problème de la complexité cyclomatique (voir aussi le catalogue des patterns de refactoring ici) . En effet, ce pattern consiste à extraire d’une méthode les fragments de code qui peuvent être isolés. L’excellent article “In pursuit of code quality: Refactoring with code metrics” développe cette problématique en détails. Pour sa part, Eclipse supporte parfaitement ce pattern en générant, à partir d’un fragment de code sélectionné, une nouvelle méthode possédant les paramètres adéquats (menu “Refactor > Extract Method…”).

On peut appliquer la même démarche que pour la complexité cyclomatique à la question, non moins délicate, de la JavaDoc. Encore une fois, il ne s’agit pas d’énoncer de grandes théories au sujet de la rédaction de la JavaDoc, mais bien de savoir ce qui est défini dans le périmètre du projet. On ajustera les règles Checkstyle de façon à ce qu’elles reflètent ce périmètre. Cela permettra de déduire, en fonction des comptes rendus Checkstyle, des “actions qualité” réalistes. Et cela évitera aux développeurs d’être gênés par des erreurs “hors sujet”.

Bien configurer l’IDE pour éluder les contraintes de Checkstyle

Dans le second volet de cet article, je proposerai une série d’astuces dédiées à Eclipse, visant à inhiber les aspects les plus contraignants de Checkstyle. En combinant cette configuration avec les recommandations citées ci-dessus, on obtient un confort de développement maximum, permettant d’exploiter pleinement le potentiel de Checkstyle.

Advertisements