J’ai participé à TDD/ATTD et à la session sur les commentaires dans le code.

TDD – ATTD

Le Test Driven Development est une méthode de programmation basée sur les règles suivantes :

• on écrit un test
• on vérifie qu’il échoue
• on écrit juste ce qu’il faut pour que le test passe (et rien d’autre!)
• on vérifie qu’il passe
• on refactorise encore et encore

L’Acceptance Test Driven Development (ATDD) est basée sur l’idée de faire des tests d’acceptance (automatisés) avant même de commencer les développements. La bonne mise en pratique se fait en deux temps : le client, les utilisateurs, la MOA écrit les test pendant que les développeurs se chargent de les automatiser. Plusieurs outils existent pour cela comme par exemple Greenpepper, Fit/Fitnesse, Robot Framework … La plupart se base sur des wiki pour permettre aux personnes fonctionnelles d’écrire facilement leurs tests.

Dans une approche basée sur l’ATDD, les spécifications et les implémentations sont dirigées par des exemples concrets. Décrire précisément des cas de tests oblige celui qui spécifie à aller plus loin que les spécifications habituelles. Cette méthode a également l’avantage d’être plus claire pour le développeur.

Le TDD

Peu de personnes font du TDD pur et dur, la plupart de la dizaine de personnes présentes écrivent un bout de code avant de tester.  Néanmoins,  la personne ayant le plus d’expérience est un adepte du TDD pur et dur depuis de nombreuses années. Les frameworks de mocks permettent de simplifier sensiblement la tâche du développeur. Néanmoins, le TDD est loin d’être une évidence pour tout le monde. Le risque de perdre de vue l’architecture générale du projet, la difficulté de la sensibilisation d’une équipe aux tests, les problèmes de maintenabilité et de refactoring sont quelques uns des exemples soulevés pour montrer les difficultés engendrés par l’application de cette méthode.

L’ATDD

Au niveau des tests d’acceptance, seul une seule personne les utilise dans un contexte d’entreprise.
Le gros problème soulevé par les tests d’acceptance c’est la difficulté, lors d’utilisation d’outils type fit/fitness greenpepper est la refactorisation des tests : les tests écrits sont difficilement maintenable dans le temps. L’ATDD permet au développeur d’avoir des spécifications claires et précises, permettant entre autre de réduire les difficultés de communication entre la maitrîse d’oeuvre et d’ouvrage. Un autre point bloquant est que l’ATDD demande à l’équipe fonctionnelle de s’impliquer et de se former à un nouvel outil, ce qui n’est pas simple dans certains contextes.

Digressions diverses

Un autre aspect négatif est le temps pris par les tests, qu’ils soient d’intégration, d’acceptance …  Ils ont tendance à grossir encore et encore, à devenir de moins en moins maintenables jusqu’à devenir contre productif. Plutôt qu’un enchaînement d’action, difficile maintenable dans le temps, il faut se focaliser sur les work flows et sur les règles business. Il faut également essayer de limiter quand cela est possible l’utilisation de l’IHM dans les tests d’acceptance.

Les commentaires dans le code

Olivier Croisier a pour projet de synthétiser les bonnes pratiques de commentaires. Plusieurs points ont été abordés dans cet atelier.
Au niveau des APIs publics, la javadoc est coûteuse à maintenir mais obligatoire, et en anglais. Lorsqu’il y a du code, il est souvent obsolète donc à utiliser avec précaution.
Au niveau du code non public, les personnes présentes utilisent beaucoup moins la javadoc. On remarque souvent qu’il n’y en a pas, qu’elle est obsolète ou inintéressante. Un point pour commenter facilement le code est l’encapsulation du code dans des méthodes private qui, via leurs noms, sont auto-documentées. On peut donc alors comprendre facilement une méthode principale en lisant la succession de méthodes appelées. A noter qu’il ne suffit pas de découper son code n’importe comment, il est important de ne pas avoir une profondeur d’appels de méthodes de ce type trop importantes (A qui appelle B qui appelle C qui appelle D qui appelle E). Un moyen de découper convenablement le code est d’éviter d’appeler dans la méthode principale des méthodes fonctionnelles et des méthodes techniques. Le code est plus lisible si on découpe du fonctionnel vers le technique.
J’ai utilisé cette méthode pour découper des classes de plusieurs centaines de lignes avec un fonctionnel un peu compliqué et je trouve que le code est beaucoup plus clair, en cas d’évolution ou de recherche d’un bug, on sait directement où aller. Le problème de cette méthode est que parfois, on ne voit pas certains refactoring qui pourrait faire gagner en lisibilité (là encore, il est possible de perdre de vue la ‘big picture’). C’est pour cette raison que certains estiment qu’une méthode n’a d’utilité que lorsqu’elle est réutilisée et que les méthodes de plusieurs dizaines de lignes sont en fait plus claires. Sur ce sujet, lire Clean Code et Effective Java est essentiel.

Un autre point est l’utilisation des commentaires du style /**** GETTERS AND SETTERS *****/ /***** CONSTRUCTORS *****/ . La encore, cette méthode ne fait pas l’unanimité (et je suis loin d’en être la première fan).

Au niveau de l’utilisation français/anglais, c’est assez mitigé. La plupart écrivent leurs noms de variables et de commentaires en anglais, d’autres se permettent quelques écarts en français et pour quelques un le français est la norme.

Au niveau des tâches (//FIXME //XXX //TODO), la plupart des personnes présentes sont d’accord avec le fait que cela n’est utile que si la tâche nous concerne.

En ce qui concerne les warnings sur les classes, l’idée est d’en avoir aucun : l’utilisation des outils comme PMD, FindBugs, CheckStyle est à bien configurer avant utilisation, car la multiplication des warnings noie les vrais warnings dans de la pollution.

Je retiens également que Implementation Patterns de Kent Beck sera une de mes lectures estivales et que l’outil mvn eclipse:eclipse permet de faire bien plus de choses que prévues !

J’ai passé un agréable moment, j’y étais venue surtout par curiosité et je compte bien retourner à la prochaine ! Ça a duré jusqu’à un peu plus de 23 heures pour moi, ce qui fait quand même une bonne soirée. Énormément de digressions, ça part dans tous les sens mais c’est souvent là que c’est le plus intéressant !

Sur twitter : http://twitter.com/KawaCampParis

MAJ :  la date de l’évènement Clojure a été avancée au 8 février !

Ajout événement noSQL 16 février

Ajout évènement EulerGUI 13 février

Le KawaCampParis1 – 3 février – Décalé en mars

Les BarCamp sont des rencontres, non formelles sous forme d’ateliers-événements participatifs ou simplement de discussions libres autour d’un thème. Chacun arrive avec son propre contenu.  Comme lors des JavaCamps les participants finissaient la plupart du temps par parler d’autres choses que Java, l’idée d’un KawaCamp, plus large, a germé Les sujets seront donc nombreux, de NoSQL à Groovy en passant par les technos Google, sans oublier  HTML5, les frameworks Javascript etc ..

Site web : http://barcamp.org/KawaCampParis1
Wave publique : with:public KawaCampParis1

Clojure : Vers l’essence de la programmation – 8 février

Clojure est un langage fonctionnel apparu en 2007 de type Lisp et tournant sur la JVM. Howard Lewis Ship , créateur de Tapestry, présentera le langage, ses atouts ainsi que les concepts fondamentaux de la programmation fonctionnelle.

Site web : http://www.zenika.com/conference/web_ria/clojure-essence-de-programmation-par-howard-lewis-ship

2ème Anniversaire du Paris Jug – 9 février

Le Paris JUG fête ses deux ans en grand ! Un amphi de 500 places nous accueillera entre 18h45 et 19h (donc 30 minutes plus tôt que d’habitude) sur le sujet de l’open-source en France. Au moins 6 présentations sur des thèmes variés :

• Keynote de Sacha Labourey
• Obeo : exemple d’un éditeur d’outils de développements Open Source ayant réussi à se développer
• Les licences permettant la diffusion libre de la documentation
• Le framework Play!
• jCaptcha
• jax-doclet , permettant de génèrer de la JavaDoc à partir des des commentaires JavaDoc et des annotations de manières spécifiques (notamment pour JAX-RS et JAXB)

Et toujours suivi d’une 3ème mi-temps pour des discussions plus informelles mais tout aussi intéressantes !

Comme au mois de Décembre, la salle est à la faculté de la Sorbonne : http://www.parisjug.org/xwiki/bin/view/Location/SorbonneParisIV

Site web : http://www.parisjug.org/xwiki/bin/view/Meeting/20100209

Les secrets de la concurrence Java – 11 février

Heinz Kabuts est un des premiers Java Champion. Il publie régulièrement une newsletter très pointue sur Java et la JVM sur http://www.javaspecialists.eu/ suivie par approximativement 30 000 développeurs Java. Il abordera au cours de cette soirée 10 lois pour nous apprendre à mieux gérer le multi-threading.

Site web : http://www.zenika.com/conference/java/secret-de-la-concurrence-java-par-heinz-kabutz

EulerGUI – 13 février

EulerGUI est une interface graphique pour le Web Sémantique, et les moteurs de règles, Open Source, en Java. ( http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/html/documentation.html )

Site web : http://jmvanel.free.fr/seminaires/seminaires_gratuits.html#L436

Domain Driven Design : Les modèles en action – 17 février

Eric Evans est de retour à Paris. Auteur de Domain-Driven Design, il  présentera les différents modèles (comment les choisir, les faire cohabiter …). Cette conférence s’adresse plutôt aux développeurs expérimentés.

Site web : http://www.zenika.com/conference/architecture/domain-driven-design-par-Eric-Evans

Deuxième rencontre noSQL – 16 février

Les sujets de cette deuxième conférence sont « noSQL for Fun and Profit » et Redis.

Site web :  http://sites.google.com/a/octo.com/nosql/project-updates/usergroupparis-round2

Création du Spring User Group – 25 février

La première conférence du Spring User Group balayera les différentes nouveautés de la version 3.0 de Spring par Arnaud Cogoluègnes. La migration vers Spring 3.0, les nouveautés (Spring Expression Language, Support Rest) ainsi que le rapport avec Java EE seront abordés.

Site web :  http://groups.google.fr/group/sugfr/web/evnements

Src image :  Iulian Nistea