Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Supression d'un élément d'une map

Supression d'un élément d'une map

35 réponses
Avatar
Michaël Delva
Bonsoir à tous,

voici ma question:

j'ai la map suivante:

std::map<AnsiString,DS_Edit_Video*> map;

Je la remplis comme ceci:

map[nom_cle] = new DS_Edit_Video;

Avant de la remplir, je veux la vider de certains éléments:

for (int i=0; i < nbre_joueurs; i++)
{
AnsiString nom_cle = Liste_Joueurs->Items->Strings[i];
it ite = timelines_joueurs.fin(nom_cle);

if (ite != timelines_joueurs.end())
{
delete ite->second;
timelines_joueurs.erase(ite);
}
}

est-ce nécessaire de passer par un delete ite->second, ou bien est-ce que
la ligne qui suit le fait également?

Merci d'avance...
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
James Kanze
(Laurent Bossavit) writes:

|> > |> > intéressé à d'autres choses, et il s'occupe
|> > |> > beaucoup plus de l'« extreme programming » que
|> > |> > d'autres choses actuellement (bien que sa site,
|> > |> > www.objectmentor.com, suggère une activité actuelle
|> > |> > dans le C++ et l'orientation objet).

|> > |> Au fait, quelqu'un en connait-il un peu plus sur l'«
|> > |> Agile Software Development » ?

|> > Je suis un peu sceptique. Du peu que j'ai vu (mais c'est très
|> > peu), c'est un remballage de la programmation extrème :
|> > c-à-d surtout une prise de leurs souhaits pour la réalité
|> > par des développeurs.

|> Ca me semble un peu rapide comme procès. Pour ceux que ça
|> intérese, je conseille (en toute partialité, étant
|> co-auteur) l'ouvrage de référence suivant, en français:

Je n'ai pas régardé en détail le « Agile Software
Development ». J'ai bien régardé l'« Extreme Programming »,
en revanche. Ce n'est pas complètement mauvais, mais d'après ce
que j'ai vu, les bonnes idées, c'était des choses qu'on
connaissait déjà depuis 20 ans, mais que beaucoup de boîtes
n'appliquaient toujours pas. Si l'étiquette « Extreme programming »
aide à faire accepter ce que les spécialistes du génie logiciel
préconsisent depuis des années, tant mieux. Mais c'est le seul
intérêt que j'y vois.

|> "Extreme Programming, avec 2 études de cas", ed. Eyrolles
|> Bénard, Bossavit, Medina, Willliams
|> http://www.amazon.fr/exec/obidos/ASIN/2212110510/

|> > En revanche, dire que les tests remplacent la documentation ou la
|> > spécification externe, c'est prendre ses souhaits pour la
|> > réalité.

|> Qu'est-ce que les développeurs souhaitent, selon toi, et que la
|> logique "les tests sont de la documentation (ou de la
|> spécification)" promettrait de faire réalité ?

Le souhait, c'est de ne pas écrire de la documentation externe.
L'« extreme programmation » semble en donner une justification.
Or, si tu ne sais pas ce que ton programme doit faire avant de commencer
à l'écrire, c'est foutu d'avance. Et si tu ne sais pas l'exprimer
en français, tu ne sais pas ce qu'il doit faire. Il y a beaucoup de
chose qui ne se laisse pas définir au moyen d'un programme de test.
(Et il y a beaucoup d'utilisateurs qui ne saurait pas dire ce qu'un
programme de test spécifie.)

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Avatar
Laurent Bossavit
(Croisé et redirigé sur fr.comp.developpement)

|> Qu'est-ce que les développeurs souhaitent, selon toi, et que la
|> logique "les tests sont de la documentation (ou de la
|> spécification)" promettrait de faire réalité ?

Le souhait, c'est de ne pas écrire de la documentation externe.
L'« extreme programmation » semble en donner une justification.


Je ne pense pas que les développeurs refusent en bloc d'écrire de la
documentation. La catégorie "documentation" est trop vaste pour pouvoir
l'affirmer !

J'ai une hypothèse pour expliquer cette idée très répandue que les
développeurs n'aiment pas écrire de la doc. Elle s'énonce très
simplement: les développeurs n'aiment pas baratiner.

Or, les développeurs ont une conscience aigue, en début de projet
notamment, des lacunes qui peuvent exister dans l'expression des besoins,
dans l'architecture proposée pour répondre à ces besoins, ou dans les
principes de conception proposés pour implémenter l'architecture. Mais
exprimer ces doutes dans un document "officiel", c'est être exposé à des
critiques. "C'est ton métier de t'assurer que le serveur Bidule peut
encaisser plus de 10,000 connexions simultanées." Beaucoup de managers
ressentent tout manque de confiance comme un "esprit négatif", et ont
tendance à faire ce type de critiques.

Or, si tu ne sais pas ce que ton programme doit faire avant de commencer
à l'écrire, c'est foutu d'avance.


Nous sommes d'accord là-dessus. Le premier devoir du développeur est donc
de *demander* ce que le programme doit faire, de savoir écouter un client
qui le lui explique, et de savoir orienter la conversation pour qu'elle
produise une information qu'il saura exploiter.

J'ai vu trop de cas où on met un jeune développeur, récemment promu chef
de projet, face à un client pour la première fois, en lui demandant après
une heure d'entretien de rédiger un cahier des charges de 50 pages. Le
"ce que ça doit faire" résulte avant tout d'une conversation avec la
maîtrise d'ouvrage. Si on met plus de temps à rédiger le bilan de cette
conversation qu'on en a mis à avoir la conversation, on est en train
d'inventer.

Et si tu ne sais pas l'exprimer en français, tu ne sais pas ce qu'il doit faire.


Encore d'accord. Le client doit savoir exprimer ce qu'il attend du
programme; le développeur doit savoir exprimer ce que fera le programme
pour répondre à cette attente; le client doit savoir valider cette
expression de solution.

J'ajoute que le français est une langue imprécise et ambigue. Pour
évacuer cette ambiguité, il faut formaliser ce qui permettra au client de
se déclarer satisfait du programme livré. Ce formalisme, c'est un test:
pas nécessairement, à ce stade, un test exécutable, automatisé, mais un
test au sens "Je vais effectuer telle et telle opération, et attendre tel
et tel résultat en fonction des données présentes dans le système."

Il y a beaucoup de chose qui ne se laisse pas définir au moyen d'un
programme de test.


Et il y a beaucoup de choses qui s'y prètent très bien.

De façon générale, on peut dire que tout ce qui n'est pas formalisable
par un test (au sens général du terme) n'est pas vérifiable. Si je ne
suis pas capable d'expliquer comment je compte m'y prendre pour vérifier
que le programme fait ce que je veux, comme tu le disais ci-dessus "c'est
foutu d'avance".

Dans le cas général, si je suis capable d'expliquer comment je vais m'y
prendre pour vérifier que le programme marche, une personne compétente
peut en faire un test automatisé.

(Et il y a beaucoup d'utilisateurs qui ne saurait pas dire ce qu'un
programme de test spécifie.)


S'il est écrit en C ou en Java, qui ne sont pas prévus pour ça, c'est
sans doute vrai. On peut utiliser d'autres notations, plus familières aux
utilisateurs. Je connais des gens qui recommandent Excel comme une
notation "universelle" susceptible d'être comprise par toutes les
maîtrises d'ouvrage, et qui en ont fait un outil de test utilisable en
XP:
http://fit.c2.com/wiki.cgi?WelcomeVisitors
http://fitnesse.org/

Il y a plus d'avenir qu'on ne le pense à la production par les
développeurs de documentation *réellement* utile...

Laurent
http://bossavit.com/
http://bossavit.com/thoughts/

Avatar
kanze
Laurent Bossavit wrote in message
news:...
(Croisé et redirigé sur fr.comp.developpement)

|> Qu'est-ce que les développeurs souhaitent, selon toi, et que la
|> logique "les tests sont de la documentation (ou de la
|> spécification)" promettrait de faire réalité ?

Le souhait, c'est de ne pas écrire de la documentation externe. L'«
extreme programmation » semble en donner une justification.


Je ne pense pas que les développeurs refusent en bloc d'écrire de la
documentation.


Réfuser, peut-être pas, mais la plupart des développeurs que j'ai connu
préfère écrire du code, et certains éviter la documentation comme de la
peste. Je ne dis pas que tout le tort c'est de leur côté. Parfois, la
documentation qu'on nous démandait était réelement rébarbative et sans
intérêt. Mais dans l'ensemble, prèsque tous les développeurs (moi-même
compris) semblent préférer écrire du code que du français ou de
l'anglais.

La catégorie "documentation" est trop vaste pour pouvoir l'affirmer !

J'ai une hypothèse pour expliquer cette idée très répandue que les
développeurs n'aiment pas écrire de la doc. Elle s'énonce très
simplement: les développeurs n'aiment pas baratiner.

Or, les développeurs ont une conscience aigue, en début de projet
notamment, des lacunes qui peuvent exister dans l'expression des
besoins, dans l'architecture proposée pour répondre à ces besoins, ou
dans les principes de conception proposés pour implémenter
l'architecture. Mais exprimer ces doutes dans un document "officiel",
c'est être exposé à des critiques. "C'est ton métier de t'assurer que
le serveur Bidule peut encaisser plus de 10,000 connexions
simultanées." Beaucoup de managers ressentent tout manque de confiance
comme un "esprit négatif", et ont tendance à faire ce type de
critiques.


Ce n'est pas parce qu'on ne connaît pas tout ce qu'il ne faut pas mettre
par écrit ce qu'on connaît. Au contraire -- tant que ce n'est pas écrit,
je dirais qu'on ne le connaît pas réelement. Et je n'ai jamais
expérimenté une critique quand j'ai dit qu'on ne savait pas encore. Ce
n'est qu'une fois la manque de savoir exprimée que les managers peuvent
en faire quelque chose.

J'avoue là que mon expérience n'est peut-être pas typique. J'en entends
trop des expériences différentes pour en douter de leurs existence. Mais
ça ne change pas grand chose au problème. Que faire ce qu'il faut te
n'apporte que de critiques ne change pas que c'est ce qu'il faut.

Or, si tu ne sais pas ce que ton programme doit faire avant de
commencer à l'écrire, c'est foutu d'avance.


Nous sommes d'accord là-dessus. Le premier devoir du développeur est
donc de *demander* ce que le programme doit faire, de savoir écouter
un client qui le lui explique, et de savoir orienter la conversation
pour qu'elle produise une information qu'il saura exploiter.


C'est en effet la toute première démarche. Et la deuxième, qui en fait
pratiquement partie, c'est mettre noir sur blanc ce qu'il a compris,
pour être sûr que l'autre a compris la même chose.

J'ai vu trop de cas où on met un jeune développeur, récemment promu
chef de projet, face à un client pour la première fois, en lui
demandant après une heure d'entretien de rédiger un cahier des charges
de 50 pages. Le "ce que ça doit faire" résulte avant tout d'une
conversation avec la maîtrise d'ouvrage. Si on met plus de temps à
rédiger le bilan de cette conversation qu'on en a mis à avoir la
conversation, on est en train d'inventer.


Pas forcement. Si on connaît un peu le domaine du « client », on sait
comprendre ce dont il a besoin au démi mot. Ensuite, on l'écrit en
détail, et on lui fait lire, pour qu'il confirme qu'on a bien compris.

Ceci vaut à l'intérieur du projet aussi. Le « client », c'est les autres
développeurs, qui vont interfacer avec ce que nous faisons.

Et finallement, ce que veut le client, ce n'est pas forcement assez
détailler pour commencer quoique ce soit. Prenons un cas concret : on me
démande une bibliothèque de communication entre deux machines. Ce que me
dit mon client, c'est à peu près les types d'informations qu'il faut
communiquer, dans quelle quantité et dans quelle circumstances. Pour la
reste, il me fait confidance -- il ne veut même pas savoir. N'empêche
que sans avoir défini le protocol en détail (est-ce que je transmets les
entiers gros-boutien, petit-boutien ou en texte, etc.), je n'écris pas
une seule ligne de code.

Aussi, dans mon travail (mais je ne crois pas que ce soit universel), on
me réfère souvent à des documents de normalisation. Pour en donner une
idée, considère GB_Format (que tu peux voir à ma site). Tout ce que le
client m'a démandé, c'était une possibilité « type safe » d'utiliser un
formattage à la printf et les extensions Open System, avec les flux
standard de C++. C'est un peu vague, mais puisque je connaissais déjà
printf et les extensions Open System, ça m'a suffit pour commencer. Et
pour plus de 450 lignes de spécificatioin (qui font actuellement le
commentaire en-tête de Format.hh). Qui était écrit avant que j'ai
commencé même à réflechir sur l'organisation des classes, etc. Et qui
ont évolué, au fur et à mésure que je comprenais ce qui était possible,
et ce qui posait plus de problèmes.

Et si tu ne sais pas l'exprimer en français, tu ne sais pas ce qu'il
doit faire.


Encore d'accord. Le client doit savoir exprimer ce qu'il attend du
programme; le développeur doit savoir exprimer ce que fera le
programme pour répondre à cette attente; le client doit savoir valider
cette expression de solution.


Tout à fait. Y compris quand le « client », c'est les autres
développeurs. La communication est essentielle, et on n'est jamais sûr
qu'elle a bien passé (et que le résultat n'en sera pas oublié) sans
qu'elle soit écrite.

J'ajoute que le français est une langue imprécise et ambigue.


C'est vrai, et ce n'est pas vrai. Le français est un outil issu des
siècles de raffinement et de développement. Par nature, il remplit
beaucoup de conditions : il peut être aussi imprécis et ambigu qu'on
veut, quand on récherche l'imprécision et l'ambiguïté (comme dans
beaucoup de poësie, par exemple). Mais il peut aussi être extrèmement
précis quand on veut, et qu'on sait le manier.

Pour évacuer cette ambiguité, il faut formaliser ce qui permettra au
client de se déclarer satisfait du programme livré. Ce formalisme,
c'est un test: pas nécessairement, à ce stade, un test exécutable,
automatisé, mais un test au sens "Je vais effectuer telle et telle
opération, et attendre tel et tel résultat en fonction des données
présentes dans le système."


Je ne sais pas si j'ai bien compris.

Est-ce que tu es en train de dire simplement qu'une spécification n'a
d'intérêt que si elle est vérifiable ? Je ne serais pas tout à fait
d'accord (comment vérifier que le framework GUI que j'ai fait est «
ergonomique »), mais passons. Parce que ce n'est pas ce que disent la
plupart des avocats de l'« extreme programming ».

Ou est-ce que tu argues encore dans la direction des tests classiques,
avec simplement la nuance qu'il suffit de le spécifier dans un premier
temps, et non de le coder ?

Il y a beaucoup de chose qui ne se laisse pas définir au moyen d'un
programme de test.


Et il y a beaucoup de choses qui s'y prètent très bien.


Il en y a quelques un, mais il y en a bien plus qui ne s'y prètent pas.
Par exemple, dans prèsque tous mes projets, du fait que je suis externe
à la boîte, il y a une exigence que le code soit lisible, et
compréhensible des autres, pour qu'ils puissent s'assurer la maintenance
après que je suis parti. Comment écris-tu un test pour ça ?

Plus généralement, le fait qu'on peut tester quelque chose n'est pas
forcement le meilleur moyen de le documenter. Si, dans un protocol, je
décide d'envoyer les entiers en binaire, poids fort d'abord (format
Internet), c'est facile à tester. N'empêche que si tu dois maintenir le
code, il faut que tu comprends ce qui se passe sur la ligne, et pour ça,
une phrase (format Internet binaire) est beaucoup plus facile qu'un
programme de test.

De façon générale, on peut dire que tout ce qui n'est pas formalisable
par un test (au sens général du terme) n'est pas vérifiable. Si je ne
suis pas capable d'expliquer comment je compte m'y prendre pour
vérifier que le programme fait ce que je veux, comme tu le disais
ci-dessus "c'est foutu d'avance".


Pas pour tout, mais j'accepte la principe en général. Mais c'est une
exigence sur la claireté et la précision de la documentation. Et c'est
loin de ce que disent Fowler, Martin et al. Plusieurs l'ont déjà dit en
comp.lang.c++.moderated : avant d'écrire une ligne de code de
l'application, on écrit un programme qui le teste.

Or, d'une part, il faut que d'autres puissent lire les spécifications,
et confirmer qu'elles correspondent à ce qu'on veut, et qu'elles sont
complète. La plupart des utilisateurs ne saurait lire un programme de
test, et même quand les utilisateurs sont des autres programmeurs, et
sauraient le lire, ce n'est pas d'une lecture facile. Et de l'autre, il
y a bien des conditions qu'on ne saurait pas tester, ou qu'on ne saurait
pas tester d'une façon facile.

Dans le cas général, si je suis capable d'expliquer comment je vais
m'y prendre pour vérifier que le programme marche, une personne
compétente peut en faire un test automatisé.

(Et il y a beaucoup d'utilisateurs qui ne saurait pas dire ce qu'un
programme de test spécifie.)


S'il est écrit en C ou en Java, qui ne sont pas prévus pour ça, c'est
sans doute vrai. On peut utiliser d'autres notations, plus familières
aux utilisateurs. Je connais des gens qui recommandent Excel comme une
notation "universelle" susceptible d'être comprise par toutes les
maîtrises d'ouvrage, et qui en ont fait un outil de test utilisable en
XP:
http://fit.c2.com/wiki.cgi?WelcomeVisitors
http://fitnesse.org/

Il y a plus d'avenir qu'on ne le pense à la production par les
développeurs de documentation *réellement* utile...


Je ne nie pas l'intérêt des langages plus formel (du genre Excel) pour
la spécification de certaines parties du programme. Je ne crois pas pour
autant que le français ou l'anglais vont perdre leur importance, et
j'exigerais toujours à un programmeur non seulement une bonne
connaissance de l'informatique et du langage qu'il utilise, mais aussi
une bonne maîtrise de la langue de communication du projet. Et de la
documentation écrite.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16


Avatar
Laurent DELEPINE
wrote:
Laurent Bossavit wrote in message
news:...

(Croisé et redirigé sur fr.comp.developpement)



|> Qu'est-ce que les développeurs souhaitent, selon toi, et que la
|> logique "les tests sont de la documentation (ou de la
|> spécification)" promettrait de faire réalité ?




Le souhait, c'est de ne pas écrire de la documentation externe. L'«
extreme programmation » semble en donner une justification.




Je ne pense pas que les développeurs refusent en bloc d'écrire de la
documentation.



Réfuser, peut-être pas, mais la plupart des développeurs que j'ai connu
préfère écrire du code, et certains éviter la documentation comme de la
peste. Je ne dis pas que tout le tort c'est de leur côté. Parfois, la
documentation qu'on nous démandait était réelement rébarbative et sans
intérêt. Mais dans l'ensemble, prèsque tous les développeurs (moi-même
compris) semblent préférer écrire du code que du français ou de
l'anglais.


La catégorie "documentation" est trop vaste pour pouvoir l'affirmer !



J'ai une hypothèse pour expliquer cette idée très répandue que les
développeurs n'aiment pas écrire de la doc. Elle s'énonce très
simplement: les développeurs n'aiment pas baratiner.



Or, les développeurs ont une conscience aigue, en début de projet
notamment, des lacunes qui peuvent exister dans l'expression des
besoins, dans l'architecture proposée pour répondre à ces besoins, ou
dans les principes de conception proposés pour implémenter
l'architecture. Mais exprimer ces doutes dans un document "officiel",
c'est être exposé à des critiques. "C'est ton métier de t'assurer que
le serveur Bidule peut encaisser plus de 10,000 connexions
simultanées." Beaucoup de managers ressentent tout manque de confiance
comme un "esprit négatif", et ont tendance à faire ce type de
critiques.



Ce n'est pas parce qu'on ne connaît pas tout ce qu'il ne faut pas mettre
par écrit ce qu'on connaît. Au contraire -- tant que ce n'est pas écrit,
je dirais qu'on ne le connaît pas réelement. Et je n'ai jamais
expérimenté une critique quand j'ai dit qu'on ne savait pas encore. Ce
n'est qu'une fois la manque de savoir exprimée que les managers peuvent
en faire quelque chose.

J'avoue là que mon expérience n'est peut-être pas typique. J'en entends
trop des expériences différentes pour en douter de leurs existence. Mais
ça ne change pas grand chose au problème. Que faire ce qu'il faut te
n'apporte que de critiques ne change pas que c'est ce qu'il faut.


Or, si tu ne sais pas ce que ton programme doit faire avant de
commencer à l'écrire, c'est foutu d'avance.




Nous sommes d'accord là-dessus. Le premier devoir du développeur est
donc de *demander* ce que le programme doit faire, de savoir écouter
un client qui le lui explique, et de savoir orienter la conversation
pour qu'elle produise une information qu'il saura exploiter.



C'est en effet la toute première démarche. Et la deuxième, qui en fait
pratiquement partie, c'est mettre noir sur blanc ce qu'il a compris,
pour être sûr que l'autre a compris la même chose.


Ca c'est la cas ideal. Mais j'ai rencontré un paquet de clients qui ne
savaient pas ce qu'ils voulaient exactement et me disaient de faire a
mon idée pour exploiter au mieux le matériel qu'il venait d'acheter.
D'un autre coté, il est vrai que quand on branche un appareil de
numération sanguine a un ordinateur, il n'y a pas beaucoup de possibilités.


J'ai vu trop de cas où on met un jeune développeur, récemment promu
chef de projet, face à un client pour la première fois, en lui
demandant après une heure d'entretien de rédiger un cahier des charges
de 50 pages. Le "ce que ça doit faire" résulte avant tout d'une
conversation avec la maîtrise d'ouvrage. Si on met plus de temps à
rédiger le bilan de cette conversation qu'on en a mis à avoir la
conversation, on est en train d'inventer.



Pas forcement. Si on connaît un peu le domaine du « client », on sait
comprendre ce dont il a besoin au démi mot. Ensuite, on l'écrit en
détail, et on lui fait lire, pour qu'il confirme qu'on a bien compris.

Ceci vaut à l'intérieur du projet aussi. Le « client », c'est les autres
développeurs, qui vont interfacer avec ce que nous faisons.

Et finallement, ce que veut le client, ce n'est pas forcement assez
détailler pour commencer quoique ce soit. Prenons un cas concret : on me
démande une bibliothèque de communication entre deux machines. Ce que me
dit mon client, c'est à peu près les types d'informations qu'il faut
communiquer, dans quelle quantité et dans quelle circumstances. Pour la
reste, il me fait confidance -- il ne veut même pas savoir. N'empêche
que sans avoir défini le protocol en détail (est-ce que je transmets les
entiers gros-boutien, petit-boutien ou en texte, etc.), je n'écris pas
une seule ligne de code.


J'ai fait ca pendant 4 ans, et j'ai deja eu des description de protocole
assez speciale (style un post it avec deux ou trois lignes griffonées).
Quand le protocole n'etait pas carrément faux voire inconnu ("comment?
il se branche cet appareil? je ne savais meme pas") avec obligation de
brancher un ordinateur derriere la machine pour recuperer un exemple de
données transmises (une société dont je ne citerais pas le nom était
familiere de ce genre de chose). Et il n'y a qu'un seul appareil que je
n'ai pas reussi a brancher (sur 200).



LD



Avatar
kanze
Laurent DELEPINE wrote in message
news:<40053cca$0$24031$...
wrote:


[...]
Nous sommes d'accord là-dessus. Le premier devoir du développeur est
donc de *demander* ce que le programme doit faire, de savoir écouter
un client qui le lui explique, et de savoir orienter la conversation
pour qu'elle produise une information qu'il saura exploiter.


C'est en effet la toute première démarche. Et la deuxième, qui en
fait pratiquement partie, c'est mettre noir sur blanc ce qu'il a
compris, pour être sûr que l'autre a compris la même chose.


Ca c'est la cas ideal. Mais j'ai rencontré un paquet de clients qui ne
savaient pas ce qu'ils voulaient exactement et me disaient de faire a
mon idée pour exploiter au mieux le matériel qu'il venait d'acheter.
D'un autre coté, il est vrai que quand on branche un appareil de
numération sanguine a un ordinateur, il n'y a pas beaucoup de
possibilités.


Certes. Ce que veut le client peut être plus ou moins précis, et il
m'est arrivé aussi des cahiers de charges du genre « tu sais à peu près
ce que je veux, fais de ton meiux ». Mais il nous faut plus de
précisions avant de programmer, et à mon avis, il vaut mieux que c'est
précisions soient écrites noir sur blanc plutôt que d'être des vagues
idées dans la tête du programmeur.

J'ai déjà cité l'exemple de GB_Format. Ce que me démander le client,
c'était à peu près : « quelque chose du genre printf, avec les
paramètres positionnels de Open System, qui est type safe et qui peut
servir avec les flux C++ ». Avant d'écrire la premiére ligne de code,
j'ai écrit une spécification plus détaillée -- dans ce cas-ci, je l'ai
mise en commentaire dans le fichier d'en-tête, parce que je ne savais
pas où ailleurs le mettre sans qu'elle se perd. (La version sur ma site
a beaucoup évolué depuis, évidemment, mais la spécification originale
était au moins aussi détaillée.)

De même, avant d'écrire le code dans le fichier .cc, j'ai écrit la
spécification de chaque fonction.

Et seulement une fois l'écriture de la classe à peu près finie, je me
suis mis à écrire les programmes de test.

L'ordre de l'écriture du code -- qu'on écrit d'abord les tests ou
d'abord l'implémentation, n'est pas, à mon avis, d'une grande
importance. L'essentiel, c'est qu'on en écrit les deux. Historiquement,
dans beaucoup de boîtes, au moins, il y a eu une tendance à negliger les
tests, et si le but de mettre les tests en avant, et de dire qu'il faut
commencer par eux, c'est de s'assurer qu'on ne les neglige pas, je
trouve que c'est bien. Mais avant d'écrire ou les tests ou le code, il
faut savoir exactement ce que le programme doit faire, et je reste sur
ma position que si tu ne sais pas l'écrire d'une façon précise en
français (ou en anglais, ou en allemand, ou ...), tu ne sais pas
exactement ce que le programme doit faire. J'ajouterai en plus que si tu
ne les as pas réelement écrit, tu ne sais pas si tu sais les écrire.

Note que même quand j'écris du code pour moi-même, j'écris d'abord une
spécification. Je suis incapable d'écrire un programme sans y passer.

J'ai vu trop de cas où on met un jeune développeur, récemment promu
chef de projet, face à un client pour la première fois, en lui
demandant après une heure d'entretien de rédiger un cahier des
charges de 50 pages. Le "ce que ça doit faire" résulte avant tout
d'une conversation avec la maîtrise d'ouvrage. Si on met plus de
temps à rédiger le bilan de cette conversation qu'on en a mis à
avoir la conversation, on est en train d'inventer.


Pas forcement. Si on connaît un peu le domaine du « client », on
sait comprendre ce dont il a besoin au démi mot. Ensuite, on l'écrit
en détail, et on lui fait lire, pour qu'il confirme qu'on a bien
compris.

Ceci vaut à l'intérieur du projet aussi. Le « client », c'est les
autres développeurs, qui vont interfacer avec ce que nous faisons.

Et finallement, ce que veut le client, ce n'est pas forcement assez
détailler pour commencer quoique ce soit. Prenons un cas concret :
on me démande une bibliothèque de communication entre deux machines.
Ce que me dit mon client, c'est à peu près les types d'informations
qu'il faut communiquer, dans quelle quantité et dans quelle
circumstances. Pour la reste, il me fait confidance -- il ne veut
même pas savoir. N'empêche que sans avoir défini le protocol en
détail (est-ce que je transmets les entiers gros-boutien,
petit-boutien ou en texte, etc.), je n'écris pas une seule ligne de
code.


J'ai fait ca pendant 4 ans, et j'ai deja eu des description de
protocole assez speciale (style un post it avec deux ou trois lignes
griffonées). Quand le protocole n'etait pas carrément faux voire
inconnu ("comment? il se branche cet appareil? je ne savais meme pas")
avec obligation de brancher un ordinateur derriere la machine pour
recuperer un exemple de données transmises (une société dont je ne
citerais pas le nom était familiere de ce genre de chose). Et il n'y a
qu'un seul appareil que je n'ai pas reussi a brancher (sur 200).


Je sais. Mais avant d'écrire du code, il faut que je sache ce qu'il doit
faire. Dans le cas d'un protocol, si la spécification que j'ai reçue du
client n'est pas suffisamment précise, je commence par en écrire une qui
l'est. Et seulement quand je l'ai, je commence la programmation.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16



1 2 3 4