Compte rendu de l'XP Day Suisse (Genève) 2009

Cette séance constitue une très bonne présentation d'XP. Destinée principalement aux développeurs n'ayant pas ou peu d'expérience d'XP, cette séance fut accessible, claire et très bien illustrée par de nombreux points et des métaphores.

En tout début de séance, l'intervenant Didier Besset nous explique que le but d'XP est de maîtriser les coûts, en particulier les coûts liés aux changements. En effet, plus des changements doivent survenir tard dans le développement, plus ces changements coûtent cher ; la courbe du coût étant exponentielle :

Pour maîtriser les coûts liés aux changements, XP propose :

• le développement itératif ;
• une planification adaptable et non rigide ;
• une architecture évolutive et non contraignante ;
• la multiplication des tests.

Puis il nous explique certains fondamentaux d'XP.

XP c'est :

• faire preuve de bon sens ;
• faire les choses simplement ;
• privilégier la communication ;
• intéragir de près avec le client ;
• faire tout cela à 100 %.

Un principe fondamental, c'est de respecter la place du client et des développeurs ainsi que les connaissances de chacun. Ainsi on suppose que :

• le client connaît son métier ;
• les développeurs connaissent leurs outils ;
• le client définit les priorités ;
• les développeurs définissent les détails.

Ainsi le client doit / les développeurs ne doivent pas / le client a le dernier mot pour :

• décider du workflow ;
• définir les champs, menus, boutons ;
• choisir une charte graphique.

Les développeurs doivent / le client ne doit pas / les développeurs ont le dernier mot pour :

• décider d'une architecture ;
• choisir les outils (langage, BDD) ;
• définir le modèle.

Le client définit les priorités. Si une date de livraison semble en danger, risquant d'être dépassée, les développeurs doivent signaler le problème au client qui décidera des fonctionnalités à retirer afin de conserver la date de livraison.

Après une bonne livraison, c'est le client qui décide de la mise en service.

Après ces explications sur le rôle de XP, la place du client et des développeurs, Didier Besset explique en détail quelques grands principes de XP:

Test Driven Design

Les tests unitaires sont écrits par les développeurs. Il faut écrire les tests unitaires avant de coder. Il faut tester tout ce qui peut « foirer » ainsi que le comportement aux valeurs limites.

Les tests d'acceptation sont écrits par le client. Ils permettent de vérifier le respect du cahier des charges (et de savoir quoi tester). Ils sont un bon départ pour la documentation.

Intégration Continue

Chaque changement est immédiatement inclus dans un système déployé. Le déploiement fait partie du développement.

Un système utilisable existe en permanence :

• les développeurs peuvent essayer le système ;
• le client aussi.

Livraison fréquente

• elle est la conséquence directe de l'intégration continue ;
• le client a le système en main le plus tôt possible ;
• le client peut réagir ;
• le choc des nouvelles fonctionnalités est atténué.

Simplicité

Écrire du code lisible :

• les autres doivent pouvoir le lire ;
• vous aussi, après plusieurs mois.

Les intentions doivent être claires :

• utiliser des standards ;
• éviter les abréviations ;
• éviter les commentaires.

Le dernier point (éviter les commentaires) peut paraître bizarre, mais pour l'intervenant, le code doit se suffire à lui-même. S'il y a des commentaires, c'est que le code n'est pas lisible. J'aurais tendance à dire que les commentaires doivent exprimer ce que le code ne dit pas (fonctionnement général, invariant, propriétés de certaines variables…), mais Didier Besset n'est pas d'accord sur ce point.

En conclusion, Didier Besset commente cette citation de Peter Merel: « Make it run, make it run well, make it run fast. In that order. »:

• « Make it run » : passer les tests ;
• « Make it run well » : refactoriser, rendre le code lisible ;
• « Make it run fast » : optimiser.

Et surtout : ne rien dupliquer !

La séance est présentée par Portia Tung et Pascal Van Cauvenberghe.

Le duo fonctionne bien et présente sous forme ludique les petits outils/jeux permettant de qualifier/améliorer son agilité. L'objectif de la présentation va au-delà des 5 premiers pas pour devenir agile et explore plutôt comment amener une équipe à détecter des problèmes via l'utilisation de jeux.

La partie la plus intéressante vient d'un jeu illustrant la théorie des contraintes. Ce jeu montre comment une personne surchargée peut bloquer très vite une équipe.

Bien sûr, ce jeu est construit pour mettre en évidence ce qu'il veut montrer. L'équipe doit colorier un ensemble de dessins, un des membres se retrouve avec trop de travail pendant que le reste de l'équipe regarde. L'effet 'physique' est saisissant.

Comme tous les jeux très simples, il construit une situation caricaturale. L'important est donc le discours qu'il y a autour. Évidemment tout le monde se doute bien que si une personne se charge de tout, d'autres attendent. Ce qui est plus subtil c'est de se dire que si une personne est surchargée et stressée dans l'équipe, la soulager permet non seulement de lui faciliter la vie, mais a de bonnes chances d'améliorer le processus global.

Une personne de l'assistance demande si le concept ne doit pas être poussé jusqu'au bout en 'laissant partir' un leader technique qui prend trop de place dans l'équipe et laisser l'équipe se réorganiser d'elle-même. La conclusion de l'assistance est partagée entre le concept d'équipe homogène et d'équipe 'moyenne'.

Lors d'une pause, j'ai l'occasion de discuter plus en avant avec Pascal. Il m'explique comment il utilise ces jeux pour faire prendre conscience aux équipes des points d'amélioration possibles. Ainsi un des points clefs de son travail de consultant consiste à faire se rencontrer tous les intervenants d'un processus. La tentation pour chaque équipe étant d'optimiser sa partie et non la chaîne globale. Les jeux prennent alors beaucoup d'intérêt pour aller au-delà des frottements inévitables entre services.

Erlang est un langage de programmation conçu à l'origine par Ericsson avant d'être rendu public. Erlang est à la fois un langage de programmation fonctionnelle et un langage de programmation concurrente.

Cette session, présentée par Dominic Williams et Nicolas Charpentier, a permis de montrer l'application de la TDD à chacun de ces paradigmes de programmation.

Dominic Williams a d'abord montré en quoi la programmation fonctionnelle diffère beaucoup de la programmation procédurale ou orientée-objet, y compris en ce qui concerne les tests. En programmation orientée-objet, par exemple, avant de pouvoir tester il est nécessaire d'initialiser les objets et d'effectuer une série d'opérations afin d'amener les objets dans l'état que l'on cherche à tester. En programmation fonctionnelle, l'écriture des tests est souvent plus simple, plus lisible (une qualité primordiale en TDD) et semble finalement plus naturelle.

Pour illustrer cela, Dominic Williams a comparé des tests unitaires portant sur des listes : d'abord dans un langage orienté-objet, puis en Erlang. Les tests unitaires en Erlang se sont montrés plus concis (une ligne) et plus lisibles, car l'initialisation des listes était beaucoup plus simple.

Les démonstrations des tests en Erlang ont été faites en direct, sous Emacs, à la mode « ping-pong » (Dominic écrit les tests, Nicolas modifie le programme en conséquence) :

En haut à gauche : les tests.
En haut à droite : le programme à tester.
En bas : le résultat de la compilation/test.

Une autre démonstration intéressante a permis de montrer comment tester des fonctions d'ordre supérieur.

En programmation fonctionnelle, l'abstraction s'obtient par l'utilisation de fonctions d'ordre supérieur (c'est-à-dire des fonctions acceptant d'autres fonctions comme paramètre). En Programmation orientée-objet, l'abstraction se fait par héritage, ce qui pose certains problèmes : un même comportement doit être testé dans les sous-classes, parfois il est même nécessaire de définir des sous-classes dans le seul but de tester le comportement de la super-classe.

Toutes ces démonstrations ont permis de montrer que l'écriture de tests unitaires était simple de par la concision et l'expressivité du langage. Mieux encore : l'approche TDD permet de bien coder en programmation fonctionnelle. Par exemple, la TDD permet de tout de suite tester (et donc d'implémenter) les cas d'arrêt d'une fonction récursive, ce qui tend à réduire le risque de récursion infinie.

Le deuxième point important de cette présentation concernait la TDD en programmation concurrente et l'intérêt d'Erlang dans ce domaine.

De plus en plus d'applications introduisent des problématiques liées à la concurrence : threads, parallélisation, applications distribuées, ressources partagées…). Il est possible de faire de la programmation concurrente dans de nombreux langages (par exemple en introduisant des threads), le problème est que l'ordre d'exécution est alors non déterministe et il devient extrêmement difficile d'écrire des tests pour des programmes concurrents.

En Erlang, la notion de programmation concurrente se fait par l'introduction d'« acteurs » indépendants qui communiquent entre eux par l'échange de messages (Erlang gère même les cas de « timeout »). L'exécution devient alors parfaitement déterministe, le programme est simple, facile à comprendre, et il devient facile d'écrire des tests.

Cette présentation fut extrêmement intéressante. Elle a permis de montrer l'intérêt de la TDD en programmation fonctionnelle ainsi que les avantages de Erlang pour résoudre les problèmes de programmation concurrente et faciliter les tests pour ce type de programmes. Cette présentation a également permis de montrer que la programmation fonctionnelle pouvait être utilisée dans certains projets industriels.

Pour bien comprendre cette session, il est utile d'avoir quelques connaissances des bases de la programmation fonctionnelle, pas forcément en Erlang (pour ma part je ne connaissais pas du tout Erlang, j'étais plus habitué à Ocaml).

Toute la difficulté pour les orateurs fut de présenter, en 60 minutes seulement, les différents concepts liés à la programmation fonctionnelle devant un public peu habitué à ce genre de programmation (comme en témoignent les questions posées lors de la séance), et cela avant même de rentrer dans le cœur du sujet : les tests.

Afin que la session reste accessible au plus grand nombre, les exemples choisis restent simples (l'exemple sur les listes est un cas d'école). De fait, les habitués de la programmation impérative s'interrogent sur l'intérêt de la programmation fonctionnelle alors que les habitués de la programmation fonctionnelle (en minorité dans la salle) auraient été friands de cas moins triviaux (ce qui aurait rendu, de fait, la session beaucoup moins accessible).