Qui pratique la programmation spontanée ?

[ErwanVDF]

Salut,

Je pratique également ce que tu appelles la programmation spontanée.
Je fais moi aussi "tourner les lignes de codes dans ma tête". Et ce qui me pousse à répondre ici est que je qualifierais mon esprit de "procédural".

Je pense que la plupart des gens ne comprennent même pas ce que tu entends par la.. En ce qui concerne les commentaires, j'ai appris à m'en passer également au fur et à mesure que mon "style d'écriture" devenait plus limpide. Ceci dit, dans un souci de relecture, j'en mets parfois à des endroits clé. Un code bien écrit me parait parler de lui-même, et est en tout cas bien plus lisible que les torchons bourrés de commentaires que j'ai l'habitude de voir....

En ce qui concerne les soit-disant gros projets ayant fait l'objet d'une analyse détaillée préalable, restons sérieux et ne se voilont pas la face.
1) la plupart sont obsolètes quand ils arrivent à terme car le besoin a changé, mais l'analyse elle est restée figée..
2) Sur nombre de ces gros projets, j'ai vu les chefs de projet mettre de coté une difficulté au moment de l'analyse en se disant : faisont déjà le reste.. résultat, le produit est mal pensé, mal structuré, et le résultat est en général une refonte avant même qu'il soit achevé..

Je voudrais également préciser que programmation spontanée ne signifie pas forcément aucune analyse.. Je pense mon problème avant d'écrire, mais effectivement, la plupart du temps, je n'ai pas besoin de dessiner un algo ou de poser la chose sur papier au préalable. J'ai un structure en tête, le codage n'est qu'une forme d'expression de ma solution.

Je pense que ce qui induit les gens en erreur c'est qu'ils ont l'impression que tu t'asseois devant ton clavier et que tu codes au petit bonheur la chance. En fait, si c'est comme pour moi, quand on commence à tapoter on a déjà une "structure" en tête, la façon dont les différentes parties de la solution vont s'assembler, le codage en lui même n'est que la réalisation des pièces du puzzle, mais l'image du puzzle et la forme des pièces qui le composent est déjà dans ma tête, en tout cas pour la majeure partie.

Voilà, j'espère que tu te sens moins seul à présent

[ErwanVDF]

En fait, vais rajouter un PS (j'avais pas tout lu avant de poster, honte à moi).

Ceux qui disent que ce n'est applicable que sur des petits projets n'ont jamais :
1) travaillé sur un gros projet
2) mené un gros projet non caduque à terme

En ce qui concernent les commentaires pour l'équipe ou une éventuelle modification ultérieure du code, la aussi, restons sérieux : La plupart du temps les commentaires que je lis dans le code sont aussi enrichissant que a=1; /* Affecte 1 à la variable a */
Et à dire vrai, la plupart du temps, si je dois corriger un truc, je survole le code, si c'est bien écrit y en à pour 2 min (et vi, je lis le code couramment, n'en déplaise à certains). Si c'est mal écrit (commentaires ou pas) c'est direct poubelle et je réécris. Et sur ce point, je ne voies personne qui me contredira...

Ensuite il y a les gens qualité qui vont me parler de normes ou autres restrictions permettant une meilleure lisibilité du code. La réalité est que les normes sont la pour cacher la médiocrité de certains d'entre nous, et arriver à générer du code quasi par copier-coller. Le résultat : des milliers de lignes de code, aussi asseptisées qu'inutiles. (La j'y vais un peu fort mais suis pas loin de ce que je pense en fait). En exemple, je dirais que la plupart du temps, quand je réécris un programme, le résultat tiens sur 1/10ème voir 1/100ème de sa taille initiale en lignes de code (sisi, c'est déjà arrivé). Non parceque j'écris condensé à l'extrême, mais simplement parceque mon code est "lisible". (Je rapprocherais cette remarque de l'exemple avec les 2000 lignes en copier-coller dans un if else).

A ceux qui disent ne pas vouloir travailler avec toi dans ce cas, je réponds qu'ils sont probablement de fervents adeptes des normes, documentations, et autres moyens de dissimuler leur manque de compétence/talent (ça me fait penser à un certain cabinet de consultant ça, spécialisé dans la documentation du pourquoi ils ne peuvent mener le projet à bien). Bon, tout ça pour dire que t'es doué pour l'info, comme d'autres pour le dessin, et que perso j'associe ça à de l'art.

Et à ceux qui voient toujours pas ce que je veux dire, j'aurais un exemple sympa : Faut il écrire une partition de musique (ou la jouer) avant de pouvoir la concevoir (l'entendre dans sa tête). Ptet que compter le nombre de notes d'un opéra les aidera se dire dire qu'il y a des gens qui peuvent faire ce qu'ils appellent "programmation spontanée".

En ce qui concernent les commentaires pour l'équipe ou une éventuelle modification ultérieure du code, la aussi, restons sérieux : La plupart du temps les commentaires que je lis dans le code sont aussi enrichissant que a=1; /* Affecte 1 à la variable a */

C'est certain ErwanVDF , un abus de commentaires peuvent entrainer un alourdissemet inutile de code.
Il serait préférable de les utiliser pour décrire les parties distinctes du code , marquer les blocs..

Si c'est mal écrit (commentaires ou pas) c'est direct poubelle et je réécris. Et sur ce point, je ne voies personne qui me contredira...

Direct poubelle comme tu dis j'ai été confronté à cela maintes fois malheureusement .

[Florian]

Envoyé par ErwanVDF

La réalité est que les normes sont la pour cacher la médiocrité de certains d'entre nous, et arriver à générer du code quasi par copier-coller

Vous devez être des surhommes les gars... il m'arrivent d'avoir du mal à comprendre mes propres développements 3 mois après, si je ne les ais pas documentés.
Il ne faut pas mélanger médiocrité et nécessité de ne pas batir de nouveaux étages de la tour de Babel. J'aimerais bien être un médiocre qui maitrise UML

La programmation spontanée, je n'en fait que pour les mods de phpBB, parce que c'est plus que court et assez "simple".

Envoyé par ErwanVDF

Bon, tout ça pour dire que t'es doué pour l'info, comme d'autres pour le dessin, et que perso j'associe ça à de l'art.

Les artistes sont souvent des incompris
Revenons brutalement à une réalité sordide : l'informatique qui me fait manger et paye mes crédits, je la préfère rectangulaire et grise mais fiable. Quand je veux faire des exercices de style, je fais des mods de phpBB.

Je précise que ceci n'est pas une agression.

[duj]

Faut il écrire une partition de musique (ou la jouer) avant de pouvoir la concevoir (l'entendre dans sa tête). Ptet que compter le nombre de notes d'un opéra les aidera se dire dire qu'il y a des gens qui peuvent faire ce qu'ils appellent "programmation spontanée".

Ceci est un exemple étrange, venant de vous, car

écrire la partition, correspond à la mise au propre, à l'implémentation concrète de ce que le compositeur a pensé !

Il est clair qu'avant de l'écrire, il l'a concue , que ce soit dans sa tête ou sur un morceau de papier.

L'avantage de l'écrire sur un bout de papier, c'est que s'il meurt on pourra continuer son oeuvre, ou simplement si il oublie quelque chose, il le retrouvera.

Je ne vois rien là, de spontané, la dernière chose qu'il a faite, c'est écrire la partition!

[hachesse]

ErwanVDF, j'espere aussi ne jamais a avoir a travailler avec toi.

Comment une personne qui reprend un de tes projets peu avoir la moindre idée du fonctionnement de celui ci sans relire (et ca m'etonnerais que ce soit si facile que caa faire) tout le code qui comme l'as dit neo peut representer plus de 800 000 lignes.

Autrement dit,il faudrat deja passer plus d'un mois pour lire une premiere fois le code et le relire combien de fois avant de le comprendre reelement

Est ce que je peut savoir avec quel langage tu developpes?
Car si je suit bien ce que tu dit, tu vas plus vite a lire le code que la doc, donc jamais tu ne lis ca ou ceci ou bien encore cela

[Admin]

Je suis d'accord avec Hachesse, sans parler du fait que tu fais comment quand tu a un pool de 15 developpeurs travaillant chacun sur un module qui doit se combiner parfaitement ?

Il faut bien des specs ?

Pour moi, travailler sans spec, ni documenter le code, c'est aussi grave que de pas developper l'application.

Va dire ça aux mecs qui bossent sur les softs de Ariane 5, à 1.000.000.000 d'euros le bug, tu fais des specs plutot deux fois qu'une.

ou alors, ceux qui bossent sur le méteor (Ligne du métro 14 entierement piloté par ordinateur pour ceux qui connaissent pas)?
400 vies humaines le bug.

Là tu utilise les mathématiques pour prouver que ton logiciel plantera pas.

[Catbull]

Envoyé par ErwanVDF

Et à ceux qui voient toujours pas ce que je veux dire, j'aurais un exemple sympa : Faut il écrire une partition de musique (ou la jouer) avant de pouvoir la concevoir (l'entendre dans sa tête). Ptet que compter le nombre de notes d'un opéra les aidera se dire dire qu'il y a des gens qui peuvent faire ce qu'ils appellent "programmation spontanée".

Pour reprendre la métaphore sur la partition de musique je dirais ceci : Imagine une personne capable de composer un opéra mais qui n'écrit jamais de partition. Personne d'autre que lui ne pourra jouer son morceau.

Ce n'est pas tout d'écrire un opéra, il doit pouvoir être joué. Il en va de même pour un programme informatique.

Ton argument sur les mauvais commentaires (a=1 // On affecte 1 à a) est fallacieux. De même qu'il existe une bonne façon de programmer, il existe une bonne façon de commenter. Lorsqu'il y a des commentaires inutiles tout laisse à penser que la programmation est douteuses... A l'inverse une personne qui sait programmer saura commenter judicieusement son programme...

Les commentaires sont loin d'être inutiles surtout si comme en Java il y a une multiplication de classes. Si l'algorithme mis en place est ardu, etc...

Pour ce qui est de la programmation spontannée, je pense que n'importe quel programmeur qui possède un minimum d'expérience peut coder à la volée un algorithme. Mais je doute que cet algorithme soit alors optimisé. De plus si cette algorithme s'avère complexe, il est souvent très utile d'oter les doigts de son clavier et d'utiliser un crayon...

[Admin]

Mon ancien chef avait un petit logiciel qu'il avait fait lui meme, ce programme sortait les commentaires d'un morceau de code.

Il les lisait comme ça, s'il comprenait c'etait bon, sinon fallait refaire les comments.

Je peut te dire que quand tu te tape 4 fois les commentaires sur une fonction de 2 pages, tu apprends à faire bien et clair du premier coup.

[claudus]

Juste qq mots pour décrire mon expérience perso: j'ai récupéré un gros projet il y a 6 mois.
Ce projet est commenté, mais très peu.
Je n'ai pas d'autres choix pour comprendre certaines partie que de lire le code en passant de classes en classes.
Il est peut être facile pour certaines personne de lire le code en l'intérpretant mentalement (à condition que ceux-ci l'ai écrit).
Mais je mets au défi qui conque de faire la même chose avec un code sans aucun commentaire, écrit par plusieurs autres personnes qui ont chacun leur style d'écriture.

Reprende un gros projet bien commenté n'est pas tjrs chose facile, mais un projet non commenté, vive la gallère.

Et les commentaires ne suffisent bien souvent pas, sans un dossier d'analyse (j'ai pas dis 3 fardes, bien souvent qq pages suffisent) ne fusse que pour préciser les spécifications de l'application, où en est le projet, ce qui est fait et ce qu'il reste à faire.

Il faut toujours garder en tête que, idéalement, dans un projet ou plusieurs personnes travaillent, le jour ou un personne tombe malade ou quitte la société, le projet devrai pouvoir continuer comme si de rien n'étais. (j'ai bien précisé : idéalement)

Pour moi la méthode de la programmation spontannée ne peut être utilisé quand pour les petites projets ou les bricolages.
Pour un gros projets il est impossible de garder en tête tout les éléments.

Reprende un gros projet bien commenté n'est pas tjrs chose facile, mais un projet non commenté, vive la gallère.

Claudus, je crois que c'est malheureusement le lot de tout le monde.
Nul n'est parfait , toi et moi, mais c'est vrai qu'avec un peu de rigueur..
C'est malheureusement légion concernant les projets informatiques.

Il faut toujours garder en tête que, idéalement, dans un projet ou plusieurs personnes travaillent, le jour ou un personne tombe malade ou quitte la société, le projet devrai pouvoir continuer comme si de rien n'étais. (j'ai bien précisé : idéalement)

L'idéal serait , comme sans doute il a été précisé auparavant , de "sectoriser" ou modulariser le projet en modules bien distincts.
C'est ça le travail en équipe : chacun travail sur un module bien distinct.
Et c'est pour cela que la POO , Modula, C++,Java et consorts ont été crées, ainsi que méthodologie comme UML.

On peut faire l'analogie avec la construction d'une voiture.
Une équipe pour la carrosserie , une autre pour l'électricité , une autre pour la peinture.
Si lorsqu'on met le contact et qu'il n'ya pas de voyants alors on sait d'où le problème provient.
Bon c'est des banalités certes mais pourquoi les projets informatiques ne sont-ils pas "construits" correctement ?
Serait-ce à cause d'un côté "artisanal" ?
Mais c'est une autre histoire

[ErwanVDF]

lol,
Cool, y a de l'animation. Bon, voudrais quand même tempérer mes propos. Je bosse en général sur de gros projets UML/C++ Client/Serveur.
Il est évident que je conçois d'abord un cahier des charges, que je fais une analyse papier, et de la documentation...
Mais il est vrai aussi que j'essaie de fournir les spécifications des modules aux développeurs avec qui je travaille en fonction de leurs aptitudes. A certains je donne juste l'entrée/sortie et l'info fonctionnelle, à d'autres je vais détailler l'algorythme.
Ce que j'entends par programmation spontanée, je le répète, c'est la faculté de pouvoir concevoir rapidement une structure solide mentalement. Ce qui n'empêche pas de poser l'algo sur papier pour résoudre une difficulté précise ressentie. Je pense que cette façon de coder est lié à l'expérience et à la faculté de "faire tourner le code dans sa tête".
Je lis effectivement couramment le code (écris par moi ou par d'autre). Mais la encore, la vitesse de lecture dépend de sa lisibilité. Sur un code bien pensé, la structure est claire et le code peut être lu "en diagonal".

Pour ce qui est de l'exemple de la partition de musique : le code écrit correspond à la partition... Je comparerais les commentaires aux annotations de l'auteur sur la partition. UML ou les langages de développements ne sont que des notations communes permettant d'exprimer un concept, un algo...

[Doloop]

Merci beaucoup ErwanVDF d'avoir consacré de ton temps à répondre, et de me redonner un petit peu de crédibilité.
Tu as fort bien expliqué le fonctionnement de la programmation spontanée.

La programmation spontanée se vie, mais ne s'explique pas fondamentalement, elle fait partie de nous.

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).
Le simple fait de se concentrer permet de voir immédiatement non seulement la solution, mais les solutions. Il suffit ensuite d'effectuer son choix par rapport aux besoins futurs du programme.
J'ai même cru qu'un moment que ces visions aller finir par s'arrêter un jour ou l'autre, mais ceux-ci se sont amplifier et solidifié avec l'expérience.
Cela me fait penser au jeu d'échecs, où l'on aurait déjà précaunisé toute la stratégie de mise à mort de l'adversaire.

Les chiens ont une mémoire sélective en ce qui concerne l'odorat, ils peuvent se fixer sur une seule odeur et la suivre à la trace. Pour la programmation spontanée, c'est un peu la même chose on se fixe sur un détail, on ressent en parcourant le programme, l'endroit de ce que l'on recherche, pour finir par le trouver. L'intuition reprend le relais.
Le programme que l'on a conçu, il est en nous, en le parcourant c'est un peu comme si l'on se promenait dans sa tête.
A la création de mon premier programme, je me suis laissé dépasser comme tout novice, entre tout ce qu'il fallait faire pour le réussir, et en en même temps de découvrir toutes les possibilités algorithmiques par moi-même.
La seule envie finale, c'était de surpasser le programme, pour que ce ne soit plus le programme qui nous dépasse.

En ayant commencé par réaliser un logiciel sans aucune connaissance solide, l'immensité de ses possibilités et de sa complexité ma bouffé la tête au départ, je ne m'en cache pas, il était difficile de savoir par quoi commencer. Maintenant, mentalement je ne force plus. Lorsqu'il y a vraiment une difficulté d'un truc que l'on souhaite faire et que l'on ne sache pas encore faire, en se concentrant je ressens un flash (<1s) qui s'apparente à de la simulation accélérée, représentant la meilleure solution pour y parvenir, pour le reste c'est toujours la même chose, on sait déjà.
S'il y avait un bug, on part du principe qu'on va le trouver, il n'y a pas d'inquiétude. Au contraire cela met un petit peu d'action, ce qui n'est pas un mal en soi, il y a des limites, il faut les atteindre pour savoir où elles se situent.
Lorsque je fais un programme, je ne m'attend pas à ce qu'il fonctionne parfaitement du premier coup, mais on va adapter sa programmation par rapport au résultat obtenu en déterminant les éléments fautifs à son dysfonctionnement.

Il m'est déjà arrivé de continuer à débugger un programme l'ordinateur éteint, on l'allume est c'est bien ça.

J'ai remarqué que conduire une voiture pour moi, nécessitait plus d'effort d'attention cérébral, que de passer une journée entière à programmer et à débugger.

Récemment j'ai reporté la méthode sur l'électronique, et j'obtiens des résultats de fonctionnement identique. Dernièrement j'ai réalisé 3 cartes d'interfaces pour n'en former qu'une au final, en dessinant directement les typons en reliant manuellement les pattes des composants sur un logiciel de CAO : soit au total + 50 composants dont + 20 de différents. Tout fonctionne bien sur le port parallèle en bidirectionnel, il n'y a pas eu de modification.
Ce qui veut dire que le spontanéisme, ne s'arrête pas à l'informatique.

Lorsque l'on reussit quelque chose en tant que débutant, on resent une auto satisfaction, tout le monde y est passé. Maintenant, à chaque programme réalisé, l'auto satisfaction est quasi inexistante, on est content que le programme soit terminé, on n'est pas déçu mais sans plus, on pense plus au prochain qu'a celui qui vient d'être fait.

Sur les forums je vois pour faire de l'informatique, il faut être bon en math. Ce n'est pas mon cas ce serait même le contraire et cela ne me gène pas, peut être que cela peut aider dans des domaines spécifiques mais je ne me sents pas concerné.

Cela fait maintenant + de 8 ans que je programme spontanément, rajouter des commentaires ne me gènent pas et comme l'a bien fait comprendre ErwanVDF, à condition que ce ne soit pas n'importe quoi non plus.

Il était voir impossible d'être le seul dans cas là, l'auteur du livre qui annonçait 10 % des programmeurs qui avait le potentiel ne devait pas se tromper à son époque, chez certain il faudra plus de temps pour que cela se développe, il ne suffit que d'un facteur déclencheur.
Je respecte tout à fait les autres programmeurs qui emploient une autre méthode, ils sont très méritants, il faut programmer avec la manière qui nous correspond le mieux, ce qui est important c'est de parvenir au résultat.

Le dicton du jour : Heureux est celui qui programme ce qu'il veut.

Bonne continuation à tous. Et que l'alignement des octets de vos programmes vous soit favorable.

@ +

[hachesse]

Doloop, t'es quand meme pas serieux j'espere.

Tes methodes de travail relevent plus de la sorcelerie vaudoo que de l'informatique.

J'aimerais vraiment voir la qualité des logiciels que tu produit et les efforts que doivent faire les équipes qui doivent les maintenir

[iubito]

Pour l'exemple musical de la partition écrite en "entendant" la musique dans sa tête, c'est tout à fait possible.

En fait on distingue 2 catégories de musiciens :
1) ceux qui ont "l'oreille relative", ils font 3000 essais sur la guitare ou sur le piano pour savoir si une mélodie va bien, placent de magnifiques accords super tordus mais sans avoir rien calculé ni sans connaître leur nom, mais juste parce que "ça sonne bien".
Quand ils composent, ils doivent avoir joué avant

2) ceux qui ont l'oreille absolue, en entendant un accord ils vont le calculer (dans l'genre : "alors là y'a Do-Mi bémol-Fa#... ça fait du Do diminué"...). Ils sont capables d'écrire une partition sans avoir essayé avant, mais en l'écoutant dans la tête. Alors y'a parfois quelques ratures, mais ils sont capable d'écrire en respectant tout un tas de lois (tritons, quintes parallèles, et j'en passe...)
Ce sont plus des calculateurs, et paraît-il qu'ils perçoivent moins le côté "beauté" de la musique...

Bein en informatique c'est pareil !

Il y a ceux qui doivent essayer avant => écrire un algo, faire de l'UML, modéliser à mort...
et il y a ceux qui, bien évidemment sur un gros projet doivent se représenter le déroulement écran par écran, mais sont capables de concevoir tout l'algo dans leur tête et d'arriver devant le PC de tout écrire directement.

Perso je suis dans la 2e catégorie, que ce soit en musique ou en programmation.
Avant de commencer, je me représente quels écrans, quel enchaînement il va y avoir dans mon projet... donc je défini un peu de manière globale.
Et puis après j'enchaîne sur la programmation.

En musique, certains arrivent à déchiffrer une partition à la première lecture (si la partition est bien imprimée et que c'est pas de l'arrache-yeux pour lire), ça peut être pareil en programmation (si le code a quelques commentaires pour comprendre le sens d'un "paragraphe", ou pour expliquer une ligne complexe, et si le code est bien écrit pas tout entassé, délimité, aéré).


Alors quand on écrit spontanément, et qu'on a quand même réfléchi avant au déroulement du programme, je trouve qu'on a plus de liberté d'ajouter un nouveau truc (avec l'expérience on code bien donc on peut le faire).
Alors que quand j'ai fait une grosse séance (8 semaines) de Merise pour un projet à l'IUT, 1) au bout d'un moment on s'aperçoit qu'on a un truc bloquant, 2) quand on code... bein parfois on se demande bien ce qu'on a pu écrire sur notre schéma !
Vu la taille du projet, on était obligé de faire de l'analyse, mais parfois les collègues cherchaient à schématiser un truc, alors que moi je me disais "bon bein là il suffit de mettre un flag à 1 dans la base de donnée" des trucs tout con comme ça