Tu fais un amalgame classique facon usenet (on me l'a reproche recemment): je prend X et Y, je critique Y et j'en deduis des choses sur X alors que si je prends Z sans Y, il n'y a pas de probleme donc Z est mieux.
Reprenons dans le detail:
"En XP" --> X
"tu va faire une estimation à la louche des changements, du temps et du prix de celui ci" --> Y
"avec une methodologie" --> Z
"(mais ça demande du travail)" --> opppose de Y
Ma conclusion:
Que tu utilises XP ou UML, si tu fais tes estimations a la louche, ce sont des estimations a la louche et tu as toutes les chances de te planter. Si tu y consacres du travail et du temps (si tu t'appliques), tu as toutes les chances de moins te planter.
XP ne t'empeche pas d'avoir une approche propre et de faire les choses comme il faut.
A mon avis, une bonne analyse marche quelle que soit la methode.
Avec XP cependant, comme ton programme est blinde de test (mais vraiment blinde: "TEST EVERYTHING THAT COULD POSSIBLY BREAK"), l'approche la plus simple pour voir l'impact d'un changement est de le faire. Pas besoin de l'implementer, casse juste tout ce que ton changement va casser et regarde les tests qui foirent. C'est bon, tu sais exactement ce qui va foirer et tu peux faire ton estime.
Avec ton diagramme UML, tu vas reflechir, reflechir, analyser, fouiller jusqu'a te dire
"ca va casser ca et ca et a mon avis, ca aussi. Faudra verfier ca." . Tu n'as aucune assurance que tu n'a pas oublie un bout de code dans un coin.
"Evidemment si tu codes dans ton coin un produit pour ton usage, l'extreme programming à toujours raison d'être."
Je pense que tu ne connais pas bien XP pour dire une chose pareille. La chose la plus importante en XP est le client. C'est lui qui definit tout.
Je t'invite a aller lire "XP installed", en libre telechargement: ftp://ftp.xprogramming.com/ftp/xpinstall.pdf(...)
C'est en anglais, mais ce sont des chapitres courts qui se lisent tres agreablement, dans un anglais simple.
Je parie ma chemise que au contraire, le bouquin d'UML modelise des trucs complexe et se lit mieux avec un aspirine a portee de main.
Des gens dans ce post se sont plaints de programmes code en XP non maintenables. Vous etes tombes sur du faux XP, sur des gens qui n'avaient pas applique tous les principes.
Je ne vois pas comment du code peut etre non maintenable quand:
- "Pair programming": il est ecrit par deux personnes au moins devant un ecran. Donc il y en a au moins deux qui le comprennent.
- "Do the simplest thing": il n'est pas plus complique qu'il ne devrait.
- "Test everything that could possibly break": le code est teste profondement. Donc, si tu casses qqch, ca se verra tout de suite. Cela impose aussi d'utiliser des structures plus simple. Tu ne peux pas tester proprement une fonction de 200 lignes. Mais tu peux tester facilement 20 fonctions de 12 lignes.
- "Refactor mercilessly": notamment, toute chose n'est faite qu'a un et un seul endroit. Il suffit de changer cet endroit pour modifier le comportement.
- "Let your code express your intention": le code doit etre clair en lui-meme, pas de bidouilles obscures.
- "Shared ownership": tout le monde partage le code et le travaille, le programmeur n'est pas dans son coin a coder sa bidouille.
[^] # Re: XP c'est mieux
Posté par Philippe F (site web personnel) . En réponse à la dépêche Initiation au Rational Unified Process. Évalué à 2.
Reprenons dans le detail:
"En XP" --> X
"tu va faire une estimation à la louche des changements, du temps et du prix de celui ci" --> Y
"avec une methodologie" --> Z
"(mais ça demande du travail)" --> opppose de Y
Ma conclusion:
Que tu utilises XP ou UML, si tu fais tes estimations a la louche, ce sont des estimations a la louche et tu as toutes les chances de te planter. Si tu y consacres du travail et du temps (si tu t'appliques), tu as toutes les chances de moins te planter.
XP ne t'empeche pas d'avoir une approche propre et de faire les choses comme il faut.
A mon avis, une bonne analyse marche quelle que soit la methode.
Avec XP cependant, comme ton programme est blinde de test (mais vraiment blinde: "TEST EVERYTHING THAT COULD POSSIBLY BREAK"), l'approche la plus simple pour voir l'impact d'un changement est de le faire. Pas besoin de l'implementer, casse juste tout ce que ton changement va casser et regarde les tests qui foirent. C'est bon, tu sais exactement ce qui va foirer et tu peux faire ton estime.
Avec ton diagramme UML, tu vas reflechir, reflechir, analyser, fouiller jusqu'a te dire
"ca va casser ca et ca et a mon avis, ca aussi. Faudra verfier ca." . Tu n'as aucune assurance que tu n'a pas oublie un bout de code dans un coin.
"Evidemment si tu codes dans ton coin un produit pour ton usage, l'extreme programming à toujours raison d'être."
Je pense que tu ne connais pas bien XP pour dire une chose pareille. La chose la plus importante en XP est le client. C'est lui qui definit tout.
Je t'invite a aller lire "XP installed", en libre telechargement:
ftp://ftp.xprogramming.com/ftp/xpinstall.pdf(...)
C'est en anglais, mais ce sont des chapitres courts qui se lisent tres agreablement, dans un anglais simple.
Je parie ma chemise que au contraire, le bouquin d'UML modelise des trucs complexe et se lit mieux avec un aspirine a portee de main.
Des gens dans ce post se sont plaints de programmes code en XP non maintenables. Vous etes tombes sur du faux XP, sur des gens qui n'avaient pas applique tous les principes.
Je ne vois pas comment du code peut etre non maintenable quand:
- "Pair programming": il est ecrit par deux personnes au moins devant un ecran. Donc il y en a au moins deux qui le comprennent.
- "Do the simplest thing": il n'est pas plus complique qu'il ne devrait.
- "Test everything that could possibly break": le code est teste profondement. Donc, si tu casses qqch, ca se verra tout de suite. Cela impose aussi d'utiliser des structures plus simple. Tu ne peux pas tester proprement une fonction de 200 lignes. Mais tu peux tester facilement 20 fonctions de 12 lignes.
- "Refactor mercilessly": notamment, toute chose n'est faite qu'a un et un seul endroit. Il suffit de changer cet endroit pour modifier le comportement.
- "Let your code express your intention": le code doit etre clair en lui-meme, pas de bidouilles obscures.
- "Shared ownership": tout le monde partage le code et le travaille, le programmeur n'est pas dans son coin a coder sa bidouille.