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...;)
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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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.
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.
Pour écrire du code bête, il faut savoir coder intelligemment.
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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
Sayajin
"Olivier Azeau" a écrit dans le message de news:
wrote:
Olivier Azeau wrote:
Sayajin wrote:
"korchkidu" 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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
"Olivier Azeau" <ransom@xasamail.com> a écrit dans le message de news:
1106919057.956731.183150@f14g2000cwb.googlegroups.com...
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.
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.
Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
K. Ahausse
"Sayajin" a écrit dans le message de news:41fa409f$0$2183$
"Olivier Azeau" a écrit dans le message de news:
wrote:
Olivier Azeau wrote:
Sayajin wrote:
"korchkidu" 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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
Il a parfaitement compris : "Sur le fond, l'idée peut se défendre ... " Il dit, aussi, que les choses ne sont pas tout blanc/noir. Il dit, aussi, que, "lors d'un entretien", la formulation : "Au final on doit "coder bêtement"", prête trop à confusion ... comme le prouve ce fil.
"Sayajin" <metalkura@wanadoo.fr> a écrit dans le message de
news:41fa409f$0$2183$8fcfb975@news.wanadoo.fr...
"Olivier Azeau" <ransom@xasamail.com> a écrit dans le message de news:
1106919057.956731.183150@f14g2000cwb.googlegroups.com...
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.
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.
Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
Il a parfaitement compris : "Sur le fond, l'idée peut se défendre ... "
Il dit, aussi, que les choses ne sont pas tout blanc/noir.
Il dit, aussi, que, "lors d'un entretien", la formulation : "Au final on
doit "coder bêtement"", prête trop à confusion ... comme le prouve ce fil.
"Sayajin" a écrit dans le message de news:41fa409f$0$2183$
"Olivier Azeau" a écrit dans le message de news:
wrote:
Olivier Azeau wrote:
Sayajin wrote:
"korchkidu" 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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
Il a parfaitement compris : "Sur le fond, l'idée peut se défendre ... " Il dit, aussi, que les choses ne sont pas tout blanc/noir. Il dit, aussi, que, "lors d'un entretien", la formulation : "Au final on doit "coder bêtement"", prête trop à confusion ... comme le prouve ce fil.
Olivier Azeau
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.
En C++, une telle séparation entre conception et codage ne marche pas. 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. 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. 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.
"Hatez-vous lentement; et, sans perdre courage, Vingt fois sur le metier remettez votre ouvrage."
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.
En C++, une telle séparation entre conception et codage ne marche pas.
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.
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. 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.
"Hatez-vous lentement; et, sans perdre courage, Vingt fois sur le
metier remettez votre ouvrage."
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.
En C++, une telle séparation entre conception et codage ne marche pas. 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. 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. 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.
"Hatez-vous lentement; et, sans perdre courage, Vingt fois sur le metier remettez votre ouvrage."
Alexandre
<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 ;-) </>
<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 ;-)
</>
<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 ;-) </>
Pascal
Fabien LE LEZ wrote:
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.
Dans ce cas, il n'existe pas beaucoup de bon programmeurs...
-- Pascal
Fabien LE LEZ wrote:
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.
Dans ce cas, il n'existe pas beaucoup de bon programmeurs...
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.
Dans ce cas, il n'existe pas beaucoup de bon programmeurs...
-- Pascal
Sayajin
"K. Ahausse" a écrit dans le message de news: 41fa4dce$0$6619$
"Sayajin" a écrit dans le message de news:41fa409f$0$2183$
"Olivier Azeau" a écrit dans le message de news:
wrote:
Olivier Azeau wrote:
Sayajin wrote:
"korchkidu" 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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
Il a parfaitement compris : "Sur le fond, l'idée peut se défendre ... " Il dit, aussi, que les choses ne sont pas tout blanc/noir. Il dit, aussi, que, "lors d'un entretien", la formulation : "Au final on doit "coder bêtement"", prête trop à confusion ... comme le prouve ce fil.
Le but du post n'est "ce qui est à dire ou pas" mais "ce qui fait qu'on est
un bon codeur ou pas" aprsè pour la formulation la diplomatie est un art universel !
"K. Ahausse" <anonymous@discussions.microsoft.com> a écrit dans le message
de news: 41fa4dce$0$6619$8fcfb975@news.wanadoo.fr...
"Sayajin" <metalkura@wanadoo.fr> a écrit dans le message de
news:41fa409f$0$2183$8fcfb975@news.wanadoo.fr...
"Olivier Azeau" <ransom@xasamail.com> a écrit dans le message de news:
1106919057.956731.183150@f14g2000cwb.googlegroups.com...
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.
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.
Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
Il a parfaitement compris : "Sur le fond, l'idée peut se défendre ... "
Il dit, aussi, que les choses ne sont pas tout blanc/noir.
Il dit, aussi, que, "lors d'un entretien", la formulation : "Au final on
doit "coder bêtement"", prête trop à confusion ... comme le prouve ce fil.
Le but du post n'est "ce qui est à dire ou pas" mais "ce qui fait qu'on est
un bon codeur ou pas" aprsè pour la formulation la diplomatie est un art
universel !
"K. Ahausse" a écrit dans le message de news: 41fa4dce$0$6619$
"Sayajin" a écrit dans le message de news:41fa409f$0$2183$
"Olivier Azeau" a écrit dans le message de news:
wrote:
Olivier Azeau wrote:
Sayajin wrote:
"korchkidu" 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.
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. Pour écrire du code bête, il faut savoir coder intelligemment.
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 !
Il a parfaitement compris : "Sur le fond, l'idée peut se défendre ... " Il dit, aussi, que les choses ne sont pas tout blanc/noir. Il dit, aussi, que, "lors d'un entretien", la formulation : "Au final on doit "coder bêtement"", prête trop à confusion ... comme le prouve ce fil.
Le but du post n'est "ce qui est à dire ou pas" mais "ce qui fait qu'on est
un bon codeur ou pas" aprsè pour la formulation la diplomatie est un art universel !
Sayajin
"Olivier Azeau" a écrit dans le message de news:
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.
En C++, une telle séparation entre conception et codage ne marche pas. 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. 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. 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.
"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"
"Olivier Azeau" <ransom@xasamail.com> a écrit dans le message de news:
1106923162.591102.290300@z14g2000cwz.googlegroups.com...
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.
En C++, une telle séparation entre conception et codage ne marche pas.
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.
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. 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.
"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"
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.
En C++, une telle séparation entre conception et codage ne marche pas. 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. 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. 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.
"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"
Pierre Maurette
"Olivier Azeau" 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 ;-). -- Pierre
"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 ;-).
--
Pierre
"Olivier Azeau" 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 ;-). -- Pierre
Gabriel Dos Reis
Pierre Maurette writes:
| Vous faites un concours de banalités ? Je peux jouer ?
Oui.
-- Gaby
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
| Vous faites un concours de banalités ? Je peux jouer ?
