Souvenir d’eXtreme programming #13 : Le remaniement constant (constant refactoring)
Et non cher lecteur, le feuilleton eXtreme Programming n’est pas fini ! J’ai seulement eu d’autres projets quelque peu prenants (nDumbster entre autre).
Parlons donc du remaniement constant (constant refactoring). Il ne s’agit pas de déplacer régulièrement les personnes dans l’open space, même si cette pratique était aussi en vogue dans notre dotcom (on parlait de réorganisation spatiale !), mais de ne pas hésiter à modifier le code afin de le rendre plus propre, plus simple, plus maintenable.
Le remaniement est rendu possible par la présence de tests unitaires suffisants pour permettre des changements plus ou moins profonds dans le code sans risquer d’en perturber le fonctionnement (du moins une fois que tous les tests passent, bien sur). Sans une couverture complète du code par des tests unitaires, le remaniement constant devient une activité proche du saut à l’élastique sans élastique. Je parle de couverture complète, et non pas totale, pour signifier qu’il s’agit d’avoir voir suffisamment de tests pour tester “tout ce qui peut casser”.
Harnaché avec ses tests unitaires, le développeur peut donc se lancer dans les remaniements les plus audacieux, et cela sans le moindre risque. Enfin presque. Du moins nous avons constaté la fin de cette peur de perturber du code existant dont l’effet le plus visible chez nous était la tendance à dupliquer le code plutôt qu’a l’adapter à un nouveau besoin. Nous avions ainsi dans notre code ASP une pléthore de fonctions presque identiques à quelque variation près. Tout le monde avait peur de modifier une fonction existant en introduisant une variable supplémentaire afin d’éviter du code redondant, par exemple.
Refactoring
Et c’est bien là ce que permet le remaniement constant. A partir de petites améliorations, mais que l’on fait constamment, on obtient une application dont l’architecture est bonne tout au long de sa vie.
C’est bien évidement à l’encontre de l’approche classique, dans laquelle un architecte définira en détail l’architecture de l’application à partir de son cahier des charges. Comme en XP le cahier des charges détaillé n’existe pas, l’architecture détaillé non plus. Disons plutôt qu’on la construit au fur et à mesure.
Ceci ne rend cependant pas inutile tout notion d’architecture, mais change seulement la façon dont on la construit. En fait en XP on construit quasiment en même temps le cahier des charges, l’architecture et le code !
Dans le contexte d’un logiciel dont la définition n’est pas figé, sur un marché changeant, avec des clients ayant du mal à exprimer explicitement leurs besoins, mais capable de formuler précisément des demandes d’évolution, eXtreme Programming s’est révélé efficace. Et le remaniement permet d’obtenir une architecture homogène et non un patchwork de fonctionnalités collés ensembles.
Parmi les effets néfastes du refactoring si l’on n’y prend pas garde, c’est qu’il devient l’excuse du perfectionniste en retard. “D’accord j’ai passé trois jours sur cette tache prévue pour un jour, mais j’ai fait deux jours de refactoring”. Dans ce cas, je rappelle que le remaniement doit être constant, c’est à dire répartie durant les taches de développement, et non pas considéré comme une tache indépendante. On ne fait pas du remaniement sur n’importe quelle partie du code, mais sur une partie de code que l’on doit modifier pour une tâche en cours.
Il y a une bonne comparaison (je crois qu’elle vient de Kent Beck) entre le remaniement et le fait de nettoyer sa cuisine. Il vaut mieux cuisiner dans une cuisine propre (donc développer avec un code propre), mais on peut soit nettoyer sa cuisine avant de cuisiner, soit après avoir cuisiné, soit pendant qu’on cuisine. Et évidement si on nettoie pendant qu’on cuisine, le temps que l’on passe dans la cuisine n’est pas tellement plus long, alors que nettoyer avant de cuisiner risque de prendre plus de temps, surtout les casseroles bien sales ! Bref c’est lorsque l’on remanie son code durant l’écriture que le remaniement est le moins couteux.
Il reste encore quelques pratiques d’eXtreme Programming à traiter avant la fin de ce feuilleton. Si vous avez des questions ou des points que vous voudriez voir traiter, n’hésitez pas. Amis eXtreme Programmers, ne soyez pas triste à l’annonce de la fin proche, j’ai encore d’autres expériences à raconter. Notamment de l’eXtreme Programming en solo !
A suivre…
juillet 7th, 2005 à 19:52
Deux choses :
* Faute de frappe : eXtrempe Programming (+ plusieurs fautes d’accord, mais je m’y suis fait)
* Le dernier projet sur lequel j’ai travaillé l’a été avec une approche moit’ MDA, moit’ TDD (bcp de Junit et génération du modèle grâce au classes mappées sur la base accédée par Hibernate).
Je retrouve tout à fait l’esprit dans lequel j’ai pu programmer à cette période dans la phrase "Harnaché avec ses tests unitaires, le développeur peut donc se lancer dans les remaniements les plus audacieux, et cela sans le moindre risque. Enfin presque}}.
Cette expérience a été extrêmement bonne et je ne me vois pas une seconde développer à nouveau un projet sans écrire de tests unitaires à foison.
Mais un truc qui m’embête, c’est que j’ai cru comprendre que l’approche TDD et MDA étaient en opposition (the model is the code, the code is the model). Pour moi, elles peuvent être complémentaires.
Qu’en penses tu ?
juillet 7th, 2005 à 21:30
Merci pour la correction, pressé par le temps je ne me suis pas bien relu.
Le TDD est le MDA ne sont pas totalement opposés, puisque le TDD est une pratique de codage, alors que le MDA est une pratique d’architecture.
Il faudrait plutôt opposer MDA et XP. eXtreme Programming propose une approche complète du processus de développement logiciel, dont le TDD est une des pratiques, et MDA consiste (de ce que j’en ai compris, ne l’ayant pas pratiqué) à s’appliquer des modèles lors de la conception de l’architecture. Un peu comme les design patterns (à un plus bas niveau). Or XP n’est pas opposé aux patterns, aux contraires.
Dans la philosophie de base de XP (You Ain’t Gonna Need It), le principe est de ne pas en faire trop en amont pour obtenir un retour sur investissement constant, alors que les approches classiques peuvent mener à attendre longtemps avant d’avoir le plus petit bout d’application utilisable. Et l’approche MDA n’est pas complètement opposée à ce principe.
Bref comme tu l’as dit, l’essentiel est que la méthode utilisée fonctionne.