Les templates d'Eclipse pour unifier l'équipe

Comment faire lorsque vous devez imposer de nouvelles contraintes de développement à votre équipe mais qu'elles peuvent être perçues comme une perte de temps au premier abord ou qu'elles peuvent être implémentées différemment suivant les habitudes de chacun ?

Je prends deux exemples rapides :

1. Dans le cadre des projets Java dont j'ai la charge chez mon client, notre système de logging, basé sur log4j, n'a pas été mis en place pleinement dès le début des développements. Résultat : les traces dont nous disposions il y a encore quelques semaines étaient parfois trop justes pour nous permettre de gérer correctement le suivi d'un appel, directement sur nos serveurs. Nous avons donc demandé à nos développeurs d'ajouter des logs un peu partout dans le code, avec certaines règles précises (on signale le début de la méthode, on loggue les paramètres envoyés à un web service...). Pour ces développeurs, n'assurant pas la maintenance des projets, l'ajout de logs est une véritable gageure qu'ils réduisent au minimum.
2. Lors de la vérification des paramètres à l'entrée d'une méthode, nous demandons à nos développeurs de vérifier que les String ne soient ni nulles ni vides (uniquement des espaces ou aucun caractère). C'est une règle qui s'applique à la très grande majorité de nos méthodes, et qui demande systématiquement les mêmes vérifications, qui peuvent être faites de manières différentes suivant les habitudes de chacun.

Nous voyons bien ici les problèmes qui peuvent se poser : dans un premier temps, les développeurs vont éluder la question en en faisant le moins possible (ce qui peut se comprendre sur certaines tâches fastidieuses et peu valorisantes). Dans un second temps, les habitudes de chacun risquent de conduire à des comportements métier différents, difficilement repérables.

L'une des solutions consiste à contrôler le code produit par les développeurs. Il existe pour cela des solutions que nous aborderons dans un autre billet. Le contrôle implique cependant que vous mettiez en place des métriques, que vous passiez du temps à les analyser, que vous demandiez les rectifications et que les développeurs appliquent vos corrections. Et chaque fois, il faut recommencer...

La deuxième solution consiste à expliquer l'intérêt de ces contraintes, afin qu'elles soient comprises et mieux acceptées. Si vous travaillez avec des gens ayant un minimum de conscience professionnelle et que vous avez un sens pédagogique dépassant celui du babouin nain, vous devriez avoir un minimum de résultats.

Une autre solution consiste à fournir à vos développeurs le moyen d'en faire le moins possible, et le plus facilement possible. Nous sommes tous humains : moins l'on en fait, mieux l'on se porte. Et c'est là que les templates d'Eclipse viennent à notre secours...

Pour les présenter rapidement, les templates d'Eclipse, accessibles via l'assistant contextuel, permettent de générer du code (de quelques mots à plusieurs dizaines de lignes), tout en permettant au développeur de remplir rapidement les vides, configurés par vos soins.

Exemple : vous devez logguer le début d'une méthode avec le code suivant :

if(LOGGER.isDebugEnabled()) {
LOGGER.debug("Starting method...");
}

Il vous suffit pour cela de déclarer un template, nommé lstart, qui génère automatiquement le code précédent. Vous souhaitez saisir le message ? Pas de problème vous définissez le template ldebug, qui aura la tête suivante :

if(LOGGER.isDebugEnabled()) {
LOGGER.debug("${message}");
}${cursor}

Lorsque le développeur appliquera ce template, son curseur se placera automatiquement au niveau du message, ce qui lui permettra de le saisir. En tapant ensuite sur "entrée", son curseur se déplacera après les accolades, lui permettant de poursuivre son code sans toucher à sa souris.

Je vous laisse regarder un peu toutes les possibilités des templates d'Eclipse :

1. Import automatique des classes pré-configurées,
2. Saisie unique du nom de variable et remplacement automatique de toutes les occurences de cette variable dans le template,
3. ...

Vous voyez bien là l'intérêt des templates : en saisissant simplement un nom, vous générez un code précis, répondant aux règles définies à l'avance, sans que les développeurs aient à y réfléchir. En tant que référent technique de votre équipe, il vous suffit ainsi de créer les templates que vous jugez utiles (Windows/Preferences/Java/Editor/Templates) et de les exporter dans un fichier XML. Vos développeurs pourront ensuite les importer facilement dans leur propre environnement pour les réutiliser rapidement et facilement.

Pour que l'utilisation des templates soit réellement efficace, il faut cependant que les noms de ceux-ci soient logiques (pour que l'on puisse s'en souvenir facilement) et courts (pour inciter les développeurs à les utiliser).

Attention également à ne pas créer des templates pour tout et n'importe quoi. Les templates doivent être simples et d'utilisation évidente. Il ne faut pas qu'il y en ait une multitude.

Quelques liens rapides sur le sujet:

http://eclipse.developpez.com/faq/?page=developpement#creerTemplates

http://www.programmez.com/tutoriels.php?titre=Eclipse-et-les-templates-Java-par-l-exemple&tutoriel=82