Discussion :

[Matthieu Vergne]

Coder lentement ne veut pas dire ne pas faire d'erreur. D'ailleurs, il ne s'agit pas simplement de coder lentement ou rapidement, qui ne veut rien dire en soit, mais de choisir entre prendre le temps de concevoir complètement avant de coder ou de se lancer dans le code tout de suite en concevant la solution à la volée. Les erreurs sont toujours possibles, dans les deux cas, mais la seconde pratique tant à faire du code qui sera jeté plus tard. Si le projet dure longtemps, les dépendances à ce code jetable s'agrémentant, il finira par devenir à la fois nécessaire à jeter mais impossible à jeter, mettant l'équipe dans l'embarras car il faudra non seulement refaire ce bout là mais aussi tous ceux qui en dépendent, et ainsi de suite.

[MikeRowSoft]

Qu'en pensez-vous ?

Se qui n'est pas un trolldi, c'est justifier le fait de toujours avoir besoin de coder pour un développeur dans une entreprise.
De justifier d'une place permanente et non remplaçable.

Après les outils métier de la comptabilité, je vois bien les écoles et universités payer un abonnement mensuel pour leurs structures informatique...
Sans oublier tous les bulletins d'information (MAJ, UPGRADE, DOWNGRADE) qui vont avec.

[Lolo78]

Informatique: On a le temps de faire mal 3 fois mais on a pas le temps de faire bien 1 fois.

C'est vraiment un point essentiel.

On passe son temps à mal faire plusieurs fois que que l'on aurait pu bien faire du premier coup et en beaucoup moins de temps avec les bonnes conditions.

[sat99]

Lorsqu'on pense avoir terminé une appli, c'est à ce moment qu'il faudrait tout effacer pour recommencer avec une nouvelle architecture du produit. En effet, l'architecture idéale de l'appli ne se dévoile généralement qu'au cours de la première mouture. Perso, je fais des petites appli web gratuites sur internet, je doute que dans le cadre d'une entreprise on ait le temps de tout refaire.

[jovanovic.radoslav]

je programme depuis 30 ans. Je regarde la façon de faire des jeunes loups. Sans avoir lu le sujet jusqu'au bout il commence à coder, son but : fournir un exe le plus vite possible. Oui il doit montrer au chef qu'il peut le faire. Et il le fait. bon c'est un peu bancale, y'a des bout de ficelle partout, y'a qu'une fonction, bon elle a 5000 lignes; mais il en en fière, ça marche !!! Et quand je lui dit que je préfère de loin un code bien écrit et qui ne marche pas à un code qui marche mais mal écrit, il ne comprend pas. Mais six mois plus tard, quand il doit modifier son code dont il était assez fière, je le vois s'arracher les cheveux c'est la qu'il comprend la nécessité de découper son code en de nombreuses fonctions et de bien lire le cahier des charges. Comme le dit le proverbe c'est en forgeant que l'on devient forgeron. Il faut du temps pour devenir un pro. Quand devient on pro ? Quand on a compris que l'important en programmation n'est pas un exe qui marche ni un minimum de temps pour le faire mais un code que même un débutant peu comprendre et modifier, quand le code écrit est votre fierté et non l'exe, quand vous avez compris que vous êtes capable de faire. Alors il ne vous reste plus qu' à bien faire et la vitesse viendra d'elle-même.

[CodeurPlusPlus]

(...) l'important en programmation (...) un code que même un débutant peu comprendre et modifier (...)

Bonjour,

D'accord avec l'ensemble de votre propos, mais le passage que je cite me semble un peu extrême et idéaliste. Dès qu'une application dépasse un certaine complexité, il n'est jamais facile de comprendre et modifier, que l'on soit débutant ou pas. Je parle d'une complexité "irréductible", pas d'une complexité superflue due au fait qu'on n'a pas réussi à écrire du code maintenable. C'est dur de modifier du code, en particulier à cause des "effets de bords"... malheureusement les langages populaires sont ceux qui encouragent à en mettre partout !

[Matthieu Vergne]

Toute la question étant de savoir si ce que tu appelles "complexité irréductible" est effectivement irréductible par nature ou du fait des compétences du programmeur. Pour ma part, je tend à penser qu'une complexité n'est jamais irréductible par nature, même si c'est loin d'être une des tâches les plus simples. C'est de l'ordre du modèle conceptuel, et quand on touche à des paradigmes cela rend la chose d'autant plus difficile, mais pas impossible.