Programmation

La démarche extrêmement itérative proposée par XP n'est viable que si l'équipe est en mesure de garder la maîtrise technique de l'application, c'est-à-dire de faire en sorte que les modifications du code restent longtemps faciles et rapides malgré les nombreuses évolutions. Cette maîtrise n'est pas le fruit du hasard, elle est le résultat d'une discipline de développement qui s'appuie sur les pratiques suivantes :

Mise en place de tests unitaires

En complément des tests de recette, qui servent à prouver au client que le logiciel remplit ses objectifs, XP utilise intensivement les tests unitaires de non-régression. Ces tests sont écrits par les développeurs en même temps que le code lui-même, pour spécifier et valider le comportement de chaque portion de code ajoutée.

Typiquement, un test unitaire porte sur une classe ou une fonction précise. Il simule un contexte d'exécution, déclenche un traitement et vérifie le résultat de ce traitement à travers une suite d'assertions. Deux points importants méritent d'être soulignés :

• Les tests s'exécutent sans aucune interprétation de la part du développeur. Les assertions en question doivent vérifier automatiquement si le code testé fonctionne ou non.
• Dans un contexte XP le test est écrit juste avant le code proprement dit - en somme, le développeur pose clairement le problème avant d'implémenter la solution.

Les classes de tests ne sont pas jetées après usage : elles sont gérées par un framework dédié (1) , qui permet de les exécuter individuellement ou en totalité. La batterie de tests de l'application ne cesse donc de s'enrichir, et forme avec le temps un filet de sécurité qui permet aux développeurs d'effectuer des modifications dans le code existant sans crainte de régression.

Ces tests sont lancés à longueur de journée par les développeurs - en fait, à chaque compilation. Tous les tests unitaires doivent passer à 100% dans l'environnement d'un binôme avant tout report de modifications dans la version d'intégration du logiciel.

Cette pratique constitue l'une des pratiques centrales de XP. Ses avantages sont tels que chaque équipe, XP ou non, se doit de s'y pencher avec la plus grande attention :

• Les erreurs sont très vite détectées et localisées.
• Les tests donnent une vision précise de la tâche à réaliser et aident les développeurs à aller droit au but.
• Les tests placent les développeurs dans un contexte réduit qui leur permet de s'abstraire de la complexité du reste de l'application.
• Il est possible de s'assurer du fonctionnement global du système très rapidement, après toute modification du code, avant ou après toute intégration dans la version officielle du système.

Ce que l'on constate au final, c'est que les développeurs d'une équipe XP passent plus de temps à ajouter des fonctionnalités, et moins de temps à investiguer des défauts dans le code existant.

Remaniement du code

L'application est toujours maintenue aussi malléable que possible grâce à une activité permanente de remaniement (refactoring). Le remaniement consiste à retoucher ou réorganiser des portions de code existantes, à comportement fonctionnel identique, en vue d'améliorer la structure d'ensemble de l'application.

L'une des motivations principales de remaniement est l'absence de duplication dans le code : tout doit y apparaître "Once and Only Once". Lorsqu'un développeur doit utiliser une partie de code qui se trouve déjà quelque part, il remanie l'application de manière à pouvoir utiliser directement le code existant. De la sorte les modifications de l'application n'impactent généralement que peu d'endroits dans le code, ce qui allège d'autant le travail.

Le remaniement est également utilisé pour rendre le code plus clair : lorsqu'un développeur intervient sur une partie donnée du code, il la modifie si nécessaire afin de faciliter le travail de ceux qui passeront après lui.

Le remaniement est plus qu'un moyen de dépoussiérer le code : c'est une façon de faire émerger une conception aussi adaptée que possible aux besoins de l'application, en supprimant au fur et à mesure tout ce qui nuit à sa simplicité et peut ralentir l'équipe. Comme les tests unitaires, le remaniement est pratiqué à longueur de journée - il s'agit d'une discipline quotidienne de qualité, et non d'une activité épisodique de réécriture.

Conception simple

"You ain't gonna need it!" : on ne fait de conception que pour les fonctionnalités existantes, pas pour les fonctionnalités futures. En corollaire :

• On ne fait de généralisations dans la conception que lorsque des besoins concrets se font sentir.
• On n'introduit pas d'optimisations si elles ne sont pas demandées par le client.

En somme, plutôt que de préparer le logiciel pour un futur hypothétique, XP préconise de s'assurer que le travail actuel soit toujours bien fait (code testé, simple, lisible et sans duplications) de sorte que les changements restent faciles et rapides le moment venu.

Contrairement à ce que l'on pourrait penser au premier abord, cette position n'est pas celle de développeurs désireux de se consacrer à l'implémentation sans perdre de temps à concevoir. XP amène en réalité un changement dans l'objectif que l'équipe donne à la conception : il ne s'agit plus de concevoir pour anticiper des développements futurs, mais plutôt de concevoir le code existant de manière à ce qu'il soit dans les faits toujours bien conçu. En s'interdisant ainsi d'avoir un code médiocre, une équipe XP fait de la conception une activité vitale pour son fonctionnement. On observe d'ailleurs en pratique que les développeurs d'une équipe XP passent la plupart de leur temps à travailler sur cette conception.

_____

(1) Par exemple JUnit : http://www.junit.org