gestion_projet_xp

54
Les pratiques de l’Extreme Programming
PREMIÈRE PARTIE
La solution la plus facile qui puisse fonctionner consiste à copier le texte de la méthode et à le
coller dans une autre. Et de recommencer, lorsqu’on devra à nouveau recourir à un parcours
sélectif de répertoire.
Et si cette méthode n’est pas correcte ? (L’utilisation de tests automatisés n’évite pas forcément
toutes les anomalies.) Le programmeur – ou pire, ses coéquipiers – devra rechercher
toutes les variantes de la méthode et les corriger, une par une. À la perte de temps que représente
ce travail répétitif s’ajoute la multiplication des risques d’erreur lors de la correction. Et
si, par exemple pour optimiser les accès disques, il devient nécessaire de modifier l’algorithme
de parcours ? Même motif, même punition...
Il peut sembler difficile, dans des cas pratiques qui seront sans aucun doute plus délicats que
cet exemple, de faire la part des choses entre «simple» et «facile». On peut aussi nourrir
quelque inquiétude : à se demander à chaque fois si la solution qu’on a choisie est la plus
simple, ne va-t-on pas finir par être paralysé, incapable d’avancer ?
Remarque
Une bonne façon de déceler une solution facile, mais pas simple, est d’écouter parler le
programmeur concerné. Une phrase commençant par «C’est facile…» est un bon indice. On
sera également attentif à «Il n’y a qu’à…», plus subtil mais généralement tout aussi révélateur.
La recherche d’une solution simple commence généralement par une question : «Quelles sont
les différentes solutions possibles ?»
L’essentiel est de progresser – l’équipe a un projet à terminer, après tout ! Nous verrons plus
loin qu’un outil remarquablement efficace est à notre disposition pour simplifier ce qui – par
paresse ou par nécessité – est devenu complexe. Nous verrons aussi que la notion de simplicité
peut s’exposer en quelques mots – de façon toute simple.
Une autre subtilité tient à ce que la règle veut qu’on implémente «la solution la plus simple
qui puisse fonctionner» – mais pas «la plus simple», tout court. Si, pour un problème
complexe, on a absolument besoin d’une solution complexe – tant pis pour la simplicité ; il
faut disposer d’une solution.
Le travail de développement
Des différents points que nous avons abordés jusqu’à présent commence à émerger une vision
presque complète du travail de développement tel qu’il est conçu dans XP :
• On ajoute un test au système.
• Le test échoue : il faut écrire la fonctionnalité correspondante.
• On écrit uniquement le code le plus simple permettant de faire passer le test.
• On vérifie que le test passe.
• On simplifie en appliquant les techniques dites de «remaniement».