De passage hier chez nos amis de Zenika, Cédric Vidal et moi-même avons eu le plaisir de faire la connaissance de Eric Evans, la référence mondiale du Domain Driven Design. A noter que Eric Evans fera une conférence sur ce sujet ce mercredi soir, 17 février, chez Zenika à Paris.

C’est surtout pour une rencontre tripartite ProxiAD / Zenika / Eclipse Foundation planifiée avec Ralph Mueller, Directeur Ecosystème pour l’Europe au sein de la Fondation Eclipse, que Cédric et moi avons fait le court trajet à pied de ProxiAD Ile de France à Zenika. Côté Zenika, Laurent Delvaux, cofondateur, Pierre Queinnec, cofondateur et directeur technique et Ophélie Rudent, responsable marketing, ont été nos hôtes pour cette réunion tout à fait passionnante, lors de laquelle nous avons notamment évoqué la stratégie de la Fondation Eclipse vis-à-vis du marché.

D’autres sujets brulants étaient à l’ordre du jour, mais il serait prématuré de les aborder aujourd’hui. Restez à l’écoute : nous devrions avoir d’ici quelques semaines de super nouvelles pour vous.

En attendant voici la traditionnelle photo souvenir avec …

Il y a de cela un peu plus d’un an, lorsque je cherchais un moyen de construire un plugin Eclipse avec Maven, je tombais presque par hasard sur une réponse laconique de Jason Van Zyl (le papa de maven): “Tycho”.
Mais, me diriez-vous : On ne pouvait pas contruire de plugin Eclipse avec Maven avant ???

Eh bien, en pratique, on pouvait parvenir à compiler des sources, à générer des fichiers manifest.mf voire à construire des “product” mais à quel prix ! A titre d’illustration, je vous invite à lire l’excellent article de Cyril Lakech et vous aurez une mince idée de la sueur et des larmes qu’il fallait accepter de verser pour mettre en place Maven sur des plugins avant d’apercevoir le graal.

Une autre alternative consistait à développer et maintenir ses propres “Mojo”; Grégory Levilain a ces dernières années ainsi développé et déployé sur de nombreux projets un ensemble de plugins Maven permettant d’adopter une optique “POM-FIRST”. Cette approche laisse à Maven le soin de gérer les versions des éléments du projet (plugins, fragments, features, update-sites, products), et de leurs dépendances. Ces travaux ont été initiés en 2006 lors de la mise en open-source du projet Wazaabi.

Mais alors …

La fin de semaine dernière a été chargée, j’ai enfin pu prendre un peu de temps pour faire un compte-rendu de l’Eclipse DemoCamp que nous avons organisé Mardi dernier avec Obeo et la fondation Eclipse dans le grand amphithéâtre de l’Epitech. L’évènement as eu pas mal de succès, bon d’accord, il y avait pas mal d’étudiants mais quand même 150 personnes, ça fait plaisir !

Dans la première partie de cet article, j’ai formulé des recommandations visant à éviter certains pièges lors du choix et de la configuration des règles Checkstyle. Cela notamment afin d’éviter de décourager les  développeurs avec des règles irréalistes ou hors contexte.

Reste à nous occuper des règles particulièrement pénibles à corriger, très laborieuses, telles que les espaces superflus, l’organisation des “imports” par ordre alphabétique, ou des variables selon leur visibilité.
Ce serait une perte de temps énorme que d’avoir à se soucier de tous ces problèmes syntaxiques. Heureusement la plupart des IDE actuels fournissent des outils qui, moyennant une configuration appropriée, peuvent réaliser automatiquement tous ces traitements. Je prendrai ici le cas d’Eclipse.

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

Les “Save Actions” d’Eclipse permettent de systématiser le formatage du code ainsi que l’organisation des imports et des déclarations au moment de la sauvegarde des fichiers source. Cette option peut être utilisée de façon à résoudre toutes les règles de formatage de Checkstyle sans qu’aucune action spécifique ne soit nécessaire.

Cela nécessite de coordonner les règles Checkstyle avec les outils suivants :

• l’outil de formatage automatique du code (Window > Preferences …

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 …

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é …