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

Pierre Maurette wrote:

"Olivier Azeau" <ransom@xasamail.com> a écrit dans le message de news:

[...]

"Hatez-vous lentement; et, sans perdre courage, Vingt fois sur le
metier remettez votre ouvrage."

Entièrement d'accord avec toi. Mais il faut bien séparer l'implémentation
technique d'un concept du concept lui même : imagine tu fait un super
programme optimisé, propre, lisible mais que le concept finalement est
bancal ca ne sert à rien. Ensuite comme tu l'as dit c'est claire que
le code
en lui même peut être fait et refait on ne fait pas un code optimisé du
premier coup d'ailleurs une des citations d'un des chapitres du livre
"Langage C++" e Bjarne Stroustrup est je cite :

"Une optimisation prématurée est la cause de tout les maux"

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

On 28 Jan 2005 04:18:32 -0800, kanze@gabi-soft.fr:

- travaille réellement 8h/jour plutôt que 1h code/2h internet ...

On ne code pas 8h/jour. Pas de manière efficace, en tout cas.

Ouf, tu me rassures. J'ai eu peur, un moment, d'être un glandeur fini.
De toutes façons, je ne suis pas sûr de pouvoir programmer
efficacement sans accès Internet.


--
;-)

On 28 Jan 2005 08:40:12 GMT, Marc Boyer
<Marc.Boyer@enseeiht.yahoo.fr.invalid>:

D'autant que son son patron à du mal à comprendre pourquoi il
a besoin de WarCraft comme support à sa longue réflexion.

Pour le coup, je ne comprends pas non plus. Je préfère les Doom-like :
ça repose le cerveau pendant qu'on joue, et on travaille plus
efficacement après :-)


--
;-)

On Fri, 28 Jan 2005 21:04:15 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:

Ah ! non ! c'est un peu court, jeune homme !

-- C++yrano ;-)


--
;-)

On 28 Jan 2005 04:18:32 -0800, kanze@gabi-soft.fr:

- travaille réellement 8h/jour plutôt que 1h code/2h internet ...

On ne code pas 8h/jour. Pas de manière efficace, en tout cas.

Ouf, tu me rassures. J'ai eu peur, un moment, d'être un glandeur fini.
De toutes façons, je ne suis pas sûr de pouvoir programmer
efficacement sans accès Internet.

J'ai parlé de *travailler* 8h par jour, pas de programmer 8h par jour
... Travailler peut aussi être chercher de la doc sur internet, par exemple.
Bien sûr j'aurai dû écrire :
- travaille réellement 8h/jour plutôt que 1h code/2h glandouille sur les
chat

ça va comme ça ?

--
Florent "flure" C.
http://flure.free.fr

flure wrote:

On 28 Jan 2005 04:18:32 -0800, kanze@gabi-soft.fr:

- travaille réellement 8h/jour plutôt que 1h code/2h
internet ...

On ne code pas 8h/jour. Pas de manière efficace, en tout cas.

Ouf, tu me rassures. J'ai eu peur, un moment, d'être un
glandeur fini. De toutes façons, je ne suis pas sûr de
pouvoir programmer efficacement sans accès Internet.

J'ai parlé de *travailler* 8h par jour, pas de programmer 8h
par jour ... Travailler peut aussi être chercher de la doc sur
internet, par exemple.

Même là, j'ai mes doutes. La programmation (ou disons plutôt le
développement des logiciels) a une partie créatrice non
negligeable, et la créativité ne se commande pas. En plus, je ne
crois pas qu'on puisse reflechir intensement 8 heures par jour
de façon systèmatique. Du coup :
-- il y a bien des moments au travail où on pense à d'autre
chose, et
-- si on est sur un problème dur, on y pense fatalement en
dehors du travail.
Dans la practique, s'il y a parfois des moments où on s'y met 12
heures par jours, le moyen ne doit pas dépasser quelque chose
entre 4 et 6 heures par jours, et vue ce que ça en prend,
dépasser les 4 à 6 heures de travail réelement effectif par jour
pendant plus d'une ou deux semaines nous enlève toute notre
efficacité.

Bien sûr j'aurai dû écrire :
- travaille réellement 8h/jour plutôt que 1h code/2h glandouille sur les
chat

ça va comme ça ?

Pas vraiment. Je ne chatte pas, mais non seulement la majeur
partie de mes postes sont écrites au travail, il m'arrive aussi
d'y jouer à nethack, et à lire les journaux. Mes chefs le
savent ; évidemment, ils savent aussi que quand il y a un
problème, j'y suis tout de suite à 100%, et que s'il dure, j'y
pense beaucoup en dehors du boulot. À la fin, le client s'y
trouve parce que la qualité du boulot y est. Si jouer un
démi-heure au nethack me détend, et que la qualité du travail
dans les heures qui suit est meilleur, l'employeur s'y rétrouve.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Olivier Azeau wrote:

Fabien LE LEZ wrote:

On Thu, 27 Jan 2005 15:59:05 +0100, korchkidu
<korch_ki_du@yahoo.fr>:

Le bon programmeur, il code, il compile, il exécute, ca
plante mais c'est un bon programmeur...;)

Le bon programmeur, il réfléchit, il réfléchit, il réfléchit,
il réfléchit, il réfléchit, il réfléchit, il code, ça compile
du premier coup (sauf fautes de frappe), et ça ne plante pas.

Tu as oublié : il sait expliquer a son patron pourquoi il réfléchit
autant ;-)

De plus en plus, c'est son patron qui l'exige. Dans pas mal de
boîtes où j'ai travaillé, il était pratiquement interdit de
commencer le codage sans une revue de la conception avant.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Olivier Azeau wrote:

k...@gabi-soft.fr wrote:

Olivier Azeau wrote:

Sayajin wrote:

"korchkidu" <korch_ki_du@yahoo.fr> a écrit dans le message
de news:

Par exemple, lors d'un entretien, qu'est ce qui peut faire
gagner des points et qu'est ce qui peut en faire perdre...

Au final on doit "coder bêtement" !

Voila un exemple de ce qui peut faire perdre des points si on
le dit lors de l'entretien.

Pas du tout. Être bête, c'est une qualité du code. Du code
bête, c'est facile à comprendre, et ça marche premier coup. Un
candidat dit qu'il fait de la conception jusqu'au point que
l'écriture du code devient bête, c'est un candidat qui a
compris comment bien développer.

Tout d'abord, je n'ai pas émis d'avis sur la pertinence
d'écrire du "code bête" mais sur la pertinence de le
mentionner lors d'un entretien et je reste persuadé qu'une
phrase comme "Au final on doit coder bêtement" peut faire
perdre des points.

Si la boîte est telle que ça fait perdre des points dans un
entretien d'embauche, c'est une boîte pour laquelle je n'ai pas
envie de travailler. Mais à juger d'après mes entretiens, la
plupart des boîtes de nos jours reconnaissent au moins en
théorie l'importance de la conception et la valeur d'un code
simple -- bête et méchant, si on veut. Souvent, elles ne mettent
pas leurs propres théories en pratique, mais au moins lors des
entretiens, elles posent les bonnes questions, et une réponse
qu'il faut coder bêtement, si on a bien dit que c'est parce
qu'on a reflechi sur ce qu'on avait à coder avant, marquera des
points positifs.

Sur le fond, l'idée peut se défendre tant que l'on ne s'y
cramponne pas et que l'on accepte des methodes alternatives en
fonction du contexte.

Si un candidat soutient bec et ongles qu'il faut toujours bien
réfléchir et peaufiner sa conception et que ensuite on peut
passer a une écriture de code en tant qu'activité mécanique,
il n'a rien compris au développement.

Je me rappelle une catégorisation des logiciels que j'ai entendu
une fois : il y a le code simple, où c'est évident qu'il n'y a
pas de fautes, et le code compliqué, où il n'y a pas de fautes
évidentes.

Celui qui veut sauter la phase de conception, et qui se met à
écrire du code sans savoir réelement ce qu'il doit faire, n'a
rien compris au développement dans un milieu industriel ou
commercial. De même quelqu'un qui ne prise pas la simplicité
dans son code.

Pour écrire du code bête, il faut savoir coder intelligemment.

Justement, développer du code intelligemment, c'est de se mettre
dans une situation où on peut coder bêtement.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Olivier Azeau wrote:

Sayajin wrote:

T'a pas compris, faut pas le prendre au sens propre du terme,
mais plutôt dans le sens que le codage doit être qu'une simple
formalité ou l'on accouche ses idées qui ont pris forme dans
la conception. Un code bête ou coder bêtement = code propre,
lisible bien foutu quoi !

Justement non, le codage ne doit pas etre une "simple
formalité". C'est peut-etre vrai dans des contextes (que je ne
connais pas) ou on sépare les travaux d'analyse, de conception
et de codage sur des activités tellement distinctes qu'on
emploie des personnes différentes pour les réaliser.

Ce n'est pas nécessairement une question de personnel différent,
une personne peut porter (et porte, en général) plusieurs
châpeaux. Et la façon la plus sûre de ne pas faire une
conception rigueureuse, c'est de ne pas la séparer du codage. Au
minimum (et seulement dans des choses très simple), on écrit
d'abord la définition de la classe, avec la declaration des
fonctions publiques, les invariantes, et les pré- et
post-conditions des fonctions, avant d'ouvrir les sources dans
l'éditeur. Dès que les choses deviennent le moindre petit peu
compliquées, on commence par des diagrammes de classe et des
scénarios ; seulement quand on est sûr de son coup, on se met à
écrire du « code ».

En C++, une telle séparation entre conception et codage ne
marche pas.

Elle se pratique couramment, tu veux dire. En fait, je n'ai
jamais vu du bon code écrit autrement.

Evidemment, commencer par faire quelques schemas de conception
pour éprouver quelques idées en les soumettant aux collegues
est une bonne chose mais vouloir définir toutes ses classes
sur le papier avant de passer au code n'est en général qu'une
perte de temps.

Qui travaille sur papier ? Il y a Rose, il y a Together, et il y
en a certainement d'autres. Est-ce qu'il existe une boîte
aujourd'hui qui ne s'en sert pas ?

Et ce pour une raison simple : un travail de développement est
une activité fortement itérative ou l'on navigue en permanence
entre conception, codage et test.

Il peut y avoir des développements itératifs, tout dépend du
contexte. Mais même itératif, on suit la même schéma dans chaque
itération -- conception et définition de ce qu'on veut faire
d'abord, puis validation du concepte, puis codage et tests.

Le code propre et lisible, on ne l'obtient jamais en sortant
directement d'une conception, mais en l'ayant travaillé
pendant un certain temps qui passe par des aller-retours avec
la conception.

Le code ne devient jamais plus lisible suite à des
modifications. Au plus, on espère qu'il ne devient pas moins
lisible.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

K. Ahausse wrote:

"korchkidu" <korch_ki_du@yahoo.fr> a écrit dans le message de
news:41f901ba$1@epflnews.epfl.ch...

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

Je pense que, sur fclc++, seuls les bons programmeurs te
répondront :-) "recursion is divine" :-)) J'imagine mal un
intervenant régulier dire : " Ho ! ben, moi j'suis qu'un gros
nul".

Peut-être, mais...

L'entretien sert des deux côtés. La boîte veut apprendre de moi,
et moi, je veux apprendre de la boîte. Et on est d'accord tous
les deux que ça ne sert à rien si on ne passe pas ensemble -- je
ne serais pas productif pour la boîte, et je ne m'y plairais pas
non plus. D'où un essai de ma parte pour comprendre les
attitudes de la boîtes.

Une des choses importantes, à mon avis, c'est une ambiance où on
peut avouer ses erreurs. Je n'ai jamais connu un programmeur si
bon qu'il n'en fait jamais. Moi compris. Alors, est-ce qu'il
faut les cacher, et chercher à passer la blâme à quelqu'un
d'autre, ou est-ce que je peux aller sans peur à mon chef, et
lui dis que je me suis trompé là, et qu'il faut faire quelque
chose ?

Alors, évidemment, je ne dis pas que je suis un gros nul, mais
je m'assure aussi que l'employeur potential ne s'attend pas à la
perfection.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34