> Blabla pipo blabla!
> Oh, la belle entrée en matière, j'ai failli pas répondre a cause de cette phrase.
> Tu as de la chance, je suis de bonne humeur.
Vraiment, ta phrase ne meritait pas mieux.
> Je répond et tu me dit comment XP va le faire pour faire tout ça OK ?
Pour XP, j'ai fini le bouquin hier soir, donc je n'ai pas eu encore le temps de tester en reel :-)
Mais tout ce qu'ils recommandent me parait tres tres sense..
Comme UML, je pense que c'est un tout et que tu as du mal a ne parler que d'un des aspects.
L'accent tres fort mis sur la communication inter-developeur, developeur-client, developer-manager, manager-client, le partage du code, les tests, la recherche de la simplicite, la restructuration permanente de ton code, les release a intervalles courts. Tout ca doit contribuer aux effets precites.
Ce que tu dis a l'air interessant et merite certainement d'etre creuse (un peu). Mais je n'arrive pas a me defaire de l'idee que c'est un carcan rigide.
Comment UML gere-t-il les changements de spec ? Genre, je fais mon schema UML, j'ecris ma classe, et je m'apercois deux mois plus tard que en fait, il faut fusionner cette classe avec une autre, qui a aussi deja ete codee. Est-ce que tou mon travail est nique ?
"C'est quoi du code clair ?"
Du code que tout le monde comprend. Notamment 6 mois plus tard, quand qq'un doit faire une modif. Puisqu'en XP, il est ecrit a deux, il y a de fortes chances qu'il y ait plus de deux personnes qui le comprennent. Le code est aussi le plus simple possible.
"- a ecrire du code reutilisable ?
Pour des raisons indépendante de ma volontée, je dois zapper cette question (non, je me defile pas)
"
De toute facon, la reponse est difficile.
L'approche XP de ce probleme est:
- on utilise des regles de codage donc le code est lisible.
- le code est deja ecrit par deux personnes donc il est pas trop "private"
- faire le code le plus simple possible qui resoud votre probleme. Pas la peine de s'embeter avec des solutions compliquees potentiellement utiles et inutiles en pratique.
- votre code doit parler de lui-meme.
- ne pas hesiter a le restructurer en permanence pour qu'il parle plus et soit plus clair. On ne doit aussi avoir une fonctionnolite codee qu'a un seul endroit et un seul. Donc facilite de modification..
- un jeu de test garantit qu'il marche.
"- a ecrire des routines de tests pour les differents modules de son soft ?
Pour chaque classe définie je doit définir un ensemble de jeux de test. Une classe est validée au niveau projet que si elle passe ses jeux de test. Sinon, refus d'intégration. A noter que les jeux de test sont bien entendus definis par un tiers, à partir de la spécification
"
-> Black box testing.
Celui qui teste verifie uniquement que ta classe ressemble a sa specification et repond au methodes qui sont definies.
XP prefere le "white box testing". Tu connais ta classe. Tu teste "tout ce qui pourrait ne pas marcher". Cela veut dire que tu vas probablement ne pas tester une ou deux fonctions triviales, mais que en revanche, la ou tu as des doutes, tu va tester beaucoup plus. Tes tests seront plus intelligents.
UML m'evoque une approche tres theorique et academique de la programmation. Voici les problemes, voici les solutions theoriques: plus de doc, une meilleure conception des le depart, patati patata. Mais tout le monde sait qu'ecrire de la doc, ca fait chier les developpeurs. Faut pas aller trop contre la nature, mieux vaut se faire plaisir..
XP a l'approche opposee: d'habitude, un dev, ca se passe comme ca: la doc n'est jamais a jour, ca emmerde tout le monde de la faire, les documents de conceptions ne sont pas a jour, les specs ont eu besoin d'etre changee parce que le client a change d'avis, ...
Et XP a une approche pour gerer ces problemes reels.
Comment tu fais quand tu t'apercois au bout de 6 mois que ton projet va prendre non pas 6 mois de plus mais un an ? Quand ton client change d'avis ?
[^] # Re: hum
Posté par Anonyme . En réponse à la dépêche Initiation au Rational Unified Process. Évalué à 0.
> Oh, la belle entrée en matière, j'ai failli pas répondre a cause de cette phrase.
> Tu as de la chance, je suis de bonne humeur.
Vraiment, ta phrase ne meritait pas mieux.
> Je répond et tu me dit comment XP va le faire pour faire tout ça OK ?
Pour XP, j'ai fini le bouquin hier soir, donc je n'ai pas eu encore le temps de tester en reel :-)
Mais tout ce qu'ils recommandent me parait tres tres sense..
Comme UML, je pense que c'est un tout et que tu as du mal a ne parler que d'un des aspects.
L'accent tres fort mis sur la communication inter-developeur, developeur-client, developer-manager, manager-client, le partage du code, les tests, la recherche de la simplicite, la restructuration permanente de ton code, les release a intervalles courts. Tout ca doit contribuer aux effets precites.
Ce que tu dis a l'air interessant et merite certainement d'etre creuse (un peu). Mais je n'arrive pas a me defaire de l'idee que c'est un carcan rigide.
Comment UML gere-t-il les changements de spec ? Genre, je fais mon schema UML, j'ecris ma classe, et je m'apercois deux mois plus tard que en fait, il faut fusionner cette classe avec une autre, qui a aussi deja ete codee. Est-ce que tou mon travail est nique ?
"C'est quoi du code clair ?"
Du code que tout le monde comprend. Notamment 6 mois plus tard, quand qq'un doit faire une modif. Puisqu'en XP, il est ecrit a deux, il y a de fortes chances qu'il y ait plus de deux personnes qui le comprennent. Le code est aussi le plus simple possible.
"- a ecrire du code reutilisable ?
Pour des raisons indépendante de ma volontée, je dois zapper cette question (non, je me defile pas)
"
De toute facon, la reponse est difficile.
L'approche XP de ce probleme est:
- on utilise des regles de codage donc le code est lisible.
- le code est deja ecrit par deux personnes donc il est pas trop "private"
- faire le code le plus simple possible qui resoud votre probleme. Pas la peine de s'embeter avec des solutions compliquees potentiellement utiles et inutiles en pratique.
- votre code doit parler de lui-meme.
- ne pas hesiter a le restructurer en permanence pour qu'il parle plus et soit plus clair. On ne doit aussi avoir une fonctionnolite codee qu'a un seul endroit et un seul. Donc facilite de modification..
- un jeu de test garantit qu'il marche.
"- a ecrire des routines de tests pour les differents modules de son soft ?
Pour chaque classe définie je doit définir un ensemble de jeux de test. Une classe est validée au niveau projet que si elle passe ses jeux de test. Sinon, refus d'intégration. A noter que les jeux de test sont bien entendus definis par un tiers, à partir de la spécification
"
-> Black box testing.
Celui qui teste verifie uniquement que ta classe ressemble a sa specification et repond au methodes qui sont definies.
XP prefere le "white box testing". Tu connais ta classe. Tu teste "tout ce qui pourrait ne pas marcher". Cela veut dire que tu vas probablement ne pas tester une ou deux fonctions triviales, mais que en revanche, la ou tu as des doutes, tu va tester beaucoup plus. Tes tests seront plus intelligents.
UML m'evoque une approche tres theorique et academique de la programmation. Voici les problemes, voici les solutions theoriques: plus de doc, une meilleure conception des le depart, patati patata. Mais tout le monde sait qu'ecrire de la doc, ca fait chier les developpeurs. Faut pas aller trop contre la nature, mieux vaut se faire plaisir..
XP a l'approche opposee: d'habitude, un dev, ca se passe comme ca: la doc n'est jamais a jour, ca emmerde tout le monde de la faire, les documents de conceptions ne sont pas a jour, les specs ont eu besoin d'etre changee parce que le client a change d'avis, ...
Et XP a une approche pour gerer ces problemes reels.
Comment tu fais quand tu t'apercois au bout de 6 mois que ton projet va prendre non pas 6 mois de plus mais un an ? Quand ton client change d'avis ?