"Olivier Azeau" writes:
[...]
| Pour reprendre une analogie connue, si le cout d'un crash test
| automobile était tres faible et sa mise en oeuvre tres rapide, les
| constructeurs automobiles ne passeraient pas des mois a concevoir
un
| véhicule sur papier et a faire des simulations numériques : tous
les
| jours, ils construiraient un prototype grandeur nature en 5 minutes
et
| l'enverraient contre le mur pour voir s'il tient le coup.
| L'énorme avantage que nous avons en faisant du logiciel, c'est que
ce
| crash test rapide et a faible cout, nous l'avons : ca s'appelle du
code
| et des tests et cela suffit pour justifier un faible temps passé
"sur
| le papier" et une construction de prototype exécutable au cours de
la
| conception.
Là je ne suis pas d'accord. Il est peut-être ton cas que le crash
test
te coûte peu cher, mais il faudrait se garder d'en faire un
généralité. Le crash test que j'ai vu dans plusieurs projets
consiste en pusieurs batteries de tests, coûtant très chers et
mettant
en oeuvre beaucoup de ressources (humaines et matérielles). On ne
s'amuse pas en faire toutes les 5 minutes.
"Olivier Azeau" <ransom@xasamail.com> writes:
[...]
| Pour reprendre une analogie connue, si le cout d'un crash test
| automobile était tres faible et sa mise en oeuvre tres rapide, les
| constructeurs automobiles ne passeraient pas des mois a concevoir
un
| véhicule sur papier et a faire des simulations numériques : tous
les
| jours, ils construiraient un prototype grandeur nature en 5 minutes
et
| l'enverraient contre le mur pour voir s'il tient le coup.
| L'énorme avantage que nous avons en faisant du logiciel, c'est que
ce
| crash test rapide et a faible cout, nous l'avons : ca s'appelle du
code
| et des tests et cela suffit pour justifier un faible temps passé
"sur
| le papier" et une construction de prototype exécutable au cours de
la
| conception.
Là je ne suis pas d'accord. Il est peut-être ton cas que le crash
test
te coûte peu cher, mais il faudrait se garder d'en faire un
généralité. Le crash test que j'ai vu dans plusieurs projets
consiste en pusieurs batteries de tests, coûtant très chers et
mettant
en oeuvre beaucoup de ressources (humaines et matérielles). On ne
s'amuse pas en faire toutes les 5 minutes.
"Olivier Azeau" writes:
[...]
| Pour reprendre une analogie connue, si le cout d'un crash test
| automobile était tres faible et sa mise en oeuvre tres rapide, les
| constructeurs automobiles ne passeraient pas des mois a concevoir
un
| véhicule sur papier et a faire des simulations numériques : tous
les
| jours, ils construiraient un prototype grandeur nature en 5 minutes
et
| l'enverraient contre le mur pour voir s'il tient le coup.
| L'énorme avantage que nous avons en faisant du logiciel, c'est que
ce
| crash test rapide et a faible cout, nous l'avons : ca s'appelle du
code
| et des tests et cela suffit pour justifier un faible temps passé
"sur
| le papier" et une construction de prototype exécutable au cours de
la
| conception.
Là je ne suis pas d'accord. Il est peut-être ton cas que le crash
test
te coûte peu cher, mais il faudrait se garder d'en faire un
généralité. Le crash test que j'ai vu dans plusieurs projets
consiste en pusieurs batteries de tests, coûtant très chers et
mettant
en oeuvre beaucoup de ressources (humaines et matérielles). On ne
s'amuse pas en faire toutes les 5 minutes.
"Olivier Azeau" writes:
[...]
| Pour reprendre une analogie connue, si le cout d'un crash test
| automobile était tres faible et sa mise en oeuvre tres rapide, les
| constructeurs automobiles ne passeraient pas des mois a concevoir
un
| véhicule sur papier et a faire des simulations numériques : tous
les
| jours, ils construiraient un prototype grandeur nature en 5 minutes
et
| l'enverraient contre le mur pour voir s'il tient le coup.
| L'énorme avantage que nous avons en faisant du logiciel, c'est que
ce
| crash test rapide et a faible cout, nous l'avons : ca s'appelle du
code
| et des tests et cela suffit pour justifier un faible temps passé
"sur
| le papier" et une construction de prototype exécutable au cours de
la
| conception.
Là je ne suis pas d'accord. Il est peut-être ton cas que le crash
test
te coûte peu cher, mais il faudrait se garder d'en faire un
généralité. Le crash test que j'ai vu dans plusieurs projets
consiste en pusieurs batteries de tests, coûtant très chers et
mettant
en oeuvre beaucoup de ressources (humaines et matérielles). On ne
s'amuse pas en faire toutes les 5 minutes.
"Olivier Azeau" <ransom@xasamail.com> writes:
[...]
| Pour reprendre une analogie connue, si le cout d'un crash test
| automobile était tres faible et sa mise en oeuvre tres rapide, les
| constructeurs automobiles ne passeraient pas des mois a concevoir
un
| véhicule sur papier et a faire des simulations numériques : tous
les
| jours, ils construiraient un prototype grandeur nature en 5 minutes
et
| l'enverraient contre le mur pour voir s'il tient le coup.
| L'énorme avantage que nous avons en faisant du logiciel, c'est que
ce
| crash test rapide et a faible cout, nous l'avons : ca s'appelle du
code
| et des tests et cela suffit pour justifier un faible temps passé
"sur
| le papier" et une construction de prototype exécutable au cours de
la
| conception.
Là je ne suis pas d'accord. Il est peut-être ton cas que le crash
test
te coûte peu cher, mais il faudrait se garder d'en faire un
généralité. Le crash test que j'ai vu dans plusieurs projets
consiste en pusieurs batteries de tests, coûtant très chers et
mettant
en oeuvre beaucoup de ressources (humaines et matérielles). On ne
s'amuse pas en faire toutes les 5 minutes.
"Olivier Azeau" writes:
[...]
| Pour reprendre une analogie connue, si le cout d'un crash test
| automobile était tres faible et sa mise en oeuvre tres rapide, les
| constructeurs automobiles ne passeraient pas des mois a concevoir
un
| véhicule sur papier et a faire des simulations numériques : tous
les
| jours, ils construiraient un prototype grandeur nature en 5 minutes
et
| l'enverraient contre le mur pour voir s'il tient le coup.
| L'énorme avantage que nous avons en faisant du logiciel, c'est que
ce
| crash test rapide et a faible cout, nous l'avons : ca s'appelle du
code
| et des tests et cela suffit pour justifier un faible temps passé
"sur
| le papier" et une construction de prototype exécutable au cours de
la
| conception.
Là je ne suis pas d'accord. Il est peut-être ton cas que le crash
test
te coûte peu cher, mais il faudrait se garder d'en faire un
généralité. Le crash test que j'ai vu dans plusieurs projets
consiste en pusieurs batteries de tests, coûtant très chers et
mettant
en oeuvre beaucoup de ressources (humaines et matérielles). On ne
s'amuse pas en faire toutes les 5 minutes.
Pierre Maurette wrote:
[...]
Vous faites un concours de banalités ? Je peux jouer ?
Voilà, c'est la réponse d'un "mauvais programmeur". Pour faire plaisir
à K. Ahausse ;-).
Ah ! non ! c'est un peu court, jeune homme !
On pouvait dire... Oh ! Dieu !... bien des choses en somme...
En variant le ton, -par exemple, tenez
Agressif : "Moi, monsieur, si j'étais si mauvais,
Personne n'accepterait que je programmasse !"
Amical : "Mais mon gars, tu codes comme une godasse
Va donc lire 'Programmez en Assembleur' !"
Descriptif : "C'est un coredump !.. c'est un bug !... c'est une erreur !
Que dis-je, c'est une erreur ?... Une ERREUR majuscules !"
Curieux : "Cela vous plait-il d'être si ridicule ?
...
http://mapage.noos.fr/echolalie/neznez.htm
Pierre Maurette wrote:
[...]
Vous faites un concours de banalités ? Je peux jouer ?
Voilà, c'est la réponse d'un "mauvais programmeur". Pour faire plaisir
à K. Ahausse ;-).
Ah ! non ! c'est un peu court, jeune homme !
On pouvait dire... Oh ! Dieu !... bien des choses en somme...
En variant le ton, -par exemple, tenez
Agressif : "Moi, monsieur, si j'étais si mauvais,
Personne n'accepterait que je programmasse !"
Amical : "Mais mon gars, tu codes comme une godasse
Va donc lire 'Programmez en Assembleur' !"
Descriptif : "C'est un coredump !.. c'est un bug !... c'est une erreur !
Que dis-je, c'est une erreur ?... Une ERREUR majuscules !"
Curieux : "Cela vous plait-il d'être si ridicule ?
...
http://mapage.noos.fr/echolalie/neznez.htm
Pierre Maurette wrote:
[...]
Vous faites un concours de banalités ? Je peux jouer ?
Voilà, c'est la réponse d'un "mauvais programmeur". Pour faire plaisir
à K. Ahausse ;-).
Ah ! non ! c'est un peu court, jeune homme !
On pouvait dire... Oh ! Dieu !... bien des choses en somme...
En variant le ton, -par exemple, tenez
Agressif : "Moi, monsieur, si j'étais si mauvais,
Personne n'accepterait que je programmasse !"
Amical : "Mais mon gars, tu codes comme une godasse
Va donc lire 'Programmez en Assembleur' !"
Descriptif : "C'est un coredump !.. c'est un bug !... c'est une erreur !
Que dis-je, c'est une erreur ?... Une ERREUR majuscules !"
Curieux : "Cela vous plait-il d'être si ridicule ?
...
http://mapage.noos.fr/echolalie/neznez.htm
Dans le message
,
Si je régarde autour de moi, au moins un tiers des
développeurs ont une fenêtre ouverte sur Google en
permanence. Comme par hazard, les plus competents sont tous
dans ce tiers-là.
Par curiosité, tu dirais qu'ils sont compétents grâce (entre
autres) à leur fenêtre sur Google ou bien c'est plutôt qu'ils
peuvent se permettre une fenêtre sur Google puisque tout le
monde sait qu'ils sont compétents ?
Et c'est Google pour Usenet ou comme engin de recherche ?
Dans le message
1106914712.073101.147460@c13g2000cwb.googlegroups.com,
Si je régarde autour de moi, au moins un tiers des
développeurs ont une fenêtre ouverte sur Google en
permanence. Comme par hazard, les plus competents sont tous
dans ce tiers-là.
Par curiosité, tu dirais qu'ils sont compétents grâce (entre
autres) à leur fenêtre sur Google ou bien c'est plutôt qu'ils
peuvent se permettre une fenêtre sur Google puisque tout le
monde sait qu'ils sont compétents ?
Et c'est Google pour Usenet ou comme engin de recherche ?
Dans le message
,
Si je régarde autour de moi, au moins un tiers des
développeurs ont une fenêtre ouverte sur Google en
permanence. Comme par hazard, les plus competents sont tous
dans ce tiers-là.
Par curiosité, tu dirais qu'ils sont compétents grâce (entre
autres) à leur fenêtre sur Google ou bien c'est plutôt qu'ils
peuvent se permettre une fenêtre sur Google puisque tout le
monde sait qu'ils sont compétents ?
Et c'est Google pour Usenet ou comme engin de recherche ?
Par exemple, [12h46 ; 13h01].
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)
Par exemple, [12h46 ; 13h01].
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)
Par exemple, [12h46 ; 13h01].
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)
wrote:Quant à quand il faut passer au codage, ça dépend évidemment
un peu du projet. Dans des grands projets, c'est assez
tardifs, parce que revenir en arrière sur la conception même
d'une classe coûte cher, s'il implique des modifications
chez tous les autres programmeurs. Mais même dans les cas
les plus simples, il vaut bien mieux avoir précisé
exactement ce que doit faire la classe, et les pré- et
post-conditions de ses fonctions, avant de commencer le
codage.
Je ne souscris pas a cette notion de "revenir sur la
conception coute cher"
car, tot ou tard, il faudra revenir sur la conception
(typiquement parce qu'il faudra rajouter des fonctionnalités)
et la ca coutera encore plus cher.
En fait cela est directement lié au taux de révision des
spécifications : plus les changements sont fréquents, plus on
a interet a se mettre dans une facon de travailler ou les
retours sur la conception ne coutent pas cher.
Pour ce qui est de quand passer au code, pour moi la réponse
est : des que j'ai un bout de conception suffisamment défini
pour l'exprimer sous forme de code et qui va donc me permetrre
de mettre ma conception a l'epreuve en lui donnant une
execution reelle et non plus sous forme de diagrammes de
sequence.
[snip]-- Comme outil de génération des en-têtes. Dans ce cas-là,
on avait même déclarer nos en-têtes comme des fichiers
dérivés (au sens de ClearCase), et non comme des sources. La
source était les diagrammes Rose. C'était un gros projet, et
les développeurs n'avait pas le droit de toucher aux
en-têtes sans autorisation particulière. (C'est un peu
normal, s'il y a cents autres personnes qui dépendent de tes
en-têtes.)
Si 100 personnes dépendent directement des entetes au sein
d'un meme projet, effectivement, il y a un probleme
mais, a mon avis, le probleme n'est plus de savoir si on a
fait de la conception avant d'écrire le code... Il est plutot
de savoir pourquoi ces entetes-la n'ont pas été séparées dans
un projet a part entiere...
[snip]-- Dans le dernier projet qu'on a fait, on s'en est servi
pour toute la génération. J'avoue que j'en étais un peu
scéptique au début, mais à la fin, j'étais ravi de ne pas
avoir à constamment répéter dans le .cc toute la partie
définition qu'il y avait dans le .hh. Je crois que cette
techinique serait difficile à gérer dans un grand projet ;
il faut une certaine dicipline dans l'édition des fichiers
générés (où il faut évidemment ajouter le code des
fonctions). Mais c'est de loin la solution que je trouve la
plus agréable pour des petits projets. Tu exprimes en UML ce
qui s'exprime le mieux en UML, et en C++ ce qui s'exprime le
mieux en UML. Prèsque, parce que la définition des détails
des fonctions pouvait être un peu pénible, avec
l'enchaînement des menus, etc. Mais ça restait dans
l'acceptable, et toujours plus facile que l'alternatif de
les écrire à la main. (Et n'oublie pas que je suis un des
virtuoses des éditeurs classiques, pour écrire des choses à
la main.)
J'ai connu ce cas la ou on avait poussé jusqu'a utiliser les
stereotypes UML pour qualifier les classes et les associations
et générer le C++ correspondant au travers d'un add-in Rose
fait maison mais le principal blocage fut la discipline
imposée par ce genre de process (l'autre moitié de l'équipe
n'a pas adhéré a la méthode pour diverses raisons) ce qui
depuis me laisse penser qu'une telle facon de faire est
généralement trop paralysante.
kanze@gabi-soft.fr wrote:
Quant à quand il faut passer au codage, ça dépend évidemment
un peu du projet. Dans des grands projets, c'est assez
tardifs, parce que revenir en arrière sur la conception même
d'une classe coûte cher, s'il implique des modifications
chez tous les autres programmeurs. Mais même dans les cas
les plus simples, il vaut bien mieux avoir précisé
exactement ce que doit faire la classe, et les pré- et
post-conditions de ses fonctions, avant de commencer le
codage.
Je ne souscris pas a cette notion de "revenir sur la
conception coute cher"
car, tot ou tard, il faudra revenir sur la conception
(typiquement parce qu'il faudra rajouter des fonctionnalités)
et la ca coutera encore plus cher.
En fait cela est directement lié au taux de révision des
spécifications : plus les changements sont fréquents, plus on
a interet a se mettre dans une facon de travailler ou les
retours sur la conception ne coutent pas cher.
Pour ce qui est de quand passer au code, pour moi la réponse
est : des que j'ai un bout de conception suffisamment défini
pour l'exprimer sous forme de code et qui va donc me permetrre
de mettre ma conception a l'epreuve en lui donnant une
execution reelle et non plus sous forme de diagrammes de
sequence.
[snip]
-- Comme outil de génération des en-têtes. Dans ce cas-là,
on avait même déclarer nos en-têtes comme des fichiers
dérivés (au sens de ClearCase), et non comme des sources. La
source était les diagrammes Rose. C'était un gros projet, et
les développeurs n'avait pas le droit de toucher aux
en-têtes sans autorisation particulière. (C'est un peu
normal, s'il y a cents autres personnes qui dépendent de tes
en-têtes.)
Si 100 personnes dépendent directement des entetes au sein
d'un meme projet, effectivement, il y a un probleme
mais, a mon avis, le probleme n'est plus de savoir si on a
fait de la conception avant d'écrire le code... Il est plutot
de savoir pourquoi ces entetes-la n'ont pas été séparées dans
un projet a part entiere...
[snip]
-- Dans le dernier projet qu'on a fait, on s'en est servi
pour toute la génération. J'avoue que j'en étais un peu
scéptique au début, mais à la fin, j'étais ravi de ne pas
avoir à constamment répéter dans le .cc toute la partie
définition qu'il y avait dans le .hh. Je crois que cette
techinique serait difficile à gérer dans un grand projet ;
il faut une certaine dicipline dans l'édition des fichiers
générés (où il faut évidemment ajouter le code des
fonctions). Mais c'est de loin la solution que je trouve la
plus agréable pour des petits projets. Tu exprimes en UML ce
qui s'exprime le mieux en UML, et en C++ ce qui s'exprime le
mieux en UML. Prèsque, parce que la définition des détails
des fonctions pouvait être un peu pénible, avec
l'enchaînement des menus, etc. Mais ça restait dans
l'acceptable, et toujours plus facile que l'alternatif de
les écrire à la main. (Et n'oublie pas que je suis un des
virtuoses des éditeurs classiques, pour écrire des choses à
la main.)
J'ai connu ce cas la ou on avait poussé jusqu'a utiliser les
stereotypes UML pour qualifier les classes et les associations
et générer le C++ correspondant au travers d'un add-in Rose
fait maison mais le principal blocage fut la discipline
imposée par ce genre de process (l'autre moitié de l'équipe
n'a pas adhéré a la méthode pour diverses raisons) ce qui
depuis me laisse penser qu'une telle facon de faire est
généralement trop paralysante.
wrote:Quant à quand il faut passer au codage, ça dépend évidemment
un peu du projet. Dans des grands projets, c'est assez
tardifs, parce que revenir en arrière sur la conception même
d'une classe coûte cher, s'il implique des modifications
chez tous les autres programmeurs. Mais même dans les cas
les plus simples, il vaut bien mieux avoir précisé
exactement ce que doit faire la classe, et les pré- et
post-conditions de ses fonctions, avant de commencer le
codage.
Je ne souscris pas a cette notion de "revenir sur la
conception coute cher"
car, tot ou tard, il faudra revenir sur la conception
(typiquement parce qu'il faudra rajouter des fonctionnalités)
et la ca coutera encore plus cher.
En fait cela est directement lié au taux de révision des
spécifications : plus les changements sont fréquents, plus on
a interet a se mettre dans une facon de travailler ou les
retours sur la conception ne coutent pas cher.
Pour ce qui est de quand passer au code, pour moi la réponse
est : des que j'ai un bout de conception suffisamment défini
pour l'exprimer sous forme de code et qui va donc me permetrre
de mettre ma conception a l'epreuve en lui donnant une
execution reelle et non plus sous forme de diagrammes de
sequence.
[snip]-- Comme outil de génération des en-têtes. Dans ce cas-là,
on avait même déclarer nos en-têtes comme des fichiers
dérivés (au sens de ClearCase), et non comme des sources. La
source était les diagrammes Rose. C'était un gros projet, et
les développeurs n'avait pas le droit de toucher aux
en-têtes sans autorisation particulière. (C'est un peu
normal, s'il y a cents autres personnes qui dépendent de tes
en-têtes.)
Si 100 personnes dépendent directement des entetes au sein
d'un meme projet, effectivement, il y a un probleme
mais, a mon avis, le probleme n'est plus de savoir si on a
fait de la conception avant d'écrire le code... Il est plutot
de savoir pourquoi ces entetes-la n'ont pas été séparées dans
un projet a part entiere...
[snip]-- Dans le dernier projet qu'on a fait, on s'en est servi
pour toute la génération. J'avoue que j'en étais un peu
scéptique au début, mais à la fin, j'étais ravi de ne pas
avoir à constamment répéter dans le .cc toute la partie
définition qu'il y avait dans le .hh. Je crois que cette
techinique serait difficile à gérer dans un grand projet ;
il faut une certaine dicipline dans l'édition des fichiers
générés (où il faut évidemment ajouter le code des
fonctions). Mais c'est de loin la solution que je trouve la
plus agréable pour des petits projets. Tu exprimes en UML ce
qui s'exprime le mieux en UML, et en C++ ce qui s'exprime le
mieux en UML. Prèsque, parce que la définition des détails
des fonctions pouvait être un peu pénible, avec
l'enchaînement des menus, etc. Mais ça restait dans
l'acceptable, et toujours plus facile que l'alternatif de
les écrire à la main. (Et n'oublie pas que je suis un des
virtuoses des éditeurs classiques, pour écrire des choses à
la main.)
J'ai connu ce cas la ou on avait poussé jusqu'a utiliser les
stereotypes UML pour qualifier les classes et les associations
et générer le C++ correspondant au travers d'un add-in Rose
fait maison mais le principal blocage fut la discipline
imposée par ce genre de process (l'autre moitié de l'équipe
n'a pas adhéré a la méthode pour diverses raisons) ce qui
depuis me laisse penser qu'une telle facon de faire est
généralement trop paralysante.
writes:
[...]
| > Il y a d'autres possibilités, comme de dire tout
| > simplement que Rose n'est pas un bon outil pour faire de
| > la conception ou communiquer dessus.
| Certes. Mais alors, tu te sers de quoi ? Rose m'emballe pas
| dans tous ses détails, mais j'arrive à m'en servir. Et faute
| d'autres choses... C'est toujours mieux que de faire ses
| dessins UML sur papier.
j'utilise pas UML.
J'utilise le tableau noir de BS.
Quand je suis seul, j'utilise un papier et un crayon.
kanze@gabi-soft.fr writes:
[...]
| > Il y a d'autres possibilités, comme de dire tout
| > simplement que Rose n'est pas un bon outil pour faire de
| > la conception ou communiquer dessus.
| Certes. Mais alors, tu te sers de quoi ? Rose m'emballe pas
| dans tous ses détails, mais j'arrive à m'en servir. Et faute
| d'autres choses... C'est toujours mieux que de faire ses
| dessins UML sur papier.
j'utilise pas UML.
J'utilise le tableau noir de BS.
Quand je suis seul, j'utilise un papier et un crayon.
writes:
[...]
| > Il y a d'autres possibilités, comme de dire tout
| > simplement que Rose n'est pas un bon outil pour faire de
| > la conception ou communiquer dessus.
| Certes. Mais alors, tu te sers de quoi ? Rose m'emballe pas
| dans tous ses détails, mais j'arrive à m'en servir. Et faute
| d'autres choses... C'est toujours mieux que de faire ses
| dessins UML sur papier.
j'utilise pas UML.
J'utilise le tableau noir de BS.
Quand je suis seul, j'utilise un papier et un crayon.
James Kanze wrote:Olivier Azeau wrote:Pour moi, il est clair que le meilleur moyen pour le
commun des développeurs d'arriver au code qui implémente
le plus simplement possible les fonctionnalités voulues
c'est de naviguer en permanence entre conception, code et
test.
Je ne dis pas que dans un très petit projet, on peut changer
de châpeau assez fréquemment. Mais les activités doivent
rester distinctes.
Tout dépend ce que l'on entend par distinctes - et je crois
que les divergences de points de vues résident dans ce point.
Si c'est pour dire : "il faut faire de la conception et ne pas coder
sans avoir un minimum réfléchi a un ensemble de classes et la facon
dont elles interagissent", tout le monde sera probablement d'accord.
Si c'est pour dire : "il faut avoir une vision assez complete
du systeme sous formes de schemas de classes, de sequence,
etc. avant d'écire du code",
j'ai vu plusieurs fois des équipes passer du temps a peaufiner
une conception avec une phase de conception dédiée et, a
chaque fois, l'équipe a trop tardé a écrire du code.
L'écriture de code permet a toute conception, aussi bonne soit
elle, de se confronter a la réalité de ce que va etre le
logiciel.
Pour reprendre une analogie connue, si le cout d'un crash test
automobile était tres faible et sa mise en oeuvre tres rapide,
les constructeurs automobiles ne passeraient pas des mois a
concevoir un véhicule sur papier et a faire des simulations
numériques : tous les jours, ils construiraient un prototype
grandeur nature en 5 minutes et l'enverraient contre le mur
pour voir s'il tient le coup.
L'énorme avantage que nous avons en faisant du logiciel, c'est
que ce crash test rapide et a faible cout, nous l'avons : ca
s'appelle du code et des tests et cela suffit pour justifier
un faible temps passé "sur le papier" et une construction de
prototype exécutable au cours de la conception.
(et je connais même des personnes qui disent que
l'écriture des tests doit venir avant celle du code mais
ceci est une autre histoire...)
C'est une des modes, aujourd'hui:-). Mais ils disent en fait
que les tests, c'est la documentation de la conception --
donc toujours qu'il faut d'abord la conception.
Ils disent aussi que les tests sont écrits au fur et a mesure
du code en itérations tres rapprochées -- ce qui revient a
dire : un petit bout de conception/test-un petit bout de
codage-un petit bout de conception/test-un petit bout de
codage-un petit bout de conception/test-un petit bout de
codage-...
James Kanze wrote:
Olivier Azeau wrote:
Pour moi, il est clair que le meilleur moyen pour le
commun des développeurs d'arriver au code qui implémente
le plus simplement possible les fonctionnalités voulues
c'est de naviguer en permanence entre conception, code et
test.
Je ne dis pas que dans un très petit projet, on peut changer
de châpeau assez fréquemment. Mais les activités doivent
rester distinctes.
Tout dépend ce que l'on entend par distinctes - et je crois
que les divergences de points de vues résident dans ce point.
Si c'est pour dire : "il faut faire de la conception et ne pas coder
sans avoir un minimum réfléchi a un ensemble de classes et la facon
dont elles interagissent", tout le monde sera probablement d'accord.
Si c'est pour dire : "il faut avoir une vision assez complete
du systeme sous formes de schemas de classes, de sequence,
etc. avant d'écire du code",
j'ai vu plusieurs fois des équipes passer du temps a peaufiner
une conception avec une phase de conception dédiée et, a
chaque fois, l'équipe a trop tardé a écrire du code.
L'écriture de code permet a toute conception, aussi bonne soit
elle, de se confronter a la réalité de ce que va etre le
logiciel.
Pour reprendre une analogie connue, si le cout d'un crash test
automobile était tres faible et sa mise en oeuvre tres rapide,
les constructeurs automobiles ne passeraient pas des mois a
concevoir un véhicule sur papier et a faire des simulations
numériques : tous les jours, ils construiraient un prototype
grandeur nature en 5 minutes et l'enverraient contre le mur
pour voir s'il tient le coup.
L'énorme avantage que nous avons en faisant du logiciel, c'est
que ce crash test rapide et a faible cout, nous l'avons : ca
s'appelle du code et des tests et cela suffit pour justifier
un faible temps passé "sur le papier" et une construction de
prototype exécutable au cours de la conception.
(et je connais même des personnes qui disent que
l'écriture des tests doit venir avant celle du code mais
ceci est une autre histoire...)
C'est une des modes, aujourd'hui:-). Mais ils disent en fait
que les tests, c'est la documentation de la conception --
donc toujours qu'il faut d'abord la conception.
Ils disent aussi que les tests sont écrits au fur et a mesure
du code en itérations tres rapprochées -- ce qui revient a
dire : un petit bout de conception/test-un petit bout de
codage-un petit bout de conception/test-un petit bout de
codage-un petit bout de conception/test-un petit bout de
codage-...
James Kanze wrote:Olivier Azeau wrote:Pour moi, il est clair que le meilleur moyen pour le
commun des développeurs d'arriver au code qui implémente
le plus simplement possible les fonctionnalités voulues
c'est de naviguer en permanence entre conception, code et
test.
Je ne dis pas que dans un très petit projet, on peut changer
de châpeau assez fréquemment. Mais les activités doivent
rester distinctes.
Tout dépend ce que l'on entend par distinctes - et je crois
que les divergences de points de vues résident dans ce point.
Si c'est pour dire : "il faut faire de la conception et ne pas coder
sans avoir un minimum réfléchi a un ensemble de classes et la facon
dont elles interagissent", tout le monde sera probablement d'accord.
Si c'est pour dire : "il faut avoir une vision assez complete
du systeme sous formes de schemas de classes, de sequence,
etc. avant d'écire du code",
j'ai vu plusieurs fois des équipes passer du temps a peaufiner
une conception avec une phase de conception dédiée et, a
chaque fois, l'équipe a trop tardé a écrire du code.
L'écriture de code permet a toute conception, aussi bonne soit
elle, de se confronter a la réalité de ce que va etre le
logiciel.
Pour reprendre une analogie connue, si le cout d'un crash test
automobile était tres faible et sa mise en oeuvre tres rapide,
les constructeurs automobiles ne passeraient pas des mois a
concevoir un véhicule sur papier et a faire des simulations
numériques : tous les jours, ils construiraient un prototype
grandeur nature en 5 minutes et l'enverraient contre le mur
pour voir s'il tient le coup.
L'énorme avantage que nous avons en faisant du logiciel, c'est
que ce crash test rapide et a faible cout, nous l'avons : ca
s'appelle du code et des tests et cela suffit pour justifier
un faible temps passé "sur le papier" et une construction de
prototype exécutable au cours de la conception.
(et je connais même des personnes qui disent que
l'écriture des tests doit venir avant celle du code mais
ceci est une autre histoire...)
C'est une des modes, aujourd'hui:-). Mais ils disent en fait
que les tests, c'est la documentation de la conception --
donc toujours qu'il faut d'abord la conception.
Ils disent aussi que les tests sont écrits au fur et a mesure
du code en itérations tres rapprochées -- ce qui revient a
dire : un petit bout de conception/test-un petit bout de
codage-un petit bout de conception/test-un petit bout de
codage-un petit bout de conception/test-un petit bout de
codage-...
