Discussion :

[iubito]

Penses tu que Mozart n'avait nul besoin de structurer sa pensée pour en "sortir" de la musique ... entre émotions et musique ...
il y a peut etre la partition, non ?

La partition de Mozart, c'est l'équivalent du code des programmeurs.
Le résultat exécuté par les musiciens, c'est l'exécution du programme

[- Robby -]

iubito ! ... wai,et alors ? tu veux dire quoi ?
Développe nous ta pensée, ne te limite pas a de simples métaphores,
voir des comparaisons quasi métaphysiques ...
explique nous ce que tu penses réellement !

[ErwanVDF]

re,
J'aime beaucoup le point de vue de Nyal, bien qu'il y ait également des cas "d'inspiration" : Trouver une structure "neuve" adaptée à la résolution d'un nouveau type de problème. Comme vous pouvez le constater je parle ici de types de problèmes et de structure de résolution...
Et je suis également d'accord pour dire que qquesoit les facilités de chacun, la discussion et la confrontation d'idées ne peuvent qu'être bénéfiques à tous. D'ailleurs ce forum est la pour ça non?

[Guigui_]

C'est pas bien difficile de faire de la programmation spontannée sur des choses que l'on sait faire (si ce sont des problèmes que l'on a déjà plus ou moins abordé dans son passé).
Souvent, j'aime bien coder avant d'avoir fini de structurer mon algo (et donc programmé les idées qui me passent par la tête) mais je suis souvent obligé tout de même de revenir dessus (pour modifier légèrement ou complètement l'architecture des l'algos). Donc je doute qu'il soit possible de programmer "sans réfléchir" des algos puissants sans devoir ensuite revenir dessus pour les retravailler. Et comme bon nombre d'entre vous l'ont déjà mentionné (en IA par exemple), si vous travaillez sur un problème que vous n'avez jamais traité (ou réfléchi), je vois pas comment vous pouvez faire du code spontannée.

Pour ceux qui utilisaient la musique comme exemple, premièrement, Mozart, c'était un génie (donc si vous vous comparez à Mozart...) mais il faisait de la musique 24h/24h donc c'est normal qu'à force, des mélodies lui viennent tout seul. Mais en musique, y'a pas les mêmes notions qu'en informatique (ca serait quoi l'équivalent d'un "code optimisé" en musique ?).
Pour ceux qui font du jazz, vous croyez que les improvisations, c'est de la musique spontanée ? ben pas entièrement, y'a du travail derrière (et donc en fait, ce qu'ils jouent, ce sont des choses qu'ils ont plus ou moins conçues dans leurs heures d'entrainement).

Tout ça pour dire que la programmation spontanée, c'est bien gentil, mais y'a forcémenent derrière un vécu qui fait qu'on est capable d'aborder plus ou moins rapidement certains problèmes. Par contre, c'est certains que ce n'est pas efficace pour de gros projets ou travail en équipe.

[- Robby -]

Bonne vue des choses Guigui_ !
Tu vois ca avec justesse, recul et bon sens.
Plus une certaine "optique" des choses a laquelle je n'avais pas pensé.
Je suis d'accord avec toi.

[Admin]

Pour ceux qui font du jazz, vous croyez que les improvisations, c'est de la musique spontanée ? ben pas entièrement, y'a du travail derrière (et donc en fait, ce qu'ils jouent, ce sont des choses qu'ils ont plus ou moins conçues dans leurs heures d'entrainement).

Pas exactement en faite :-)

En musique comme tout impro, tu dois respecter des reglèes, jouer de facon tonale ou intonale, respecter telle ou telle gamme, voila les reglès de base de l'harmonie.

Maintenant, rien n'empeche une personne débutante de reussir à improviser sans connaitre tout ça, mais ce sera bien plus long à apprendre.

[djibxav]

Pour ce qui est des commentaires et noms de variables voilà un exemple fictif du genre de bouts de code que j'ai pu trouver sur un moteur DHTML en php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$j=0;
$p=-1;
$z=25;

for &#40;$b=0; $b<$z; $b++&#41;&#123;
$a = fct1&#40;$tab&#91;0&#93;&#91;$b&#93;&#41;;

if $a>$untruc&#123;
$m1&#91;$j&#93;=$a;
$j++;&#125;

else&#123;
$p++;
$m2&#91;$p&#93;=$a;&#125;&#125;

Et comme ça sur des centaines de lignes.

Alors oui le mec qui a codé ça avant comprennait surrement ce qu'il ecrivait au moment ou il l'ecrivait de façon spontanée.
Mais moi, sans dossier d'analyse, sans aucun document à coté, juste avec le code sans commentaire et avec des noms de variables et fonctions non significatifs j'ai passé qques jours à comprendre le fonctionnement de son moteur.
Et ce n'etait qu'un tres petit projet.
La programmation spontané je suis le premier à l'utiliser pour des petits projets persos, mais sur un projet d'envergure c'est de la folie pure.

[al1_24]

J'ai eu la chance , compte tenu de ma longue expérience, de travailler ces dernières années sur la rétro-documentation d'applications existantes dans différents environnements fonctionnels.
Quel plaisir de passer derrière un programmeur génial qui, à l'instinct, avait pondu des centaines voire des milliers de lignes de code non commenté où les variables se nommaient a, b ou x, les objets Label1, Form2 et les méthodes f1..fn. Sans compter les multiples recopies de code là où une fonction paramétrée aurait suffi.
La seule chose à faire quelquefois était d'exécuter le code en mode de débogage pour envisager de comprendre ce qu'avait voulu faire ledit programmeur avant de pouvoir ajouter les lignes de commentaire entre les lignes de code, éventuellement renommer variables, objets et méthodes et enfin rédiger les spécifications et autres règles de gestion qui n'avaient jamais été mises à plat ailleurs que dans le cerveau du concepteur.
Rien à redire sur le fonctionnement des applications : helvétisées ! (NdT: qui tournent comme des mécanismes d'horlogerie suisse)
Mais côté maintenabilité...
Encore une chance que Delphi, Access ou VB nomment automatiquement les objets et les méthodes évènementielles.
Tout cela pour dire que rien ne remplacera un bon document d'analyse et des programes commentés, d'abord pour les développeurs mais surtout pour ceux qui seraient amenés à faire évoluer ces applications.
Cela me fait un peu penser au petit matériel audio (mini-chaîne) : c'est bien fini, ça fonctionne bien... jusqu'au jour où il faut remplacer le voyant qui éclaire le cadran... et pour cela démonter une vingtaine de vis et autant de connecteurs avant de constater, après avoir cherché dans 10 boutiques spécialisées, que l'ampoule n'est pas standard et d'être obligé de bidouiller pour effectuer une réparation de fortune.

[- Robby -]

J'adore l'analogie avec le "petit matériel audio" !
Y'a du vécu derrière ca, clair ! ...
Ma remarque n'a rien avoir avec le fond du débat ...
mais c'est tellement vrai cette remarque.
Moi, j'ai donné aussi dans ce genre de plan !
je demonte plus ce genre de "brol" ... ah non, c'est fini ca !
Et pour ton opinion sur le "spontané" ... 100% d'accord avec toi.

[cedricgirard]

Commencer par spécifier puis coder le squelette de l'application, puis ensuite avancer de facon iterative pour chauque sous partie du projet
Analyse, codage, test puis validation et ensuite on passe a une autre partie

Ca me semble la maniere la plus sympa de procéder, tout en garantissant la qualité. C'est la base de XP ;-)

[cedricgirard]

La première fois que je me suis concentré pour commencer à créer véritablement un programme, ça ma déconcentré immédiatement de me voir concentré à ce niveau (d'un point de vue extérieur).

Marrant ça me rappele une pub mal traduite de l'américain pour le "Pouvoir ZON", qui est censé pousser les gentils vers la réussite alors que les méchants tombent dans le puit du malheur, et le tout sans effort.
Ceci n'est qu'une anecdote, je trouve ton style un peu enflammé ;-) mais c'est bien comme ça.

Concevoir l'algo mentalement ou sur papier ne me semble pas changer grand chose - juste une différence d'outils. Ensuite lire le code facilement est une capacité. Je me focalise justement en ce moment sur le refactoring en extreme programming, technique qui aide à rendre le code limpide d'une maniere fiable, en conjonction avec des tests unitaires.
Pratique tu les tests unitaires?

[cedricgirard]

Alors que l'informatique c'est basiquement TRES technique , encore une fois je me répète un programme informatique c'est semblable à un jeu de construction type Meccano où il faut assembler des modules avec d'autres ou bien un méchanisme d'horloge suisse.

Bien que je sois pas convaincu par le dev spontanné, je suis persuadé que ecrire un programme est plus une activité littéraire que technique/mathématique. Avis partagé par quelques un de mes profs passés (depuis plusieurs années je précise)
Etant attiré par l'écriture romanesque, et pour ce que j'ai lu sur divers auteurs, la maniere de faire d'un developpeur et d'un écrivain n'est pas si éloignée

[sequentaire]

Bien que je sois pas convaincu par le dev spontanné, je suis persuadé que ecrire un programme est plus une activité littéraire que technique/mathématique. Avis partagé par quelques un de mes profs passés (depuis plusieurs années je précise)
Etant attiré par l'écriture romanesque, et pour ce que j'ai lu sur divers auteurs, la maniere de faire d'un developpeur et d'un écrivain n'est pas si éloignée

J'approuve, je vote +1.

[Chromozome]

Moi j'aimerais bien voir quelques centaines de lignes de programmation de doloop

[djibxav]

Bien que je sois pas convaincu par le dev spontanné, je suis persuadé que ecrire un programme est plus une activité littéraire que technique/mathématique. Avis partagé par quelques un de mes profs passés (depuis plusieurs années je précise)
Etant attiré par l'écriture romanesque, et pour ce que j'ai lu sur divers auteurs, la maniere de faire d'un developpeur et d'un écrivain n'est pas si éloignée

Approuve +1

Ce qui nous conforte dans l'idée de l'analyse quand on vois le travail de preparation realisé par un ecrivain avant de coucher le moindre ligne (bien sur si on cite les editions arlequin ça conforte l'idée du developpement spontané mais bon.... )

[Doloop]

Salut à tous,

Je rajoute un petit complément d'information à propos du livre des 10 % en question.

Citation du livre : programmation du 6502 de Rodnay Zaks aux éditions SYBEX (dépot légal initial : 3 e trimestre 1981)

Le tracé de l'ordinogramme est une étape hautement conseillé entre la spécification de l'algorithme et le codage proprement dit de la solution. Il est remarquable que l'on ait observé que peut-être seulement 10 % de la population des programmeurs sont capables d'écrire un programme correct sans passer par l'ordinogramme.
Malheureusement, on a observé aussi que 90 % de la population croient faire partie des 10 % qui n'ont pas besoin d'ordinogramme.

Il en résulte que en moyenne, 80 % des programmes ne fonctionneront pas à leur premier passage en machine. (Ces nombres n'ont bien sûr pas la prétention d'être très précis). En bref, la plupart des programmeurs novices voient rarement la nécessité de tracer un ordinogramme. Ceci entraîne habituellement des programmes "boiteux", ou erronés. Ils doivent alors passer un temps considérable à tester et à corriger leur programme (cela s'appelle la phase de mise au point). Il est donc fortement recommandé d'avoir la discipline de tracé l'ordinogramme dans tous les cas. Cela demandera un petit supplément de temps avant le codage, mais il en résultera habituellement un programme clair qui s'exécutera vite correctement. Lorsque les ordinogrammes sont bien compris, un faible pourcentage des programmeurs sont capables de franchir cette étape mentalement sans avoir à faire de tracé sur papier. Malheureusement, dans ce cas, les programmes qu'ils écriront seront difficiles à comprendre pour quelqu'un d'autre privé de documentation que constitue l'ordinogramme. Il est donc universellement recommandé d'avoir la stricte discipline de tracer l'ordinogramme pour tout programme important.

L'auteur a enseigné la programmation et les microprocesseurs à plus de 3000 personnes dans le monde entier. Il est ingénieur de l'Ecole Centrale et docteur de l'université de Berkeley où il a développé un interpréteur APL microprogrammé, ...

Bonne continuation.

@ +

[Claude Pelletier]

J'ai personnellement une méthode qui, si on l'observe superficiellement, s'apparente à de la programmation spontanée, car je m'attarde peu à de longues analyses, ne réalisant pas de très gros projets (essentiellement des sites Web en JSP). Mais je prends quand même le temps de composer un plan de ce que j'ai à faire, ne serait-ce que pour discerner les points stratégiques du développement et établir des priorités dans la production.

J'apparente l'analyse à l'établissement d'un budget. En effet, on arrive facilement à vivre sans établir de budget, quand on ne brasse pas de trop grosses affaires. Cependant, dès que l'on a des placements, des obligations, des investissement, on perd le fil, sans budget, et l'on s'expose à de gros ennuis, comme la faillite, ou l'on ne tire pas le meilleur rendement de nos avoirs.

Mes analyses peuvent parfois tenir sur un bout de papier, comme le budget d'un étudiant, mais au moins ai-je une idée précise de tout ce qu'il y a à faire pour mener mes projets à terme avec le meilleur des rendements.

[quicky2000]

La programmation spontanée c peut être bien tout seul ( et encore ... ) mais pas en équipe ( cf toutes les raisons citées précédemment )...j aimerais savoir si c'est utilisé en entreprise, si oui je réviserais mon jugement.

[bilb0t]

Bien sur que c'est utilisé en entreprise !!!

"-C'est pour quand ça boss ?"
"-Pour hier soir !!!"

C'est le cas typique où j'utilise la prog spontanée.

ça te fais réviser ton jugement ?

[quicky2000]

Je reformule ma question est ce que c est utilisé en entreprise dans des cas autres que celui où le travail était à rendre pour hier ou plus généralement qu'on a pas le temps...