Traduction : « La conception est-elle morte ? » de Martin Fowler (2004)

 J’ai toujours perçu les systèmes d’informations et les applications qui le composent comme un écosystème cherchant son équilibre. Ses composants vivent, se développent, évoluent et / ou disparaissent. Ce qui ne bouge pas et ne s’adapte pas finit toujours par mourir, c’est une des raisons aujourd’hui pour laquelle les systèmes d’informations se tournent vers les méthodes agile, ou vers l’agilité de manière plus générale : garantir qu’un système ou une application puisse se développer, telle la croissance d’un être qui s’adapte à son environnement.

Pour autant faut-il avoir conscience de son environnement, et des connexions qui le composent. La conception et l’architecture ont pour rôle d’analyser l’existant et les connexions possibles, et de définir comment un nouveau système doit être conçu pour s’intégrer au mieux.

Cependant nous ne sommes pas des Dieu, nous sommes faillibles et devons en permanence revenir sur nos erreurs. La création est en réalité une recherche constante d’équilibre, entre la conception et la réalisation, tandis que se développe un système. Concevoir nous permet de définir une cible et les moyens de l’atteindre, tandis que la réalisation concrétise une solution.

Les deux sont indissociables et fortement dépendants : concevoir se base sur l’expérience concrète de la réalisation, tandis que la réalisation serait aveugle sans un travail de conception lui permettant d’éviter de faire les mauvais choix. Trop souvent on cherche les séparer alors qu’ils devraient se soutenir l’un et l’autre.

Je suis tombé il y a quelque temps sur un article de Martin Fowler daté de 2004, que j’ai découvert via le site du Touilleur Express . J’ai retrouvé dans cet article cette vision concrète du mariage entre la conception et la réalisation.

N’ayant pas trouvé de traduction  Française, j’ai choisi d’apporter ma maigre contribution au net en proposant cette version Française. Je suis loin d’être billingue et de nombreuses coquilles sont probablement présentes, mais j’espère que cette traduction interessera les anglophobes qui cherchent eux aussi comment inscrire une démarche de conception dans une démarche Agile.

Le fichier au format pdf : Is_Design_Dead_Fr

 =======================================================================

La conception est-elle morte ?

Auteur : Martin Fowler ; Responsable Recherche, ThoughWorks

Dernière évolution significative : Mai 2004

Traduction : Aout 2011, Laurent Dumestier

Pour la plupart de ceux qui ont été brièvement en contact avec l’Extreme Programming, on peut avoir le sentiment que XP cherche à
entrainer la mort de la conception logicielle. Non seulement l’activité de conception telle que « Big up Front Design » (conception
totale au démarrage) est ridiculisée, mais des techniques de conception telles que l’UML, les Frameworks flexibles, et même les
patterns (ndt : patrons de conception) sont rabaissées au plus bas niveau ou simplement ignorées. En réalité, XP implique un gros
travail de conception, mais d’une manière différente de celle des processus logiciels bien établis. XP a rajeuni la notion de
conception évolutive au travers de pratiques qui permettent à l’évolution de devenir une stratégie de conception viable. Il apporte
aussi de nouveaux chalenges et compétences car les concepteurs doivent apprendre comment concevoir une conception simple, comment
utiliser la retro-conception pour maintenir une conception évolutive et comment utiliser les patterns de manière évolutive.

(Ce papier a été écrit à partir de mon bloc-notes pour la conférence XP 2000 et sa forme originale a été publiée dans le compte rendu).

Les pratiques qui permettent XP
La valeur de ce qui est simple
Que peut bien signifier la simplicité de toute façon ?
Et ce que la retro conception viole les règles du YAGNI ?
Les patterns et XP
Faire grandir une architecture
UML et XP
Sur les métaphores
Allez-vous être un architecte quand vous allez progresser ?
Reversibibilité
La volonté de concevoir
Des choses qui sont difficiles à retro-concevoir
Et ce que la conception devient mature ?
Alors, et ce que la conception est morte ?
Remerciements
Historique des modifications
Historique des traductions

L’Extreme Programming (XP) a défié un grand nombre d’idées communes sur le développement logiciel. Une des plus controversées a
été le rejet des efforts significatifs investis dans la conception « up-front » (définition d’une conception complète avant le
développement), en faveur d’une approche plus évolutive. Pour ses détracteurs, il s’agit d’un retour au développement «
coder et corriger » (ndt : « code and fix »), habituellement dénigré comme une forme de bidouillage (ndt : « hacking »). Pour ses fans
il est généralement perçu comme le rejet des techniques, principes et patterns de conception (tels que l’UML). Ne vous inquiétez pas
pour la conception, si vous vous concentrez sur votre code, une bonne conception apparaîtra d’elle-même.

Je me suis moi-même trouvé au cœur de cet argument. Une grande partie de ma carrière a impliqué l’utilisation de langages graphiques
de conception – tels que l’Unified Modeling Language (UML) et ses précurseurs – et de patterns de conception. En effet j’ai
écrit des livres à la fois sur l’UML et sur les patterns. Est-ce que mon engagement pour XP signifie que je reviens sur ce que tous
ce que j’ai écrit sur ces sujets, et qu’il m’a fait repartir de zéro face à de telles notions antirévolutionnaires ?

Et bien je n’imagine pas que je puisse vous quitter en maintenant le suspens avec cette note dramatique. La réponse courte est non.
La réponse longue est le reste de ce document.

Conception planifiée et évolutive

Pour cette présentation, je vais décrire 2 styles de conception pratiqués dans le développement logiciel. Peut être que le plus commun
est la conception évolutive. La conception évolutive signifie essentiellement que la conception des systèmes croît tandis que le système
est implémenté. La conception est une partie du processus de programmation, et comme le programme évolue les schémas de conception
changent aussi.

La conception évolutive habituellement utilisée est un désastre. La conception finie par être l’agrégation d’un lot de décisions
« ad hoc » (ndt : spécifiques et exceptionnelles), qui chacune rendent le code plus difficile à modifier. Par bien des façons vous
pouvez argumenter que ce n’est pas de la conception, et qu’il est certain que cette approche mène assurément vers une faible
conception. Comme Kent l’a mis en avant, la conception est là pour vous permettre de maintenir une facilité d’évolution du
logiciel sur le long terme. Quand la conception se détériore, il en est de même pour votre capacité à appliquer efficacement des
modifications. Vous subissez l’entropie logicielle : au cours du temps la conception devient de plus en plus mauvaise. Non seulement
cela rend le logiciel plus difficile à faire évoluer, mais cela facilite aussi à la fois l’apparition de bugs et augmente la
difficulté pour les détecter et pour les résoudre sans impacts. C’est le cauchemar du « coder et corriger », où les bugs deviennent
de manière exponentielle plus couteux à corriger au fur et à mesure que le projet se développe.

La conception planifiée (ndt : « Planned Design) est un moyen d’y remédier, et contient une notion née des autres branches
d’ingénierie. Si vous voulez fabriquer une niche, vous pouvez juste assembler du bois et obtenir un résultat sommaire. Cependant si
vous voulez fabriquer un gratte ciel, vous ne pouvez pas travailler de cette façon, le résultat s’effondrera avant même que vous
n’en ayez construit la moitié. Donc vous allez commencer avec des schémas d’ingénierie, réalisé avec un bureau d’ingénieur
comme celui dans lequel ma femme travaille dans le centre ville de Boston. Tandis qu’elle produit la conception elle prend
conscience des problèmes, en partie via des analyses mathématiques, mais surtout en utilisant des codes de construction. Les codes de
construction sont des règles sur la manière dont vous concevez des structures, ils sont basés sur l’expérience issue de ce travail
(et de formules mathématiques sous-jacentes). Une fois que la conception est faite, son entreprise d’ingénierie peut alors remettre
le résultat de conception à une autre entreprise qui va le construire. La conception planifiée pour les logiciels devrait fonctionner de
la même manière. Les concepteurs anticipent les principales problématiques à l’avance. Ils n’ont pas besoin d’écrire de code
parce qu’ils ne construisent par le logiciel, ils sont en train de le concevoir. Ainsi ils peuvent utiliser des techniques de
conception telles que l’UML, qui s’affranchit de certains détails de programmation et qui permet aux concepteurs de concevoir à
un niveau plus abstrait. Une fois que la conception est faite ils peuvent remettre le résultat à une autre équipe (ou même une autre
entreprise) à des fins de construction. Comme les concepteurs réfléchissent sur un périmètre plus large, ils peuvent éviter les séries
de décisions ad-hoc qui mènent à l’entropie logicielle. Le programmeur peut suivre la direction de la conception et, sous réserve
qu’il respecte la conception, avoir un système bien construit.

Aujourd’hui l’approche de la conception planifiée est omniprésente depuis les années 70, et beaucoup de gens l’ont utilisé.
Elle est de bien des façons meilleure que la conception évolutive du « coder et corriger ». Mais elle a des défauts. Le premier est
qu’il est impossible de penser à tous les problèmes que vous aurez à gérer quand vous programmerez. Il est donc inévitable qu’au
cours de la programmation vous aller découvrir des choses qui remettent en cause la conception. Cependant si les concepteurs ne sont
plus là, ont bougé sur un autre projet, qu’arrive-t-il ? Les programmeurs ont commencé à programmer en se basant sur la conception
et l’entropie alors se révèle. Même si les concepteurs ne sont pas partis, cela va prendre du temps de résoudre les problèmes de
conception, modifier les schémas et alors modifier le code. On observe alors habituellement une réparation rapide et une pression sur
les délais. Ainsi survient à nouveau l’entropie.

En outre il y a souvent un problème de culture. Les concepteurs occupent ce rôle grâce à leurs compétences et expériences, mais ils sont
tellement occupés par la conception qu’ils n’ont plus le temps de coder. Cependant les outils et le matériel du développement
logiciel évoluent très rapidement. Quand vous ne coder plus non seulement vous manquez les évolutions technologiques qui apparaissent,
mais vous perdez aussi le respect de ceux qui codent.

Cette tension entre les constructeurs et les concepteurs arrive aussi pour les bâtiments, mais c’est plus intense dans le monde du
logiciel. C’est intense parce qu’il y a une différence fondamentale. Dans le bâtiment il y a une séparation nette de compétence
entre ceux qui conçoivent et ceux qui construisent, mais pour le logiciel c’est moins le cas. Tout programmeur travaillant dans des
environnements avec un haut niveau de conception doit être très compétent. Suffisamment compétent pour remettre en cause les conceptions
issues des concepteurs, spécialement quand le concepteur est moins au fait des réalités quotidiennes de la plateforme de développement.

Maintenant ce problème peut être résolu. Peut être que nous pouvons gérer les tensions humaines ? Peut être que nous pouvons disposer de
concepteurs suffisamment compétents pour gérer la plupart des problèmes et avoir un processus suffisamment méthodique pour modifier les
schémas. Il y a cependant un autre problème : le changement du besoin. Le changement du besoin est le problème numéro un, qui cause des
maux de tête aux équipes projets logiciels qui le subissent.

Une manière de gérer l’évolution du besoin est de maintenir une flexibilité dans la conception afin que vous puissiez facilement la
modifier quand le besoin change. Cependant cela requiert de l’anticipation du type de changement auquel vous vous attendez. Une
conception peut être prévue pour gérer les aléas de la volatilité, mais tandis que cela aidera pour les modifications anticipées du
besoin, cela n’aidera pas (et ca pourra même gêner) pour les changements imprévus. Ainsi vous devez suffisamment comprendre les
besoins pour distinguer les zones volatiles entre elles, et mon observation est que c’est très dur à appliquer.

Maintenant certains de ces problèmes d’évolution du besoin sont dus à une compréhension insuffisante des besoins. Par conséquent un
grand nombre de personnes se concentre sur les processus ingénierie de définition du besoin, afin d’obtenir une meilleure expression
du besoin dans l’espoir que cela évitera que le besoin provoque une modification de la conception plus tard. Mais même ce chemin est
un de ceux qui ne mènent pas à un remède. Beaucoup de changements imprévus du besoin sont causés par une évolution du business. Ceux là
ne peuvent pas être empêchés, quelque soit l’attention portée par votre processus de définition du besoin.

Tout cela semble rendre la conception planifiée impossible. C’est sûr qu’il y a de grands défis. Mais je ne suis pas enclin à
clamer que la conception planifiée est pire que la conception évolutive. En effet cette dernière est plus communément pratiquée à la
manière « coder et corriger ». Pour ma part je préfère la conception planifiée au « coder et corriger ». Cependant je suis au fait des
problèmes de la conception planifié et je suis en train de chercher une nouvelle direction.

Les pratiques qui permettent XP

XP est controversé pour beaucoup de raisons, mais une des principales mises en avant est qu’il est partisan de la conception
évolutive plutôt que de la conception planifiée. Comme nous le savons, la conception évolutive ne peut possiblement pas fonctionner a
cause des décisions de conceptions ad-hoc et de l’entropie logicielle.

Au cœur de la compréhension de cet argument se trouve la courbe de changement du logiciel. La courbe de changement indique que tandis
que le projet se déroule, il devient exponentiellement plus couteux d’apporter des modifications. La courbe de changement est
habituellement exprimée en ces termes « une modifications réalisée en analyse qui coute 1$ en coutera une centaine pour le corriger en
production ». C’est ironique puisque la plupart des projets travaillent encore avec un processus ad-hoc qui n’a pas de phase
d’analyse, mais pour lequel le coût exponentiel est toujours là. La courbe de changement exponentielle justifie que la conception
évolutive ne puisse pas fonctionner. Elle nous indique aussi pourquoi la conception planifiée doit être pratiquée prudemment, parce que
toute erreur dans la conception planifiée doit faire face au même phénomène exponentiel.

L’idée fondamentale derrière XP est qu’il est possible de rabaisser la courbe suffisamment pour faire fonctionner la conception
évolutive. Cet abaissement est à la fois permis et exploité par XP. C’est la part de couplage entre les pratiques XP : ne pouvez pas
appliquer individuellement ces parties d’XP qui exploitent la courbe abaissée sans appliquer celles qui permettent cet abaissement.
C’est une source commune de controverse autour d’XP. Beaucoup de gens critiquent les pratiques d’exploitation sans
comprendre les pratiques qui permettent leur application. Souvent les reproches proviennent de critiques de leur propre expérience, où
ils n’ont pas appliqué les pratiques qui permettent l’application des pratiques d’exploitation. Le résultat est qu’ils
se sont brulé les doigts et que quand ils voient XP ils se rappellent juste du feu.

Il y a de nombreux ensembles qui constituent les pratiques qui permettent XP. Le cœur est composé des pratiques de test et
d’intégration continue. Sans la sécurité apportée par le test, le reste des pratiques XP serait impossible. L’intégration
continue est nécessaire pour conserver l’équipe synchronisée, et ainsi pouvoir apporter des changements et ne pas être inquiété par
son intégration avec le travail des autres. Ensemble ces pratiques peuvent avoir d’importants effets sur la courbe de changement. Il
m’a été rappelé cela une nouvelle fois ici à ThoughtWorks. L’introduction des tests et de l’intégration continue a été
marquée par une amélioration de l’effort de développement. En tout cas suffisamment pour remettre sérieusement en question
l’idée selon laquelle vous avez besoin de toutes les pratiques d’XP pour obtenir une importante amélioration.

La retro-conception a un effet similaire. Ceux qui retro-conçoivent leur code de manière méthodique comme suggéré par XP gagnent une
différence significative dans leur efficacité, comparé à être plus laxiste et à restructurer plus spécifiquement. C’est certainement
l’expérience que j’en tire après que Kent m’ait appris à retro-concevoir correctement. Après tout, seul un fort changement
m’aurait motivé à écrire tout un livre à ce sujet.

Jim Highsmith, dans son excellent « summary of XP » (résumé d’XP), utilise l’analogie d’un ensemble d’échelles. D’un
coté il y a la conception planifiée, de l’autre il y a la retro-conception. Dans les approches les plus traditionnels la conception
planifiée domine, parce que l’hypothèse est que vous ne pouvez pas changer d’avis plus tard. Comme le coût du changement décroît
alors vous pouvez faire la plus grande part de votre conception plus tard dans la retro conception. La conception panifiée ne doit pas
être écartée complètement, mais il y a maintenant dans la balance deux approches de conception avec lesquelles travailler. Pour moi
c’est comme si avant de connaitre la retro-conception, je faisais toutes mes conception avec une seule main.

Ce sont ces pratiques telles que l’intégration continue, le test et la retro-conception qui mettent en place un nouvel environnement
qui rend la conception évolutive possible. Cependant une chose que nous n’avons pas encore vu est où se trouve le point
d’équilibre. Je suis sur que, malgré l’impression vue de l’extérieur, XP n’est pas juste du test, du code et de la retro
conception. Il y a de la place pour concevoir avant de coder. Il y en a un peu avant tout développement, mais la plus grande partie
survient lors des itérations, avant de coder une tache particulière. Mais il y a un nouvel équilibre entre la conception « up-front » et
la retro conception.

La valeur de ce qui est simple

Deux des plus importants cris de ralliement d’XP sont les slogans « Faites de la manière la plus simple quelque chose qui peut
marcher » (ndt : « Do the Simplest Thing that Could Possibly Work ») et « Vous n’aurez pas besoin de cela » (ndt : « You Aren’t
Going to Need It »), aussi connu comme YAGNI. Les deux sont les manifestations des pratiques XP pour la conception simple.

La manière dont YAGNI est communément décrite est que vous ne devriez pas ajouter aujourd’hui du code qui sera uniquement utilisé
par une fonctionnalité qui sera nécessaire demain. D’un côté ca semble simple. Les problèmes viennent avec des choses telles que les
Frameworks, les composants réutilisables, et la conception flexible. De telles choses sont compliquées à construire. Vous payez un
surcout au départ pour les construire, et l’espoir que vous allez en tirer parti plus tard vous en coutera. Cette idée de construire
la flexibilité au départ est vue comme une partie de la clef d’une conception logicielle efficace.

Cependant l’avis d’XP est que vous n’aller pas construire des composants et Framework flexibles pour le premier cas qui
présente une fonctionnalité. Laisser ces structures grossir autant qu’elles en ont besoin. Si je veux une classe Argent
aujourd’hui qui gère l’addition mais pas la multiplication, alors je construis uniquement l’addition dans ma classe
Argent… Même si je suis sur que j’aurai besoin de la multiplication dans la prochaine itération, et que je comprends comment la
faire facilement, et que je pense que ca sera réellement facile à faire, je vais quand même le laisser à la prochaine itération.

Une des raisons pour cela est économique. Si je dois faire un quelconque travail qui est uniquement utilisé par une fonctionnalité qui
sera nécessaire demain, ca signifie que je sacrifie l’effort à investir dans ce qui doit être fait pour cette itération. Le planning
des livraisons indique ce sur quoi il est nécessaire de travailler maintenant, et travailler sur d’autres choses destinées au futur
est contraire aux engagements des développeurs envers le client. Il y a le risque que les « stories » (ndt : fonctionnalités accessible
pour un type d’utilisateur, francisé dans ce document sous le terme scénarios) de cette itération puissent ne pas être faites. Même
si dans les scénarios de cette itération il n’y a pas de risque c’est au client de décider quel travail supplémentaire doit être
fait – et cela peut ne pas impliquer la multiplication.

Ce désintéressement économique est le résultat de la possibilité que nous puissions ne pas avoir raison. Cependant aussi sûr de nous sur
la manière dont cette fonction marche, nous pourrions encore être dans le faux – spécialement parce que nous n’avons pas encore le
détail du besoin. Travailler sur la mauvaise solution se révèle très tôt être encore plus du gâchis que de travailler sur la bonne
solution au plus tôt. Et les spécialistes XP pensent généralement que nous avons trop tendance à être dans le faux que dans le vrai (et
je partage ce sentiment).

La seconde raison en faveur d’une conception simple est que la conception complexe est plus difficile à comprendre qu’une
simple. De plus toute modification du système est rendue plus difficile par l’ajout de complexité. Cela ajoute un coût durant la
période comprise entre le moment où la conception complexe est ajoutée et le moment où elle est nécessaire.

Maintenant, cet avis est perçu par beaucoup de gens comme insensé, et ils ont raison de le penser. Cela vous amène à voir le monde du
développement habituel comme ne mettant pas en œuvre les pratiques permettant XP. Cependant quand l’équilibre entre la conception
planifiée et évolutive se modifie, alors YAGNI devient une bonne pratique (et seulement dans ce cas alors).

Donc résumons. Vous ne voulez pas dépenser d’effort pour ajouter de nouvelles capacités qui ne seront pas nécessaires avant une
future itération. Et même si le cout est zéro, vous nous n’en voulez toujours pas parce que cela augmente le prix des modifications
même si ca ne coute rien de l’ajouter. Cependant vous pouvez raisonnablement vous comporter de cette manière uniquement quand vous
utilisez XP, ou une technique similaire qui réduit le cout du changement.

Que peut bien signifier la simplicité de toute façon ?

Donc nous voulons notre code aussi simple que possible. Ca ne sonne pas comme si c’était dur d’argumenter en ce sens, après tout
qui veut être compliqué ? Mais bien sur cela pose la question « qu’est ce qui est simple ? ».

Dans XPE Kent donne quatre critères pour un système simple. Dans l’ordre (le plus important en premier) :

  • Faire fonctionner tous les tests ;
  • Révèler toutes les intentions ;
  • Pas de duplication ;
  • Le plus petit nombre de classes et méthodes.

« Faire fonctionner tous les tests » est un critère relativement simple. « Pas de duplication » est aussi très clair, bien que de
nombreux développeurs aient besoin d’aide sur la manière de l’accomplir.La plus ambiguë est celle qui a rapport avec la
révélation d’intention. Qu’est ce que ca signifie exactement ?

La valeur basique ici est la clarté du code. XP place une grande importance dans le code qui est facilement lisible. Dans XP « le code
propre » est un terme mal utilisé. Mais l’intention de révéler le code pour certains est compris comme des astuces pour
d’autres.

Dans son rapport XP 2000, Josh Kerievsky pointe un bon exemple de ce fait. Il regarde le code public d’XP possiblement le plus
utilisé – JUnit. JUnit utilise des « décorateurs » (patterns) pour ajouter des fonctionnalités optionnelles aux cas d’utilisation,
telles que la synchronisation concurrente et le code de mise en place de traitement par lot. En séparant ce code dans des « decorators
», cela permet au code général d’être plus clair qu’il n’aurait put l’être autrement.

Mais vous devez vous demandez vous-même si le code résultant est réellement simple. Pour moi il l’est, mais je suis familier avec le
pattern « decorator ». Mais pour ceux qui ne le sont pas c’est encore compliqué. De la même manière JUnit utilise des méthodes
enfichables pour lesquels j’ai observé que la plupart des gens les trouvent peu claires au départ. Donc devons nous conclure que la
conception de JUnit est plus simple pour les concepteurs expérimentés et plus compliquée pour ceux moins expérimentés ?

Je pense que se concentrer sur l’élimination de la duplication, à la fois pour le « Once and Only Once » (ndt : « Une fois et
seulement une ») d’XP et le DRY (ndt : « Don’t Repeat Yourself » – « Ne vous répétez pas vous-même »), est l’une des plus
évidente et merveilleuse bonne idée. Suivre seulement cette règle peut vous amener sur un long chemin. Mais ce n’est pas tout, et la
simplicité est encore une chose compliquée à trouver.

Récemment j’ai été impliqué dans la fabrication de quelque chose qui pourrait bien avoir une conception complexe. J’ai retro
conceptualisé et certains axes de flexibilité ont été retirés. Mais comme l’un des développeurs me l’a dit « c’est plus
facile de retro concevoir une conception trop complexe que ça ne l’est de retro concevoir aucune conception ». C’est mieux
d’être plus simple que vous n’en avez besoin, mais ce n’est pas un désastre d’être un peu plus complexe.

Le meilleur avis que je n’ai jamais entendu vient d’Oncle Bob (Robert Martin). Son avis était de ne pas s’accrocher trop à
deviner ce qu’est la conception la plus simple. Après que vous ayez fait tout votre possible, vous devrez et vous réaliserez la
retro conception plus tard. Au final, la volonté de retro concevoir est plus importante que de savoir ce qu’est la chose la plus
simple.

Et ce que la retro conception viole les règles du YAGNI ?

Ce sujet est arrivé sur la mailing list d’XP récemment, et le mieux serait de l’évoquer dans notre réflexion sur le rôle de la
conception dans XP.

D’un point de vue basique, la question commence avec le fait que retro concevoir prend du temps mais n’ajoute pas de
fonctionnalités. La règle de YAGNI est que vous êtes supposé concevoir pour le présent et non pour le futur, est-ce une violation ?

La règle de YAGNI est que vous ne devez pas ajouter une complexité qui n’est pas nécessaire pour l’itération en cours. C’est
une partie de la pratique de la conception simple. Retro concevoir est nécessaire pour garder la conception aussi simple que vous le
pouvez, aussi vous devriez retro concevoir dès que vous réalisez que vous pouvez rendre les choses plus simples.

La conception simplifiée exploite à la fois les pratiques d’XP et est une pratique permettant XP. C’est seulement si vous avez
les tests, l’intégration continue, et la retro conception que vous pouvez pratiquer la conception simple efficacement. Mais en même
temps conserver une conception simple est essentiel pour garder une courbe du changement plate. Toute complexité non nécessaire rend le
système plus difficile à dévier dans toutes les directions exceptée celle que vous avez anticipé avec la flexibilité que vous avez mis
dans la conception. Mais les gens ne sont pas doués pour anticiper, donc il est mieux de concentrer ses efforts sur la simplicité.
Cependant les gens ne vont pas obtenir la chose la plus simple du premier coup, donc vous avez besoin de retro concevoir afin de vous
rapprocher de cet objectif.

Les patterns et XP

L’exemple JUnit m’amène inévitablement à évoquer les Design Patterns (ndt : patrons de conception). La relation entre les
patterns et XP est intéressante, et c’est un sujet de recherche commun. Joshua Kerievsky soutient que les patterns sont sous-estimés
dans XP et ses arguments sont éloquents, donc je ne veux pas les répéter. Mais c’est une bonne chose de garder à l’esprit que
pour beaucoup de gens les patterns semblent en conflit avec XP.

L’essence de cet argument est que les patterns sont souvent sur-utilisés. Le monde est plein de programmeurs de légende, ayant tout
juste finit de lire le GOF (ndt : Gang of Four, le groupe de quatre auteurs de référence dans le domaine des Design Patterns) qui
contient 16 patterns dans 32 lignes de code. Je me souviens d’un soir, où alimenté par un très bon whisky, j’écrivais avec Kent
un article intitulé « Pas de patron de conception : 23 mauvaises astuces ». Nous pensions à des choses comme utiliser un « if statement
» (bloc conditionnel) plutôt qu’un « strategy » (ndt : un patron de conception connu). La blague est que cela a un sens, les
patterns sont souvent trop utilisés, mais ça ne fait pas d’eux une mauvaise idée. La question est de savoir comment vous les
utilisez.

Une des théories à ce sujet est que les forces d’une conception simple vont vous amener vers les patterns. Beaucoup de
retro-conceptions le font de manière explicite, mais même sans cela si vous suivez les règles de la conception simple vous allez arriver
aux patterns, même si vous ne les connaissez pas encore. Cela peut être vrai, mais est ce réellement la meilleur manière de le faire ?
Assurément c’est mieux si vous savez grossièrement où vous allez et que vous avez un livre qui vous aide à résoudre les problèmes
plutôt que d’avoir à tout inventer vous-même. C’est certain que je parcours encore le GOF quand je sens qu’un pattern va
être nécessaire. Pour moi la conception efficace nécessite que nous sachions le prix d’un pattern est bon à être payé – c’est
son avantage propre. De la même manière, comme Joshua le suggère, nous avons besoin d’être plus familier sur la manière dont nous
descendons graduellement vers les patterns. Sur ce sujet XP traite la manière d’utiliser les patterns différemment de la manière
dont les gens les utilisent, mais n’en enlève absolument pas leur intérêt

En lisant certains extraits de la mailing list j’ai l’impression claire que beaucoup de gens voient XP comme décourageant
l’usage des patterns, malgré l’ironie du fait que la plupart des promoteurs d’XP sont aussi des leaders des mouvements pour
les patterns. C’est parce qu’ils ont vu au delà des patterns, ou parce que les patterns sont tellement encrés dans leurs
pensées, qu’ils ne l’on pas réalisé ? Je ne connais pas la réponse pour les autres, mais pour moi les patterns sont toujours
d’une importance vitale. XP peut être un processus pour le développement, mais les patterns sont un squelette pour le savoir
conceptuel, savoir qui apporte de la valeur quel que soit votre processus. Différents processus peuvent utiliser des patterns de
différentes manières. XP embarque à la fois la non utilisation d’un pattern tant que ce n’est pas nécessaire et vos amène sur
des patterns via l’implémentation simple. Mais les patterns sont encore une pièce maitresse du savoir à acquérir.

Mon avis est que les utilisateurs d’XP utilisant des patterns devraient :

  • investir du temps pour apprendre les patterns ;
  • se concentrer sur quand appliquer le pattern (pas trop tôt) ;
  • se concentrer sur comment implémenter le pattern dans sa forme la plus simple dans un premier temps, et ajouter de la complexité plus
    tard ;
  • si en plaçant un pattern on réalise plus tard qu’il n’en ne vaut pas la peine, ne pas être effrayé à l’idée de
    l’enlever à nouveau.

Je pense qu’XP devrait impliquer encore plus l’apprentissage des patterns. Je ne suis pas sûr de la manière dont je
l’adapterais aux pratiques d’XP, mais je suis sur que Kent serait d’accord pour aller dans ce sens.

Faire grandir une architecture

Qu’est ce que cela signifie être un architecte logiciel ? Pour moi le terme architecture amène à une notion sur les éléments situés
au cœur du système, ceux qui sont difficiles à faire évoluer. Les fondations sur lesquelles le reste doit être construit.

Quel rôle joue un architecte quand vous utilisez la conception évolutive. Encore une fois on critique le fait qu’XP ignore
l’architecture, que l’objectif d’XP est de produire du code rapidement et de faire confiance à la retro-conception pour
corriger tous les problèmes de conception. Il est intéressant de voir qu’ils sont dans le vrai, et que ca pourrait bien être leur
faiblesse. Certainement les experts XP – Kent Beck, Ron Jeffries, et Bob Martin – ont dépensé énormément d’énergie afin d’éviter
tout mécanisme de conception amont au départ. Ne le stockez pas dans une base de données tant que vous n’êtes pas sûr d’en avoir
besoin. Travaillez avec des fichiers d’abord et retro-concevez la base de données durant la dernière itération.

Je suis connu pour être un expert XP lâche, et en tant que tel je me dois de désapprouver. Je pense qu’il y a un rôle pour une large
part d’architecture au départ. Des choses telles que définir tôt la manière dont séparer en couche l’application, la manière
dont vous aller interagir avec la base de donnée (si vous en avez besoin d’une), quelle approche utiliser pour gérer le serveur web.

Pour l’essentiel, je pense que la plupart de ces domaines sont des patterns que nous avons appris au fil des années. Tandis que
votre savoir sur les patterns grandit, vous devriez avoir raisonnablement une première idée sur la manière de les utiliser. Toutefois la
clef qui fait la différence est que ces décisions d’architecture prises tôt ne doivent pas être considérées comme gravées dans le
marbre, ou plutôt l’équipe doit savoir qu’ils peuvent faire des erreurs dans ces décisions prises tôt, et qu’ils devraient
avoir le courage de les réparer. D’autres ont raconté l’histoire d’un projet qui, proche du déploiement, a décidé qu’il
n’avait plus besoin des EJB et qui les a retiré de leur système. C’était une retro conception de dimensionnement, ca a été
réalisé tard, mais les pratiques permettant XP ont rendu non seulement cela possible, mais intéressant.

Comment cela aurait il put fonctionner avec une autre façon de faire ? Si vous décidez de ne pas utiliser les EJB, serait-ce plus dur de
les ajouter plus tard ? Devriez vous ainsi ne jamais commencer avec les EJB tant que vous n’avez pas essayé de faire sans et
découvert que ca ne marchait pas ? C’est une question qui implique de nombreux facteurs. C’est sûr que travailler sans un
composant complexe augmente la simplicité et fait aller les choses plus vite. Toutefois des fois il est plus facile de se débarrasser de
quelque chose comme ça que d’avoir à l’incorporer.

Donc mon avis est de commencer par évaluer ce qu’est vraisemblablement l’architecture. Si vous voyez une large quantité de
donnée avec de multiples utilisateurs, lancez-vous et utilisez une base de données dès le premier jour. Si vous voyez une logique métier
complexe, incorporez une modélisation du domaine (NDT : « domain model », la modélisation du métier, avec son vocabulaire, ses entités,
processus et les relations). Toutefois en déférence aux dieux du YAGNI, quand vous avez un doute, faites l’erreur de choisir la
simplicité. Aussi soyez prêt à simplifier votre architecture dès que vous voyez quelle partie de l’architecture n’apporte plus
rien.

UML et XP

De toutes les questions que j’ai eues au sujet de mon engagement dans XP, une des plus difficiles à résoudre concerne mes relations
vis-à-vis de l’UML. Et ce que les deux sont incompatibles ?

Il y a un grand nombre de points d’incompatibilité. Bien sûr qu’XP rejette l’importance des diagrammes. Malgré tout la
position officielle s’apparente plus à « utilisez les s’ils sont utiles », il y a un fort sous entendu de « les véritables
experts XP ne font pas de diagrammes ». Cela est renforcé par le fait que les gens comme Kent ne sont pas du tout à l’aise avec des
diagrammes, en effet je n’ai jamais vu Kent volontairement dessiner un diagramme logiciel avec un quelconque système de notation
définit.

Je pense que le problème vient de causes séparées. Une d’entre elles est le fait que certains ont trouvé utiles les logiciels de
diagramme et d’autres non. Le danger viens de ceux qui pensent que ceux qui ne l’utilisent pas le devraient et vice-versa. A la
place nous devrions juste accepter que certaines personnes utiliseront des diagrammes et d’autres non.

L’autre problème est que les logiciels de modélisation tendent à être associés à un lourd processus nécessitant beaucoup de temps à
la création de diagrammes qui n’apportent rien et qui peuvent en réalité poser des difficultés. Donc je pense que les gens devraient
être conseillés sur la mannière d’utiliser correctement les diagrammes et d’éviter les pièges, plus que recevoir le message «
seulement si vous le devez (poltron) » qui est habituellement porté par les experts XP.

Donc voilà mon avis pour utiliser correctement les diagrammes.

Tout d’abord il faut garder à l’esprit pourquoi vous êtes en train de dessiner des diagrammes. La première valeur est la
communication. Une communication efficace signifie sélectionner les choses importantes et négliger le moins important.

La sélection est la clef de l’utilisation correcte d’UML. Ne dessinez pas toutes les classes – justes les importantes. Pour
chaque classe ne montrez pas tous les attributs et toutes les opérations – seulement les plus importantes. Ne dessiner pas des
diagrammes de séquences pour tous les cas d’usages et scénarios – seulement… vous avez compris l’idée. Un problème récurent avec
l’utilisation commune des diagrammes est que les gens essayent de les rendre compréhensibles. Le code est la meilleure source
d’information sur la compréhension, tout comme le code est la chose la plus facile à maintenir synchronisée avec le code. Pour les
diagrammes la facilité de compréhension est l’ennemi de la compréhension.

Une utilisation commune des diagrammes est d’explorer une conception avant que vous commenciez à la coder. Souvent vous avez
l’impression qu’une telle activité est illégale par rapport à XP, mais ce n’est pas vrai. Beaucoup de gens disent que quand
vous avez une tache difficile il vaut mieux se rassembler pour avoir une session de conception en premier. Toutefois quand vous faites
de telles sessions :

  • Faites les courtes
  • N’essayez pas d’adresser tous les détails (juste les plus importants)
  • Traitez la conception résultante comme une ébauche, non comme une conception finale

Le dernier point est qu’il faut préférer l’extension. En effet quand vous faites une conception complète dès le début, vous
allez inévitablement trouver que certains aspects de la conception sont faux, mais vous allez seulement le découvrir en codant. Ce
n’est pas un problème tant que vous modifiez la conception quand ça arrive. Les troubles proviennent du fait que les gens pensent
que la conception est figée, et qu’ils n’intègrent pas la connaissance qu’ils ont acquise au travers de la phase de codage
et qu’ils ne la répercutent pas dans la conception.

Changer la conception ne signifie pas forcement changer les diagrammes. Il est parfaitement raisonnable de décliner des diagrammes qui
vous aident à comprendre la conception et alors vous débarrasser des autres diagrammes. Le fait de les dessiner a apporté une aide
suffisante pour les rendre utiles. Ils n’ont pas à devenir des artefacts permanents. Les meilleurs diagrammes UML ne sont pas des
artefacts.

Beaucoup des experts XP utilisent des cartes CRC (ndt : cartes souvent physiques représentant des objets au sens développement). Ce
n’est pas en conflit avec UML. J’utilise un mixe entre CRC et UML tout le temps, utilisant selon le besoin la technique qui est
la plus utile pour le travail que j’ai à faire.

Une autre utilisation des diagrammes UML est pour documenter au fur et à mesure. Dans sa forme habituelle c’est un modèle qui réside
dans une boîte à outils. L’idée est de conserver cette documentation pour aider les gens à travailler avec le système. Dans la
pratique ça n’aide souvent pas du tout :

  • Ca prend trop de temps de garder les diagrammes à jour, donc ils se désynchronisent avec le code
  • Ils sont cachés dans une boîte à outil ou un gros classeur, donc personne ne les regardent
  • Donc mon avis pour qu’une documentation à jour fonctionne malgré ces différents problèmes observés :
  • Utilisez uniquement des diagrammes que vous pouvez maintenir à jour sans effort
  • Poser les diagrammes là où tout le monde peut facilement les voir. J’aime les accrocher sur un mur. Encouragez les gens à écrire
    sur les copies sur le mur avec un stylo pour les changements simples
  • Faites attention à si les gens les utilisent, sinon jetez les.

Le dernier aspect concernant l’utilisation d’UML est pour la documentation dans une situation de changement de main, telle que
quand un groupe passe la main à un autre. Là l’avis d’XP est que produire de la documentation est un épisode (ndt : « story »)
comme un autre, et ainsi la valeur métier est déterminée par le client. Encore une fois UML est utile ici aussi pour fournir des
diagrammes qui sont sélectionnés pour aider à la communication. Souvenez vous que le code est l’espace de stockage de
l’information détaillée, les diagrammes agissent pour résumer et mettre en lumière les problèmes importants.

Sur les métaphores

Ok je pourrais aussi bien le dire publiquement – je n’ai encore jamais touché à cette chose qu’est la métaphore. Je l’ai vu
fonctionner, et ça a d’ailleurs bien fonctionné sur le projet C3, mais ca ne signifie pas que j’ai une quelconque idée de
comment le faire, et il ne me reste plus qu’à décrire l’explication sur la manière de le mettre en place.

La pratique XP des métaphores est construite sur l’approche d’un système de noms de Ward Cunninghams. Le point important est
vous arrivez avec un ensemble de noms très biens connus qui agissent comme un vocabulaire pour parler du domaine. Ce système de noms
intervient dans la manière dont vous nommez les classes et les méthodes dans le système.

J’ai construit un système de nom en construisant un modèle conceptuel du domaine. Je l’ai fait avec les experts du domaine en
utilisant UML ou ses prédécesseurs. J’en ai déduit que vous devez être prudent en faisant ca. Vous avez besoin de garder un ensemble
minimal et simple de notations, et vous devez éviter de laisser des problèmes techniques détériorer le modèle. Mais si vous le faites
j’ai découvert que vous pouvez l’utiliser pour construire un vocabulaire du domaine que les experts du domaine peuvent
comprendre et utiliser pour communiquer avec les développeurs. Le modèle n’épouse pas parfaitement les classes de conception, mais
c’est suffisant pour donner un vocabulaire commun à la totalité du domaine.

Maintenant je ne vois pas une quelconque raison pour que ce vocabulaire ne soit pas métaphorique, par exemple la métaphore de C3
s’est révélé rentable pour la ligne de fabrication. Mais je ne vois pas non plus pourquoi baser votre système de nom sur le
vocabulaire du domaine est une mauvaise idée. Non pas que je penche vers un abandon d’une technique qui marche bien pour moi quand
il s’agit d’obtenir un système de noms.

Souvent les gens critiquent XP sur les bases que vous avez besoin au moins d’une conception dans les grandes lignes du système. Les
experts XP souvent répondent avec la réponse « c’est dans la métaphore ». Je pense que je n’ai toujours pas eut une explication
convaincante de ce qu’est une métaphore. C’est un vrai gouffre dans XP, et un de ceux dont les expert XP doivent se débarrasser.

Allez-vous être un architecte quand vous allez progresser ?

Pour la plupart, pour cette dernière décennie, le terme « architecte applicatif » est devenu populaire. C’est un terme qu’il est
personnellement difficile pour moi d’utiliser. Ma femme est un ingénieur en structure. La relation entre les architectes et les
ingénieurs est…intéressante. Ma favorite est « les architectes sont bon dans les trois B : les bulles, les buissons et les oiseaux (NDT
: bulbs, bushes, birds) ». L’idée est que les architectes arrivent avec de jolis dessins, mais ce sont les ingénieurs qui doivent
s’assurer qu’ils peuvent réellement faire tenir debout quelque chose. Par conséquent nous avons évité le terme architecte
logiciel, après tout si ma propre femme ne peut pas me traiter avec respect professionnel quelles chances ai-je que ça soit le cas avec
quelqu’un d’autre ?

Dans le logiciel, le terme architecte signifie plusieurs choses. (En logiciel, tous les termes signifient plusieurs choses). En général,
cela transporte dans tous les cas une certaine gravitée, telle que « je ne suis pas juste un simple développeur, je suis un architecte
». Cela peut se traduire par « je suis un architecte maintenant, je suis trop important pour faire des choses telles que
programmer ». La question devient alors de choisir de décider de vous séparer de l’effort de programmation du bas peuple, qui
est quelque chose que vous devriez faire quand vous déciderez d’exercer un management technique.

Cette question génère une énorme quantité d’émotion. J’ai vu des gens très en colère à l’idée de ne plus avoir de rôle en
tant qu’architecte. « Il n’y a pas de place dans XP pour les architectes expérimentés » est souvent la plainte que
j’entends.

De plus au sujet du rôle de concepteur lui même, je ne pense pas que XP ne mette pas en valeur l’expérience ou de bonnes compétences
de conception. Cependant beaucoup des promoteurs d’XP – Kent Beck, Bob Martin, et bien sur Ward Cunningham – sont ceux auprès
desquels j’ai appris le plus a propos de ce qu’est la conception. Toutefois cela signifie que leur rôle diffère de celui que
beaucoup voient comme un rôle de leader technique.

Comme exemple, je vais citer un de nos leaders techniques à ThoughWorks : Dave Rice. Dave traversé quelques cycles de vies et a assumé
une couverture non officielle de meneur technique sur un projet de 50 personnes. Son rôle en tant que leader signifiait dépenser
beaucoup de temps avec tous les programmeurs. Il travaillait avec un programmeur quand ils avaient besoin d’un coup de main, et il
observait pour voir qui allait avoir besoin d’aide. Un signe explicite est l’endroit où il s’assoit. En tant que responsable
sur le long terme, il pouvait tout aussi bien avoir le bureau qu’il souhaite. Il en a partagé un avec Cara, le responsable des
livraisons. Cependant durant les quelques derniers mois il s’est déplacé dans les open spaces où les programmeurs travaillent
(utilisant le style ouvert des « chambre de guerre » qui a les faveurs d’XP). C’est important pour lui parce que de cette façon
il peut voir comment ca se passe, et il est capable de donner un coup de main là où c’est nécessaire.

Ceux qui connaissent XP vont réaliser que je décris le rôle explicite du Coach pour XP. En effet un parmi les quelques jeux de mots que
fait XP il y a ce qu’il appelle la figure de responsable technique le « Coach ». La signification est claire : dans XP le
responsable technique est vu comme enseignant aux programmeurs et comme les aidants à prendre des décisions. C’est un des profils
qui exige aussi bien de bonnes compétences sociales que de bonnes compétences techniques. Jack Bolles lors de XP 2000 a commenté
qu’il y a une petite place maintenant pour le maitre solitaire. La collaboration et l’enseignement sont les clefs du succès.

A un dîner de conférence, Dave et moi avons parlé avec un opposant verbal d’XP. Tandis que nous discutions de ce que nous avions
fait, les similarités dans notre approche étaient évidentes. Nous aimons tous l’adaptabilité, le développement itératif. Tester est
important. Donc nous étions perplexes devant la férocité de cette opposition. Alors est venu cet argument, autour de l’idée que « la
dernière chose que je veux c’est que mes programmeur retro conçoivent et s’amusent avec la conception ». Maintenant c’était
clair. Le fossé conceptuel a été expliqué ensuite par Dave qui m’a parlé un peu plus tard « s’il ne fait pas confiance à ses
programmeurs, pourquoi ne les licencie-t-il pas ? ». Dans XP la chose la plus importante que le développeur expérimenté peut faire est
de transmettre autant de compétences que possible aux développeurs les plus juniors. A la place d’un architecte qui prend les
décisions importantes, vous avez un coach qui enseigne aux développeurs à prendre d’importantes décisions. Tout comme Ward
Cunningham l’a mis en évidence, cela amplifie ainsi les compétences et apporte plus au projet qu’un héros solitaire ne le
pourra.

Reversibibilité

A l’XP 2002 Enrico Zaninotto a donné un speech fascinant au sujet des liens entre les méthodes agiles et la fabrication économique
(Ndt « lean manufacturing » est une méthode de projet basée sur l’économie des coûts par la réduction du gâchis). Sa vision était
que un des aspects clés des deux approches sont qu’elles font s’écrouler la complexité en réduisant l’irréversibilité dans
le processus.

Dans cette vision une des sources principales de complexité est l’irréversibilité des décisions. Si vous pouvez facilement changer
vos décisions, cela signifie que c’est moins important de prendre les bonnes, ce qui vous simplifie beaucoup la vie. La conséquence
pour la conception évolutive est que les concepteurs ont besoin de réfléchir sur la manière dont ils peuvent éviter
l’irréversibilité dans leurs décisions. Plutôt que d’essayer de prendre la bonne décision, essayez maintenant de trouver une
manière pour reporter la décision à plus tard (quand vous aurez plus d’informations) ou de prendre la décision d’une façon qui
vous permettra de l’annuler plus tard avec un minimum de difficulté.

Cette détermination à supporter la réversibilité est une des raisons pour lesquelles les méthodes agiles placent beaucoup
d’importance dans les systèmes de contrôle du code source, et de tout investir dans un tel système. Bien que cela ne garantisse pas
la réversibilité, particulièrement pour les décisions sur le long terme, cela apporte une fondation qui donne confiance à l’équipe,
même si elle est rarement utilisée.

Concevoir pour la réversibilité implique aussi un processus qui met rapidement en évidence les erreurs. Un des avantages du
développement itératif est que les itérations rapides permettent aux clients de voir un système grandir, et si une erreur est faite dans
les expressions du besoin cela peut être identifié et corrigé sans que le coût de la réparation devienne prohibitif. Cette même mise en
évidence rapide est aussi importante pour la conception. Cela signifie que vous devez mettre les choses en avant afin que les zones
potentiellement sources de problèmes soient rapidement testées pour voir si un problème survient. Cela signifie aussi qu’il vaut
mieux expérimenter pour voir à quel point les changement futurs seront difficiles, même si vous ne faite pas de réel changement tout de
suite – en testant en réalité un prototype isolé sur une branche du système. Plusieurs équipes ont rapporté avoir essayé tôt un futur
changement sur un mode prototypé pour voir à quel point ce serait difficile s’il devait être réellement réalisé.

La volonté de concevoir

Tandis que je me suis beaucoup concentré sur les pratiques dans cet article, une chose qui est trop facile de ne pas prendre en compte
est l’aspect humain.

Afin de travailler, la conception évolutive a besoin d’une force qui mène vers la convergence. Cette force peut uniquement venir de
gens – quelqu’un dans l’équipe qui a la détermination de s’assurer que la qualité de la conception reste élevée.

Ca n’a pas à venir de tous le monde (bien que ca soit une bonne chose si c’est le cas), d’habitude juste une ou deux
personnes dans l’équipe prennent sous leur responsabilité de conserver une conception complète. S’est une des taches qui tombe
habituellement dans le giron du terme « architecte ».

Cette responsabilité signifie garder un œil constant sur les bases du code, regarder pour voir si certaines zones sont en train de
devenir sales, et mettre en place des actions rapides pour corriger le problème avant qu’il devienne incontrôlable. Le gardien de la
conception n’a pas à être celui qui le corrige – mais il doit s’assurer que cela est réparé par quelqu’un.

Une faible volonté de concevoir semble être la raison principale pour laquelle la conception évolutive peut échouer. Même si les gens
sont familiers avec les choses dont j’ai parlé dans cette article, sans cette volonté la conception ne se mettra pas en place.

Des choses qui sont difficiles à retro-concevoir

Peut-on utiliser la retro-conception pour gérer toutes les décisions de conception, ou est ce qu’il y a des problèmes qui sont
tellement impactant qu’ils sont difficiles à reporter à plus tard ? A ce moment, le dogme XP est que les toutes les choses sont
faciles à ajouter quand vous en avez besoin, donc YAGNI s’applique toujours. Je me demande s’il y a des exceptions. Un bon
exemple de quelque chose qui est controversé d’ajouter plus tard est l’internationalisation. Y a-t-il quelque chose d’aussi
douloureux que d’ajouter plus tard ce avec quoi vous devriez commencer de toute façon ?

Je peux facilement imaginer qu’il y a des choses qui tombent facilement dans cette catégorie. Toutefois la réalité est que nous
avons toujours eu très peu d’informations. Si vous devez ajouter quelque chose, comme l’internationalisation, vous aurez au
final tout à fait conscience de l’effort que ca prendra de le faire. Vous êtes cependant moins conscient de l’effort que cela
aurait pris, semaine après semaine, de le mettre en place et de le maintenir avant que ce soit réellement nécessaire. Aussi, vous êtes
moins conscient du fait que vous pourriez très bien être dans le faux, et donc vous aurez besoin de retro-concevoir de toute façon.

Une partie de la justification de YAGNI est qu’il y a beaucoup de ces besoins potentiels qui finissent par ne pas en être, ou qui au
minimum ne correspondent pas à ce à quoi vous vous attendiez. L’effort que vous aurez préservé en n’implémentant aucun besoin
est inferieur à l’effort nécessaire pour retro concevoir ceux dont vous avez réellement besoin.

Une autre problématique à garder en tête est de vous demander si vous savez réellement comment le faire. Si vous avez implémenté
l’internationalisation plusieurs fois, alors vous saurez les patterns que vous devez employer. Ainsi vous avez plus de chance
d’être dans le vrai. Ajouter des structures anticipées est probablement le mieux si vous êtes dans cette position, plutôt que si
vous êtes nouveaux sur le problème. Donc mon avis sera que si vous savez comment le faire, vous êtes dans une position où vous pouvez
juger les coûts de le faire maintenant et de le faire plus tard. Toutefois si vous ne l’avez pas fait auparavant, non seulement vous
n’est pas capable d’estimer le coût assez bien, mais vous êtes aussi le moins susceptible de le faire correctement. Dans ce cas
vous devriez l’ajouter plus tard. Si vous l’ajoutez alors, et trouvez que c’est difficile, vous serez probablement mieux que
si vous l’aviez ajouté plus tôt. Votre équipe est mieux expérimentée, vous connaissez le mieux le domaine et vous comprenez le mieux
les besoins. Souvent dans cette position vous regardez en arrière et voyez comment s’aurait été facile un recul complet. Cela aurait
put être plus difficile de l’ajouter que vous ne le pensez.

C’est aussi lié à la question à propos de l’ordre des scénarios (Ndt : « stories »). Dans « Planifier XP » (ndt : « Planning XP
»), Kent et moi exposons ouvertement notre désaccord. Kent est en faveur de laisser la valeur business être le seul facteur qui conduit
l’ordre des scénarios. Après avoir au début été en désaccord Ron Jeffries est maintenant d’accord avec cela. Je suis encore
incertain. Je pense que c’est un équilibre entre la valeur business et le risque technique. Cela devrait m’amener à fournir au
moins l’internationalisation tôt pour réduire ce risque.

Cependant c’est uniquement vrai si l’internationalisation était nécessaire dès la première livraison. Arriver à une livraison
aussi tôt que possible est d’une importance vitale. Il est préférable d’ajouter de la complexité après cette première livraison
si ce n’était pas nécessaire avant. La force d’embarquer un code qui fonctionne est énorme. Cela concentre l’attention du
client, augmente la crédibilité et est une source massive d’apprentissage. Faites tout ce que vous pouvez pour amener cette date au
plus tôt. Même si cela demandera plus d’effort pour ajouter quelque chose après la première livraison, il vaut mieux de livrer le
plus tôt possible.

Avec toute nouvelle technique c’est naturel que ces recommandations soient incertaines quand à son périmètre d’utilisation. La
plupart des experts XP se sont vu dire que la conception évolutive est impossible à cause de certains problèmes, pour découvrir que
finalement c’était quand même possible. Cette conquête des situations « impossibles » mène une confiance face à toutes les
situations qui peuvent arriver. Bien sûr vous ne pouvez pas faire une telle généralisation, mais tant que la communauté XP attaque les
frontière et échoue, nous ne pourront jamais être sur de là où sont ces frontières, et c’est une bonne chose que d’essayer et de
repousser plus loin le potentiel des frontières que les autres peuvent voir.

(Un article récent de Jim Shore discute de certaines situations, incluant l’internationalisation, où les frontières potentielles se
révèlent ne pas être des barrières après tout).

Et ce que la conception devient mature ?

Une des difficultés de la conception évolutive est qu’il est très difficile de dire si la conception est aujourd’hui mature. Le
danger d’entremêler la conception avec la programmation est que la programmation peut se passer de la conception – c’est la
situation où la conception évolutive diverge et échoue.

Si vous êtes dans une équipe de développement, alors vous sentez que la conception est amenée par la qualité du code de base. S’il
devient plus complexe et difficile de travailler avec le code de base, c’est qu’ils n’y a pas assez de conception de faite.
Mais tristement c’est un point de vue subjectif. Nous n’avons pas d’outil de mesure qui peuvent nous donner une vue
objective sur la qualité d’une conception.

Si ce manque de visibilité est difficile pour les gens techniques, il est de loin plus alarmant pour les membres non techniques
d’une équipe. Si vous êtes un manager ou client comment pouvez-vous dire si le logiciel est bien conçu ? Cela vous importe parce que
les logiciels avec une pauvre conception seront plus cher à modifier dans le futur.

Il n’y a pas de réponse facile à cela, mais il y a quelques ébauches :

  • Ecoutez les gens techniques. Si ils se plaignent à propos de la difficulté à faire des changements, alors prenez sérieusement en compte
    de telles plaintes et donnez leur le temps de corriger ;
  • Gardez un œil sur la quantité de code qui est jetée. Un projet qui à une retro-conception saine sera toujours prêt à jeter du mauvais
    code. Si rien n’est supprimé, alors c’est presque certain qu’il n’y a pas assez de retro conception de pratiquée – ce
    qui amènera à une dégradation de la conception. Cependant comme on peut abuser de toutes les métriques, l’opinion des gens
    techniquement bons prévaut sur toute mesure, malgré la subjectivité.

Alors, et ce que la conception est morte ?

Absolument pas, mais la nature de la conception a changé. La conception XP met en avant les compétences suivantes :

  • Un souhait constant de garder du code aussi clair et simple que possible ;
  • Des compétences de retro-conception de sorte que vous pouvez en toute confiance apporter des améliorations là où vous en ressentez le
    besoin ;
  • Une bonne connaissance des patterns : pas seulement connaître les solutions mais aussi apprécier quand les utiliser et comment évoluer
    avec elles ;
  • Concevoir en gardant un œil sur les futurs changements, savoir quand des décisions prises aujourd’hui vont devoir être changées
    dans le futur ;
  • Savoir comment communiquer la conception aux gens qui ont besoin de la comprendre, en utilisant des diagrammes et par-dessus tout : la
    conversation.

C’est une effrayante sélection de compétences, mais être un bon concepteur a toujours été difficile. XP ne rend pas réellement cela
plus facile, du moins pas pour moi. Mais je pense qu’XP nous donne une nouvelle manière de penser la conception efficace parce que
ca a rendu la conception évolutive une stratégie possible à nouveau. Et je suis un grand fan de l’évolution – sinon qui sait ce que
je pourrais être ?

Remerciements

Au cours de ces deux dernières années, j’ai amassé et volé beaucoup de bonnes idées de beaucoup de bonnes personnes. La plupart
d’entre elles sont perdues dans les faiblesses de ma mémoire. Mais je me souviens avoir retiré de bonnes idées de Joshua Kerievski.
Je me souviens aussi de beaucoup de commentaires utiles de Fred George et de Ron Jeffries. Aussi je ne peux pas oublier comment beaucoup
de bonnes idées continuent de venir de Ward et Kent.

Je suis toujours reconnaissant pour tous ceux qui ont posé des questions et mis en évidence les coquilles. J’ai été laxiste sur la
conservation d’une liste de ces connaissances, mais elle inclue Craig Jones, Nigel Thorne, Sven Gorts, Hilary Nelson, Terry
Camerlengo.

Historique des modifications

Ici ce trouve une liste des évolutions majeures apportées à ce document

  • Mai 2004 : ajout d’une section sur la « Volonté de concevoir », « Réversibilité » et « Et ce que concevoir est mature »
  • Février 2001 : article mis à jour avec des sections sur faire grandir une architecture, le rôle d’un architecte et où les choses
    qui sont difficiles à ajouter avec la retro-conception.
  • Juillet 2000 : Article original soumis à l’XP 2000 et posté sur martinfowler.com

Historique des traductions

  • Septembre 2011 : V 1.0 : Premier jet de la traduction et diffusion sur le net
This entry was posted in Uncategorized. Bookmark the permalink.

Comments are closed.