Devoxx France 2013 – Implémenter la qualité sur un projet Java

A l'occasion de Devoxx France 2013, j'ai assisté à la conférence intitulée « Implémenter la qualité sur un projet Java » présentée par Vincent Massol (profil github), contributeur du projet XWiki.

Vincent nous parle des bonnes pratiques dans la gestion d'un projet Java, en prenant comme modèle son expérience sur XWiki.

Stabilité de l'API

Il faut faire attention aux utilisateurs et même aux développeurs du framework.

Clirr est un outil qui casse la construction d'un projet s'il y a un changement dans une API. La comparaison peut se faire au niveau binaire ou au niveau du code source. Lorsque l'on a intentionnellement changé l'API, il faut documenter le changement pour qu'il soit ignoré par l'outil, qui signalera cela dans son rapport.

Voici quelques pratiques mise en place sur le projet XWiki pour la gestion de ses API :

  • Création d'un package 'internal' : Les classes/méthodes/attributs présents dans ce paquetage peuvent être visibles au sens Java mais le développeur ne doit pas les utiliser. S'il le fait quand même, il prend le risque que son code ne compile plus ou ne s'execute plus lors d'une nouvelle version de la librairie. Il ne faut pas oublier d'exclure ce paquetage de la javadoc et de l'analyse Clirr.
  • Gestion de la dépréciation dans l'API
    • Version courante : Utiliser l'annotation @Deprecated dans le code et le tag @deprecated dans la javadoc (voir aussi la documentation Oracle sur le sujet).
    • Future version : Déplacer le code déprécié vers des artefacts dont le nom se termine par "-legacy". Les classes dépréciées sont déplacées. Les méthodes dépréciées sont déplacées en utilisant AspectJ.
  • Gestion des nouvelles API : Celles-ci sont potentiellement instables. Il faut utiliser l'annotation @Unstable et préciser une limite de validité.

Attention à l'ajout de méthodes dans une interface ! Mais cela ne sera plus un problème à partir du jdk8, qui permet d'ajouter une implémentation par défaut sur une interface.

L'enfer des jars

Il arrive parfois que certaines classes soient dupliquées à l'exécution (même classes dans 2 jars présents dans le classpath). Lorsque les classes sont différentes, cela constitue un véritable problème qui peut être résolu en utilisant les plugins maven suivants :

  • duplicate-finder pour détecter les classes dupliquées.
  • enforcer pour forcer l'application de certaines règles (version du jdk, version des artefacts ...).

Tests de couverture

La librairie JaCoCo mesure la couverture des tests et, si la valeur est en dessous d'un certain seuil, la construction du projet échoue.

Attention : Certains tests peuvent être non déterministes et le taux de couverture peut varier d'une exécution à l'autre, sans modification du code. C'est notamment le cas lorsqu'on utilise la classe ConcurrentHashMap avec plusieurs threads. Vincent propose de rajouter un paramètre nommé threshold (voir la discussion sur le projet github de JaCoCo) pour définir une marge de tolérance par rapport au seuil.

Faux positif/négatif

Un faux positif correspond à un test qui passe alors qu'il aurait dû échouer. A l'opposé, un faux négatif correspond à un test qui ne passe pas alors qu'il aurait dû passer. Exemple de faux négatif : crash, lenteur du système. Voici quelques plugins Jenkins qui peuvent servir dans ces situations :

  • Groovy Postbuild : Ce plugin permet de contrôler le résultat d'un build et éventuellement rajouter un badge sur le sommaire du build et/ou l'historique des builds. Dans notre cas, il peut rechercher du texte dans les logs afin de vérifier qu'un test passe réellement.
  • Email-ext : Ce plugin permet d'étendre la fonctionnalité de notification par email. On pourrait, par exemple, annuler l'envoi d'email lorsque le système est lent (mais l'interface web de jenkins continuerait de montrer le problème).
  • Scriptler : Ce plugin permet de centraliser les scripts Groovy d'une instance Jenkins. On peut aussi jouer un script sur tous les jobs jenkins ou sur tous les noeuds/esclaves. Remarque : le plugin gère 2 sites de partage de scripts : jenkins-scripts ou scriptlerweb.

Bug tracking

Avec le temps, les courbes de bugs ouverts et bugs corrigés tendent à diverger. Pour atténuer cette divergence, le jeudi a été déclaré jour de correction des bugs par les contributeurs du projet XWiki. Afin de diminuer rapidement les bugs ouverts, ceux-ci commencent par fermer les bugs corrigés et les bugs en doublon. Ensuite, ils corrigent les bugs faciles et requalifient certains bugs en évolution. Pour voir le résultat, consulter le tableau de bord du projet XWiki.

Pour terminer, Vincent souligne qu'il faut paramétrer les outils afin qu'ils fassent échouer un build lorsqu'une mesure est mauvaise. Sans cela (paramétrage pour émettre un simple avertissement), on va avoir tendance à ignorer le message, puis laisser le problème empirer et finalement ne jamais le corriger.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.