La différence entre un bon et un mauvais programmeur...
105 réponses
korchkidu
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
Sérieusement, je suppose que tu parles des sessions de « brainstorming », parce que la persistence du tableau noir n'est pas particulièrement bonne.
Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
-- Matthieu
Fabien LE LEZ
On Tue, 01 Feb 2005 09:23:43 +0100, korchkidu :
Mais n'y a t'il pas des concepts importants du C++ qui pour vous sont indispensables
(matriser parfaitement les templates,
Personne ne maîtrise parfaitement les templates.
RAII et tous les termes compliques que je ne connais pas qui vont avec...)?
Ta question ressemble un peu à "J'ai bien compris que pour faire un bon livre, il faut un scénario, des personnages intéressants, etc., mais ne faut-il pas d'abord connaître les mots de la langue française ?".
Il faut bien entendu connaître les bases et les pièges classiques du langage. Mais d'un autre côté, de même qu'un livre plein de mots compliqués sera difficile à lire, un code qui contient des "trucs" tordus sera moins lisible et moins fiable qu'un code qui ne contient que des méthodes "basiques", connues et fiables. Par exemple, ne pas savoir ce que fait exactement le code "delete this; this= new..." n'est pas bien grave, parce que c'est une méthode tordue qui (j'espère) n'est pas utilisée.
-- ;-)
On Tue, 01 Feb 2005 09:23:43 +0100, korchkidu <korch_ki_du@yahoo.fr>:
Mais n'y a t'il pas des concepts importants du C++ qui pour vous sont
indispensables
(matriser parfaitement les templates,
Personne ne maîtrise parfaitement les templates.
RAII et tous les
termes compliques que je ne connais pas qui vont avec...)?
Ta question ressemble un peu à "J'ai bien compris que pour faire un
bon livre, il faut un scénario, des personnages intéressants, etc.,
mais ne faut-il pas d'abord connaître les mots de la langue
française ?".
Il faut bien entendu connaître les bases et les pièges classiques du
langage.
Mais d'un autre côté, de même qu'un livre plein de mots compliqués
sera difficile à lire, un code qui contient des "trucs" tordus sera
moins lisible et moins fiable qu'un code qui ne contient que des
méthodes "basiques", connues et fiables. Par exemple, ne pas savoir ce
que fait exactement le code "delete this; this= new..." n'est pas bien
grave, parce que c'est une méthode tordue qui (j'espère) n'est pas
utilisée.
Mais n'y a t'il pas des concepts importants du C++ qui pour vous sont indispensables
(matriser parfaitement les templates,
Personne ne maîtrise parfaitement les templates.
RAII et tous les termes compliques que je ne connais pas qui vont avec...)?
Ta question ressemble un peu à "J'ai bien compris que pour faire un bon livre, il faut un scénario, des personnages intéressants, etc., mais ne faut-il pas d'abord connaître les mots de la langue française ?".
Il faut bien entendu connaître les bases et les pièges classiques du langage. Mais d'un autre côté, de même qu'un livre plein de mots compliqués sera difficile à lire, un code qui contient des "trucs" tordus sera moins lisible et moins fiable qu'un code qui ne contient que des méthodes "basiques", connues et fiables. Par exemple, ne pas savoir ce que fait exactement le code "delete this; this= new..." n'est pas bien grave, parce que c'est une méthode tordue qui (j'espère) n'est pas utilisée.
-- ;-)
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote: | > 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. | | À bon ? Et tu développe des applications de taille ? | | > J'utilise le tableau noir de BS. | | On peut y faire de l'UML aussi. Évidemment, à condition de ne | rien faire qui vaut la peine de garder:-).
Pardon ?
| Sérieusement, je suppose que tu parles des sessions de | « brainstorming », parce que la persistence du tableau noir | n'est pas particulièrement bonne.
Parce que la conception n'est pas du « brainstorming » ?
Au cas où, tu ne le saurais pas, il y a des moyens autres que UML de rendre les choses persistantes. Des appareils photonumériques, par exemple (je ne rigole pas), et j'en passe.
| > Quand je suis seul, j'utilise un papier et un crayon. | | Que tu gardes soigneusement quelque part, j'espère, pourque tes | idées ne se perdent pas, et qu'elles puissent servir aux autres.
Je garde la plupart d'entre elles -- cela devient du UML tout d'un coup ?
| Je ne connais pas la contexte universitaire ; j'imagine que dans
Avant de venir à A&M, celui avec qui je travaille travaillait chez AT&T et ne faisait pas exactement de la recherche universitaire. Mais bon, hein.
| la récherche, il y a effectivement beaucoup d'idées qu'on jette | par la suite.
Ton imagination est alors probablement très limitée. Je ne sais pas si ceci explique cela.
| Mais moi, on me paie cher pour mes idées, et le | client s'estimera lesé si elles se perdaient comme ça.
Partirais-tu de l'axiome que UML est la seule manière de rendre persistante ses idées ? Après tu les mets sous forme XML ? Parce que sinon, hein c'est de l'escroquerie.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis wrote:
| > 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.
|
| À bon ? Et tu développe des applications de taille ?
|
| > J'utilise le tableau noir de BS.
|
| On peut y faire de l'UML aussi. Évidemment, à condition de ne
| rien faire qui vaut la peine de garder:-).
Pardon ?
| Sérieusement, je suppose que tu parles des sessions de
| « brainstorming », parce que la persistence du tableau noir
| n'est pas particulièrement bonne.
Parce que la conception n'est pas du « brainstorming » ?
Au cas où, tu ne le saurais pas, il y a des moyens autres que
UML de rendre les choses persistantes. Des appareils photonumériques,
par exemple (je ne rigole pas), et j'en passe.
| > Quand je suis seul, j'utilise un papier et un crayon.
|
| Que tu gardes soigneusement quelque part, j'espère, pourque tes
| idées ne se perdent pas, et qu'elles puissent servir aux autres.
Je garde la plupart d'entre elles -- cela devient du UML tout d'un
coup ?
| Je ne connais pas la contexte universitaire ; j'imagine que dans
Avant de venir à A&M, celui avec qui je travaille travaillait chez AT&T
et ne faisait pas exactement de la recherche universitaire. Mais bon,
hein.
| la récherche, il y a effectivement beaucoup d'idées qu'on jette
| par la suite.
Ton imagination est alors probablement très limitée. Je ne sais pas si
ceci explique cela.
| Mais moi, on me paie cher pour mes idées, et le
| client s'estimera lesé si elles se perdaient comme ça.
Partirais-tu de l'axiome que UML est la seule manière de rendre
persistante ses idées ? Après tu les mets sous forme XML ? Parce que
sinon, hein c'est de l'escroquerie.
| Gabriel Dos Reis wrote: | > 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. | | À bon ? Et tu développe des applications de taille ? | | > J'utilise le tableau noir de BS. | | On peut y faire de l'UML aussi. Évidemment, à condition de ne | rien faire qui vaut la peine de garder:-).
Pardon ?
| Sérieusement, je suppose que tu parles des sessions de | « brainstorming », parce que la persistence du tableau noir | n'est pas particulièrement bonne.
Parce que la conception n'est pas du « brainstorming » ?
Au cas où, tu ne le saurais pas, il y a des moyens autres que UML de rendre les choses persistantes. Des appareils photonumériques, par exemple (je ne rigole pas), et j'en passe.
| > Quand je suis seul, j'utilise un papier et un crayon. | | Que tu gardes soigneusement quelque part, j'espère, pourque tes | idées ne se perdent pas, et qu'elles puissent servir aux autres.
Je garde la plupart d'entre elles -- cela devient du UML tout d'un coup ?
| Je ne connais pas la contexte universitaire ; j'imagine que dans
Avant de venir à A&M, celui avec qui je travaille travaillait chez AT&T et ne faisait pas exactement de la recherche universitaire. Mais bon, hein.
| la récherche, il y a effectivement beaucoup d'idées qu'on jette | par la suite.
Ton imagination est alors probablement très limitée. Je ne sais pas si ceci explique cela.
| Mais moi, on me paie cher pour mes idées, et le | client s'estimera lesé si elles se perdaient comme ça.
Partirais-tu de l'axiome que UML est la seule manière de rendre persistante ses idées ? Après tu les mets sous forme XML ? Parce que sinon, hein c'est de l'escroquerie.
| writes: | | > Sérieusement, je suppose que tu parles des sessions de | > « brainstorming », parce que la persistence du tableau noir | > n'est pas particulièrement bonne. | | Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
| kanze@gabi-soft.fr writes:
|
| > Sérieusement, je suppose que tu parles des sessions de
| > « brainstorming », parce que la persistence du tableau noir
| > n'est pas particulièrement bonne.
|
| Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
| writes: | | > Sérieusement, je suppose que tu parles des sessions de | > « brainstorming », parce que la persistence du tableau noir | > n'est pas particulièrement bonne. | | Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
Comment as-tu deviné ?
-- Gaby
Matthieu Moy
Gabriel Dos Reis writes:
Matthieu Moy writes:
| writes: | | > Sérieusement, je suppose que tu parles des sessions de | > « brainstorming », parce que la persistence du tableau noir | > n'est pas particulièrement bonne. | | Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
Comment as-tu deviné ?
Pour l'instant, ma these est en jpeg, faut que je convertisse ça en LaTeX, ça fera plus propre ...
-- Matthieu
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| kanze@gabi-soft.fr writes:
|
| > Sérieusement, je suppose que tu parles des sessions de
| > « brainstorming », parce que la persistence du tableau noir
| > n'est pas particulièrement bonne.
|
| Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
Comment as-tu deviné ?
Pour l'instant, ma these est en jpeg, faut que je convertisse ça en
LaTeX, ça fera plus propre ...
| writes: | | > Sérieusement, je suppose que tu parles des sessions de | > « brainstorming », parce que la persistence du tableau noir | > n'est pas particulièrement bonne. | | Tu dis ça parce que t'as pas d'appareil photo numérique. ;-)
Comment as-tu deviné ?
Pour l'instant, ma these est en jpeg, faut que je convertisse ça en LaTeX, ça fera plus propre ...
-- Matthieu
Olivier Azeau
wrote:
Olivier Azeau wrote:
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.
Est-ce qu'on peut trop tardé à écrire du code ? En général, plus on rétard à écrire du code, plus le projet est fini vite.
Parce qu'il est annule pour manque de résultat tangible ?
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.
Et ça leur avancerait à quoi ? À savoir ce qu'ils ont fait n'était pas juste ?
C'est un bon début, non ?
Ça ressemble un peu l'histoire des millions de singes qui tappent au hazard au clavier, pour écrire Shakespeare.
Personne n'a parlé de coder au hasard (c'est a dire sans savoir ce que l'on veut coder). Il est juste question de vérifier le plus tot possible que ce que l'on a imaginé fonctionne réellement.
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.
Le problème, chez nous, c'est que ce n'est pas toujours évident quand ça « crashe ». Un programme peut bien semblait fonctionner, mais comporter des erreurs graves quand même.
Raison de plus pour tenter le plus de crash test possible dans toutes les conditions imaginables (contre un mur, contre un arbre, sous la pluie, sur la neige...)
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-...
Personne n'a rien dit contre des itérations rapprochées. Tout ce qu'on discute, c'est comment faire une itération.
Itérativement !
kanze@gabi-soft.fr wrote:
Olivier Azeau wrote:
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.
Est-ce qu'on peut trop tardé à écrire du code ? En général, plus
on rétard à écrire du code, plus le projet est fini vite.
Parce qu'il est annule pour manque de résultat tangible ?
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.
Et ça leur avancerait à quoi ? À savoir ce qu'ils ont fait
n'était pas juste ?
C'est un bon début, non ?
Ça ressemble un peu l'histoire des millions de singes qui
tappent au hazard au clavier, pour écrire Shakespeare.
Personne n'a parlé de coder au hasard (c'est a dire sans savoir ce que
l'on veut coder). Il est juste question de vérifier le plus tot
possible que ce que l'on a imaginé fonctionne réellement.
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.
Le problème, chez nous, c'est que ce n'est pas toujours évident
quand ça « crashe ». Un programme peut bien semblait
fonctionner, mais comporter des erreurs graves quand même.
Raison de plus pour tenter le plus de crash test possible dans toutes
les conditions imaginables (contre un mur, contre un arbre, sous la
pluie, sur la neige...)
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-...
Personne n'a rien dit contre des itérations rapprochées. Tout ce
qu'on discute, c'est comment faire une itération.
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.
Est-ce qu'on peut trop tardé à écrire du code ? En général, plus on rétard à écrire du code, plus le projet est fini vite.
Parce qu'il est annule pour manque de résultat tangible ?
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.
Et ça leur avancerait à quoi ? À savoir ce qu'ils ont fait n'était pas juste ?
C'est un bon début, non ?
Ça ressemble un peu l'histoire des millions de singes qui tappent au hazard au clavier, pour écrire Shakespeare.
Personne n'a parlé de coder au hasard (c'est a dire sans savoir ce que l'on veut coder). Il est juste question de vérifier le plus tot possible que ce que l'on a imaginé fonctionne réellement.
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.
Le problème, chez nous, c'est que ce n'est pas toujours évident quand ça « crashe ». Un programme peut bien semblait fonctionner, mais comporter des erreurs graves quand même.
Raison de plus pour tenter le plus de crash test possible dans toutes les conditions imaginables (contre un mur, contre un arbre, sous la pluie, sur la neige...)
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-...
Personne n'a rien dit contre des itérations rapprochées. Tout ce qu'on discute, c'est comment faire une itération.
Itérativement !
Olivier Azeau
Fabien LE LEZ wrote:
On 31 Jan 2005 08:05:57 -0800, "Olivier Azeau" :
Par exemple, [12h46 ; 13h01].
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)
Non.
Ah bon ?
Fabien LE LEZ wrote:
On 31 Jan 2005 08:05:57 -0800, "Olivier Azeau" <ransom@xasamail.com>:
Par exemple, [12h46 ; 13h01].
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)
Non.
Ah bon ?
Olivier Azeau
wrote:
Olivier Azeau wrote:
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.
Pourquoi ? Si la première conception a été bien faite, on pourrait en ajouter des fonctionalités sans problèmes. Ce qu'il ne faut pas, c'est d'en changer.
On est quand même bien obligé de modifier certains comportements non ?
[...]
En fait, la plupart des technologies de processus dont je me sers ont été développées pour des systèmes critiques, où le moindre erreur n'est pas acceptable. Le but du processus, c'était constamment de réduire le taux d'erreurs, coût que coût. Et on les a introduit la première fois que je les ai vu précisement pour ça -- la qualité n'avait pas de prix. Imagine notre surprise alors quand on a découvert que le prix du développement s'était baissé aussi -- la qualité est gratuite.
J'ai lu des choses intéressantes sur ce sujet dans "Peopleware" Je pense aussi que "la qualité est gratuite pour tous ceux qui sont prêts à en payer le prix", le tout est de savoir comment on approche la qualité. Pour moi, c'est payer le prix des "tests le plus tôt possible" pour pouvoir affiner rapidement conception et code.
[...}
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...
Ils l´etaient, en quelque sort. Qu'est-ce que ça change ?
Tout. Cela permet d'organiser un relation client-fournisseur pour définir les objectifs du projet, définir les cas d'utilisation, formaliser le feedback des utilisateurs... Tout cela me semble beaucoup plus important que de savoir à quelle heure on conçoit, à quelle heure on code et à quelle heure on teste.
kanze@gabi-soft.fr wrote:
Olivier Azeau wrote:
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.
Pourquoi ? Si la première conception a été bien faite, on
pourrait en ajouter des fonctionalités sans problèmes. Ce qu'il
ne faut pas, c'est d'en changer.
On est quand même bien obligé de modifier certains comportements non ?
[...]
En fait, la plupart des technologies de processus dont je me
sers ont été développées pour des systèmes critiques, où le
moindre erreur n'est pas acceptable. Le but du processus,
c'était constamment de réduire le taux d'erreurs, coût que coût.
Et on les a introduit la première fois que je les ai vu
précisement pour ça -- la qualité n'avait pas de prix. Imagine
notre surprise alors quand on a découvert que le prix du
développement s'était baissé aussi -- la qualité est gratuite.
J'ai lu des choses intéressantes sur ce sujet dans "Peopleware"
Je pense aussi que "la qualité est gratuite pour tous ceux qui sont
prêts à en payer le prix", le tout est de savoir comment on approche la
qualité. Pour moi, c'est payer le prix des "tests le plus tôt possible"
pour pouvoir affiner rapidement conception et code.
[...}
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...
Ils l´etaient, en quelque sort. Qu'est-ce que ça change ?
Tout.
Cela permet d'organiser un relation client-fournisseur pour définir les
objectifs du projet, définir les cas d'utilisation, formaliser le
feedback des utilisateurs...
Tout cela me semble beaucoup plus important que de savoir à quelle heure
on conçoit, à quelle heure on code et à quelle heure on teste.
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.
Pourquoi ? Si la première conception a été bien faite, on pourrait en ajouter des fonctionalités sans problèmes. Ce qu'il ne faut pas, c'est d'en changer.
On est quand même bien obligé de modifier certains comportements non ?
[...]
En fait, la plupart des technologies de processus dont je me sers ont été développées pour des systèmes critiques, où le moindre erreur n'est pas acceptable. Le but du processus, c'était constamment de réduire le taux d'erreurs, coût que coût. Et on les a introduit la première fois que je les ai vu précisement pour ça -- la qualité n'avait pas de prix. Imagine notre surprise alors quand on a découvert que le prix du développement s'était baissé aussi -- la qualité est gratuite.
J'ai lu des choses intéressantes sur ce sujet dans "Peopleware" Je pense aussi que "la qualité est gratuite pour tous ceux qui sont prêts à en payer le prix", le tout est de savoir comment on approche la qualité. Pour moi, c'est payer le prix des "tests le plus tôt possible" pour pouvoir affiner rapidement conception et code.
[...}
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...
Ils l´etaient, en quelque sort. Qu'est-ce que ça change ?
Tout. Cela permet d'organiser un relation client-fournisseur pour définir les objectifs du projet, définir les cas d'utilisation, formaliser le feedback des utilisateurs... Tout cela me semble beaucoup plus important que de savoir à quelle heure on conçoit, à quelle heure on code et à quelle heure on teste.
kanze
Olivier Azeau wrote:
wrote:
Olivier Azeau wrote:
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.
Pourquoi ? Si la première conception a été bien faite, on pourrait en ajouter des fonctionalités sans problèmes. Ce qu'il ne faut pas, c'est d'en changer.
On est quand même bien obligé de modifier certains comportements non ?
Lesquels ? Ou plutôt pourquoi ? Je ne suis pas sÛr d'avoir compris où tu veux en venir. En général, on évite de modifier le comportement d'une fonction existante ; on en ajoute une, plutôt.
Mais ce n'est pas une règle absolue. À la fin, il s'agit toujours d'une question de prix. Modifier tous les utilisateurs a un certain prix, on le fait que si ça rapporte plus que ça ne coûte.
[...}
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...
Ils l´etaient, en quelque sort. Qu'est-ce que ça change ?
Tout. Cela permet d'organiser un relation client-fournisseur pour définir les objectifs du projet, définir les cas d'utilisation, formaliser le feedback des utilisateurs... Tout cela me semble beaucoup plus important que de savoir à quelle heure on conçoit, à quelle heure on code et à quelle heure on teste.
Tout à fait.
En fait, le plus important, c'est d'avoir un processus, et de le savoir. Par la suite, on peut le modifier ou non, comme on veut, et on peut en mésurer l'effet des modifications. Tandis que sans processus, où chacun fait ce qui lui plaît...
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Olivier Azeau wrote:
kanze@gabi-soft.fr wrote:
Olivier Azeau wrote:
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.
Pourquoi ? Si la première conception a été bien faite, on
pourrait en ajouter des fonctionalités sans problèmes. Ce
qu'il ne faut pas, c'est d'en changer.
On est quand même bien obligé de modifier certains
comportements non ?
Lesquels ? Ou plutôt pourquoi ? Je ne suis pas sÛr d'avoir
compris où tu veux en venir. En général, on évite de modifier le
comportement d'une fonction existante ; on en ajoute une,
plutôt.
Mais ce n'est pas une règle absolue. À la fin, il s'agit
toujours d'une question de prix. Modifier tous les utilisateurs
a un certain prix, on le fait que si ça rapporte plus que ça ne
coûte.
[...}
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...
Ils l´etaient, en quelque sort. Qu'est-ce que ça change ?
Tout.
Cela permet d'organiser un relation client-fournisseur pour
définir les objectifs du projet, définir les cas
d'utilisation, formaliser le feedback des utilisateurs... Tout
cela me semble beaucoup plus important que de savoir à quelle
heure on conçoit, à quelle heure on code et à quelle heure on
teste.
Tout à fait.
En fait, le plus important, c'est d'avoir un processus, et de le
savoir. Par la suite, on peut le modifier ou non, comme on veut,
et on peut en mésurer l'effet des modifications. Tandis que sans
processus, où chacun fait ce qui lui plaît...
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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.
Pourquoi ? Si la première conception a été bien faite, on pourrait en ajouter des fonctionalités sans problèmes. Ce qu'il ne faut pas, c'est d'en changer.
On est quand même bien obligé de modifier certains comportements non ?
Lesquels ? Ou plutôt pourquoi ? Je ne suis pas sÛr d'avoir compris où tu veux en venir. En général, on évite de modifier le comportement d'une fonction existante ; on en ajoute une, plutôt.
Mais ce n'est pas une règle absolue. À la fin, il s'agit toujours d'une question de prix. Modifier tous les utilisateurs a un certain prix, on le fait que si ça rapporte plus que ça ne coûte.
[...}
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...
Ils l´etaient, en quelque sort. Qu'est-ce que ça change ?
Tout. Cela permet d'organiser un relation client-fournisseur pour définir les objectifs du projet, définir les cas d'utilisation, formaliser le feedback des utilisateurs... Tout cela me semble beaucoup plus important que de savoir à quelle heure on conçoit, à quelle heure on code et à quelle heure on teste.
Tout à fait.
En fait, le plus important, c'est d'avoir un processus, et de le savoir. Par la suite, on peut le modifier ou non, comme on veut, et on peut en mésurer l'effet des modifications. Tandis que sans processus, où chacun fait ce qui lui plaît...
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
