La différence entre un bon et un mauvais programmeur...

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 ?

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Loïc Joly wrote:

James Kanze wrote:

J'ai déjà donné sur projet où j'avais fortement influencé
une méthode de travail "toutes les interfaces publiques
décrites sous Rose et le code de ces interfaces généré
automatiquement en C++" Non seulement je ne suggèrerai
plus ce genre de choses mais je botterais le derrière de
toute personne qui le suggèrerait dans le cadre d'un
projet auquel je participe !

Je ne connais pas ton projet, mais je peux dire que je l'ai
vu marcher de façon extrèmement efficace à plus 'une
occasion. Chaque fois qu'on s'est servi de Rose, pour dire.

Je ne suis pas sûr comprendre la position que tu argues.
Est-ce que tu essaies de dire que la conception ne sert à
rien, et qu'il vaut mieux écrire des classes sans savoir
leur rôle dans l'application, et les fonctions sans savoir
exactement ce qu'elles doivent faire, ou est-ce que tu
argues qu'il faut simplement éviter à tout prix de
communiquer ces informations aux autres ?

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.

De plus, je pense que le niveau de détail sur lequel il faut
arrêter la conception dépend des gens, des tailles d'équipe,
des types de projet...

Je ne suis pas sûr de comprendre. La conception, on le fait même
quand on choisit l'algorithme à l'intérieur d'une fonction.
Voire même quand on chosit le nom des variables locales. Mais
évidemment, à ce niveau-là, on le fait effectivement en parallel
avec le codage. La question serait pas plutôt : quand est-ce
qu'on arrête la conception pûre sans codage ? Question à
laquelle la seule réponse possible est : quand on a fait assez
de conception pour savoir ce qu'on veut coder.

Il y a un fait plusieurs questions. La première, c'est est-ce
qu'il faut de la conception avant de commencer à coder ? Et là,
j'espère que personne n'en niera importance -- si tu ne sais pas
ce que doit faire la classe, comment la coder ? Mais au delà de
ça, j'ai l'impression qu'il y a moins accord. Quelle forme doit
prendre cette conception, par exemple ? Et jusqu'où faut-il
aller avant de commencer le codage ?

Pour la forme, dans mon esprit, une partie de la réponse est
claire : il faut quelque chose d'écrite. En plus, j'aurais
tendance à dire qu'il faut de l'UML, à peu près pour les mêmes
raisons qu'on chosit le C++ standard, plutôt qu'un langage
inventé par le fournisseur. À partir de là, je suis près à
discuter sur les moyens -- Rose, Together ou quelque chose
d'autre. Je suis un peu scéptique sur la solution papier, mais
il me semble avoir entendu parler des projets qui se sont servi
des outils graphiques pûrs, et qui ont réussi.

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.

[...]

Mais pour revenir à Rose ou Together : comment discutes-tu
de la conception sans l'avoir définie ? Sur un support que
les autres puissent lire ?

J'ai moi aussi un problème avec Rose. J'ai essayé de
l'utiliser, mais j'ai triuvé ça très laborieux. Je réfléchis
jusqu'à ce que j'ai une ébauche de conception dans la tête,
mais après, s'il me faut trop de temps pour la retranscrire,
ce qui a été le cas quand j'ai utilisé Rose, j'ai tendance à
me mélanger les pinceaux. Ou à avoir un chef qui débarque dans
mon bureau pour de la paperasserie ou organiser une démo.

Il y a certainement des aspects ergonomique qu'il faudrait
améliorer en Rose. On a parfois l'impression de se perdre dans
des enchaînements sans fin de menus et de boîtes de dialogues.
En revanche, je ne l'ai pas trouvé trop lourd pour la conception
à plus haut niveau, les diagrammes de classe ou des scénarios,
par exemple.

Jusqu'ici, mon expérience est prèsque uniquement avec Rose. Ce
qui me limite pas mal -- je sais que c'est mieux que le papier,
mais je ne peux pas le comparer à beaucoup d'autres choses. Ce
que je peux dire, c'est que je l'ai vu utiliser d'au moins trois
façons :

-- Simplement comme outil graphique de conception. Il servait à
déssiner des diagrammes de classe et des scénarios, et c'est
tout. Par la suite, on transcrivait ces diagrammes en code à
la main.

-- 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.)

Évidemment, on se servait beaucoup aussi de l'idiome du
pare-feu de compilation -- ajouter un membre privé exigeait
une modification dans le modèle. Aussi, on avait des
consultants de chez Rational chez nous qui savait bien
« tuner » le généré à nos besoins.

N'empeche que le résultat en valait la peine.

-- 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.)

Together m'avait semblé plus approprié à l'époque, mais encore
immature, très lent et trop orienté Java.

Tiens, c'est exactement mes impressions. L'ayant essayé (et en
avoir suivi le cour) il y a quelques mois. Together, c'est un
outil Java, écrit en Java, et bricoler pour pouvoir faire du
C++.

Enfin, c'ést mon impression. Il faut dire que comme Rose, il est
extrèmement ouvert, et que d'après le peu que j'ai pu voir, la
customisation est bien plus facile que celle de Rose. Alors, on
doit pouvoir l'adapter à faire du bon C++, même s'il ne le fait
pas en configuration de base. Et sur une machine Windows (où il
y a de bonnes implémentations de Java) puissante, avec assez de
mémoire, il doit aussi être utilisable. (Moi, j'ai un Sparc
Ultra avec 256 Mo. Autant dire qu'une application de cette
taille, écrite en Java, ce n'est pas la peine.)

Pour l'instant, j'ai tendance à travailler au papier et
crayon, ou encore en décrivant mon architecture sous forme de
squelette de classe écrits en C++, avec la doc d'utilisation
de ses classes. Je n'en suis pas pleinement satisfait, mais
n'ai pas encore trouvé mieux.

La solution de la squelette de classe en pseudo-C++ marche pour
de petites choses, ou les rapports entre les classes ne sont pas
trop complexes. (C'est ce qui me sers chez moi, dans le
développement de ma bibliothèque.) Mais on arrive vite à ses
limites.

Le gros problème que je trouve avec le papier, c'est que les
papiers se perdent. On fait une belle conception et on
l'implémente, mais par la suite, les papiers de conception sont
perdus, et personne ne le connaît plus.

--
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

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:

Dans un grand projet, c'est trivialement faux. Une fois que j'ai
figé l'interface de ma classe, je ne peux plus y toucher, parce
que la modifier imposerait des modifications chez tous les
collègues qui s'en servent. Mais même dans les petits projets,
c'est préférable d'éviter des modifications qui impactent
partout.

Il vaut donc mieux conserver du code pas tout a fait satisfaisant et
pas aussi clair que ce que l'on pourrait avoir sous prétexte qu'il
faudrait aller modifier quelques fichiers ?

Pour une classe applicative, si une telle tache est inenvisageable,
c'est qu'il y a un probleme de trop fort couplage dans la conception et
que, donc, il vaut mieux la revoir avant que les choses empirent.

Pour une classe 'composant de base' utilisée dans tous les
fichiers(genre log, gestion d'erreur, etc.), je peux le comprendre,
mais, a mon sens, cela justifie l'écriture de code assez tot dans le
process : pour justement détecter les évolutions souhaitables avant
que tout le monde ait utilisé une classe donnée dans "son" code.

A propos de cette "propriété" de code, une approche que j'essaie de
mettre en oeuvre, c'est justement de ne plus parler de "collegues qui
se servent de telle ou telle classe qu'untel a écrite". Le meilleur
moyen pour minimiser les impacts chez les autres, c'est d'aller
soi-meme modifier le code partout ou notre changement d'interface a des
impacts, autrement dit voir le code comme une propriété collective.

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.

In article <41fa6cc1$0$26209$626a14ce@news.free.fr>,
Alexandre <alex.g@netcourrier.com> wrote:

<mode 2nd degré on>
une bonne méthode :
inviter un programmeur à manger entre 12h et 14h, dans sa boite.
S'il te dit : no problem, allons au resto sympa à 30 min d'ici, on rentrera
vers 15h, alors il a le temps, c'est un mauvais programmeur puisque son chef
de projet ne lui confie rien.
Si par contre il te dit : "ok, justement j'avais 15minutes de pause
sandwitch entre 12h43 et 13h12, pendant que mon prog compile, on peut y
aller", alors c'est un bon programmeur, il est surchargé de boulot que son
chef lui donne car c'est le seul bon dans l'équipe.

Note : on peut aussi considerer que c'est l'inverse ;-)
</>

Je me mefierais beaucoup du deuxieme programmeur, deja il ne sait pas compter,
c'est mauvais signe...

On Mon, 31 Jan 2005 15:30:46 +0000 (UTC), espie@tetto.home (Marc
Espie):

Si par contre il te dit : "ok, justement j'avais 15minutes de pause
sandwitch entre 12h43 et 13h12, [...]

Je me mefierais beaucoup du deuxieme programmeur, deja il ne sait pas compter,
c'est mauvais signe...

Meuh non. Il parle juste d'un intervalle de longueur 15 minutes,
sous-ensemble de l'intervalle [12h43 ; 13h12].
Par exemple, [12h46 ; 13h01].


--
;-)

Fabien LE LEZ wrote:

On Mon, 31 Jan 2005 15:30:46 +0000 (UTC), espie@tetto.home (Marc
Espie):

Si par contre il te dit : "ok, justement j'avais 15minutes de pause

sandwitch entre 12h43 et 13h12, [...]

Je me mefierais beaucoup du deuxieme programmeur, deja il ne sait
pas compter,

c'est mauvais signe...

Meuh non. Il parle juste d'un intervalle de longueur 15 minutes,
sous-ensemble de l'intervalle [12h43 ; 13h12].
Par exemple, [12h46 ; 13h01].
Si les 2 bornes de l'intervalle sont incluses, cela fait 16 minutes ;-)

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.

-- Gaby

"Olivier Azeau" <ransom@xasamail.com> writes:

| 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.

Je mitoute.

-- Gaby