Au Pied Levé - À Main Levée

Forum -► Général Développement -► Débats sur le développement – Le Best Of

[Discussion] Qui pratique la programmation spontanée ?

■ ■ ■ SOMMAIRE ■ ■ ■

• AVANT-PROPOS
  
  • L'appropriation
  • Processus créatif
  • Citations sur la créativité
• L'AVIS DES ADEPTES
  
  • Envoyé par ErwanVDF
  • Envoyé par epeios
  • Envoyé par barjy
  • Envoyé par zecreator
  • Envoyé par 2Eurocents
  • Envoyé par mumen
  • Envoyé par d’autres adeptes (glanés sur la discussion)
• CITATIONS À MÉDITER

Ce billet rassemble les avis les plus développés de certains membres et cite quelques autres avis brefs mais pertinents.

AVANT-PROPOS

En 2003, lorsque Doloop initie cette discussion, c’est un professionnel qui a huit ans d’expérience. Ses détracteurs qui lui opposent des arguments du genre spécificités et commentaires, le considèrent manifestement comme un demeuré. Quel informaticien en 2003, peut-il ignorer ses classiques ? Si Doloop évoque sa démarche de développement, c’est qu’il a tout simplement envie de partager son expérience, de confronter son ressenti avec d’autres adeptes.

La programmation spontanée n’est pas du tout incompatible avec un contexte de développement conventionnel. Il n’y a pas d’alternative binaire « programmation spontanée » ou « programmation conventionnelle ». La programmation spontanée est une qualification, une expertise à la fois personnelle et professionnelle. C’est un savoir-faire acquis par la réflexion et l’expérience.

La question des spécificités soulevée par certains détracteurs est un faux problème. Quel que soit le contexte de développement, avec ou sans spécificités, en équipe ou en électron libre, le développeur-programmeur est toujours seul dans sa tête.

La programmation spontanée commence par l’appropriation mentale de la problématique. Les spécificités n’existent pas ? Le développeur-programmeur les rassemble, les invente, les concrétise au fur et à mesure qu’il programme. Des spécificités existent (cahier des charges ou analyses), le développeur-programmeur s’approprie la problématique à partir de ces sources. Peu importe la méthode d’analyse des besoins, la façon dont sont exprimées les spécificités, le développeur-programmeur s’en imprègne, se les approprie en les traduisant dans son propre langage mental. Dans les deux cas, le développeur-programmeur est en capacité de programmer spontanément.

■ L'appropriation

L’appropriation mentale d’une problématique ou imprégnation pour Younid [#453], équivaut à la préparation mentale de l’athlète qui se sophronise avant un objectif important. Pour le programmeur, l’appropriation se limite à une fonctionnalité, un programme, une analyse. Pour le développeur, l’appropriation n’a pas de limites, il s’approprie la problématique dans son intégralité.

L’appropriation, c’est entreprendre et assumer pleinement la responsabilité de ce que l’on entreprend.

Pour le Développeur-programmeur, développer-programmer, c’est d’abord un challenge, un contrat moral avec une obligation de résultat assumée. Dans cet esprit, l’appropriation, c’est cette détermination du développeur-programmeur à assimiler mentalement les spécificités d’une problématique (stipulées ou à investiguer) et à les reformuler dans son mode de pensée, à les traduire dans son langage mental, en projection du résultat à obtenir.

Il y a plusieurs façons d’exprimer l’appropriation :

• « L'unique façon sérieuse de comprendre quelque chose est de devenir soi-même ce que l'on comprend. » - Soren Aabye Kierkegaard
  
  
• « On ne peut peindre le paysage sans être soi-même dans le paysage. » - Les peintres lettrés chinois
  
  
• « Pour bien peindre la montagne, il faut devenir la montagne. » - Proverbe chinois
  
  
• « Il ne s’agit pas de penser à une solution mais de vivre et ressentir une solution.
  C’est arriver à se mettre dans les chaussures de l’autre. » - Bruno Bettelheim, Psychiatre américain

L’expérience est au cœur des leçons de vie, lesquelles se muent ensuite en sagesse. C’est ce qui rend cette dernière si difficile à enseigner : l’expérience ne s’apprend pas, elle se vit. Ou plutôt, elle s’apprend en se vivant.

■ Processus créatif

L’effort mental inhérent à la pratique de la programmation spontanée, devient vite un processus créatif addictif. Certains membres évoquent ce ressenti dans leurs messages :

Envoyé par cedricgirard

Étant attiré par l'écriture romanesque, et pour ce que j'ai lu sur divers auteurs, la manière de faire d'un développeur et d'un écrivain n'est pas si éloignée.

Envoyé par Rafy

Je suis très loin de mon PC ces temps-ci, je n'ai jamais autant eu envie de programmer qu’en ce moment. Je me rends compte maintenant que programmer c'est comme une drogue.

Envoyé par davcha

En fait, il y a des gens qui sont créatifs, qui ont besoin d'être créatifs. Il y a quelques années, ça me déprimait d'avoir lézardé pendant 2 heures durant une journée, il fallait que je "fabrique" quelque chose tout le temps.

Envoyé par LadyWasky

… Enfin, je suis aussi un accroc du développement.

Envoyé par zecreator

Je préfère garder du temps à ma créativité et ma veille technologique, à l'élaboration de nouvelles techniques, qui me permettent de m'épanouir dans mon métier de développeur.

Pour ma part, une journée sans avoir créé aurait été une journée de ma vie que j’aurais gâchée. Je crée tous les jours, c’est un besoin vital.

■ Citations sur la créativité

• « La créativité est une habitude, et la meilleure créativité est le résultat de bonnes habitudes de travail. » - TWYLA THARP
  
  
• « Je ne crois pas que programmer n’est pas créatif. Je pense qu’une part de structure est nécessaire à la créativité. » - TWYLA THARP
  
  
• « Être créatif est un travail à temps plein avec ses propres routines quotidiennes. C’est la raison pour laquelle les écrivains, par exemple, aiment se fixer des routines. » - TWYLA THARP
  
  
• « La créativité n’est pas limitée aux arts, c’est une façon de vivre la vie. » - MADELEINE L'ENGLE
  
  
• « La créativité peut être décrite comme l’abandon de ses certitudes. » - GAIL SHEEHY
  
  
• « Vous ne pouvez pas épuiser la créativité. Plus vous l’utilisez, plus vous en avez. » - MAYA ANGELOU
  
  
• « Lorsque nous nous engageons dans une chose pour laquelle nous sommes naturellement doués, notre travail prend l’apparence d’un jeu et c’est le jeu qui stimule la créativité. » - LINDA NAIMAN
  
  
• « La créativité est essentiellement un art solitaire. C’est la capacité à puiser en nous, à extraire une idée de notre âme même. » - LOU DORFSMAN
  
  
• « Rendre compliquées les choses simples est à la portée de tout le monde. La créativité, c’est rendre simples les choses compliquées. » - CHARLES MINGUS
  
  
• « La créativité c’est inventer, expérimenter, grandir, prendre des risques, briser les règles, faire des erreurs et s’amuser. » - MARY LOU COOK
  
  
• « La créativité implique de briser les conventions afin de regarder les choses sous un jour nouveau. » - EDWARD DE BONO
  
  
• « Faites de la place dans un coin de votre esprit et la créativité va immédiatement le remplir. » - DEE HOCK
  
  
• « La créativité c’est percer le banal pour trouver le merveilleux. » - BILL MOYERS
  
  
• « Une intuition, c’est la créativité qui essaye de vous dire quelque chose. » - FRANK CAPRA
  
  
• « La créativité s’exprime autant lorsque l’on compose un morceau de musique que quand on écrit un programme informatique, qu’on organise un événement ou qu’on décore son appartement. Dès qu’il n’existe pas de solution unique pour résoudre un problème, il y a de la place pour la créativité ! ». - Bastien Wagener
  
  
• « Ce qui me fait survivre, c’est la création. Créer quoiqu’il arrive, ou la musique, ou la peinture, ou la littérature, la poésie, la sculpture… mais surtout pas de stagnation, sinon c’est foutu ! » - Serge Gainsbourg

L'AVIS DES ADEPTES

Envoyé par ErwanVDF

30/12/2003, 04h05 #16

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 ce 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 là.

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 soi-disant gros projets ayant fait l'objet d'une analyse détaillée préalable, restons sérieux et ne nous voilons 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 : faisons déjà le reste… résultat, le produit est mal pensé, mal structuré, et le corollaire 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 algorithme ou de poser la chose sur papier au préalable. J'ai une 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'assois 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 sont déjà dans ma tête, en tout cas pour la majeure partie.

Ceux qui disent que ce n'est applicable que sur des petits projets :

1. n'ont jamais travaillé sur un gros projet,
2. n'ont jamais mené un gros projet non caduque à terme.

En ce qui concernent les commentaires pour l'équipe ou une éventuelle modification ultérieure du code, là 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 il y en a pour 2 minutes (et oui, 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 vois 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 là 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 aseptisées qu'inutiles. (Là 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 tient sur 1/10ème voir 1/100ème de sa taille initiale en lignes de code (si, si, c'est déjà arrivé). Non parce que j'écris condensé à l'extrême, mais simplement parce que mon code est "lisible". (Je rapprocherais cette remarque de l'exemple avec les 2.000 lignes en copier-coller dans un "IF ELSE").

À 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'informatique, comme d'autres pour le dessin, et que personnellement j'associe ça à de l'art.

Et à ceux qui ne 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). Peut-être que compter le nombre de notes d'un opéra les aidera à se dire qu'il y a des gens qui peuvent faire ce qu'ils appellent la "programmation spontanée".

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

Envoyé par epeios

31/12/2003, 12h40 #36

Vive la programmation spontanée !

Cela fait des années que je pratique la programmation spontanée et cela me convient parfaitement.

Pour pratiquer ce genre de programmation, il faut disposer des outils adéquats, c'est-à-dire à la fois du bon langage et des bonnes bibliothèques. Pour ma part, j'utilise C++ comme langage et pour ce qui est des bibliothèques, comme je n'en ai trouvées aucune qui me convenait, je les ai conçues moi-même.

Grâce à ces outils, écrire un programme consiste simplement à écrire les différents algorithmes mis en œuvre directement dans mon éditeur, sans passer par l'étape papier. Dès lors, les commentaires deviennent superflus, puisque la correspondance entre lignes de codes et algorithmes mis en œuvre est directe, et donc n'a pas à être précisé par un commentaire. Si, malgré cela, des commentaires sont nécessaires, c'est que l'algorithme en lui-même pose problème, et non pas son implémentation.

Les seuls cas ou je recours à des commentaires (ou du moins le devrais), c'est pour du code rendu incompréhensible suite à une optimisation, ou du code dépendant du système utilisé, comme pour la programmation des sockets, ou encore du multitâche, entre autres.

Bien sûr, il arrive parfois que j'ai du mal à comprendre mon propre code, mais cela ne me pousse pas pour autant à remettre en question ma manière de programmer (notamment en ce qui concerne l'absence de commentaires). Pour moi, cela signifie simplement que l'algorithme implémenté n'est pas bon, et ce qui me paraît alors obscure dans mon code me met généralement sur la piste d'un nouvel algorithme qui clarifie le code incriminé.

Mais cela m'arrive rarement de ne plus comprendre mon propre code, car au moment même où je l'écris, je sens s'il risque de me poser ce genre de problème. Même si je le laisse à ce moment là en place, et même s'il est entièrement satisfaisant par ailleurs, ça ne cessera pas de me turlupiner jusqu'à ce que je trouve (cela prend des semaines parfois) et mette en place un autre algorithme qui me satisfasse.

Encore une fois, cette manière de procéder n'est possible qu'avec les outils adéquats mais également une grande discipline. À titre d'exemple, il n'y a pour ainsi dire pas de boucles "FOR" dans mes sources, et je déporte tout groupe d'instructions pour lesquelles cela a un sens dans une fonction dédiée ce qui me contraint, et ce n'est pas toujours évident, à trouver des noms de fonctions explicites, et n'est-ce pas là, après tout, l'équivalent des commentaires qui devrait accompagner ces instructions si je les avais laissées dans la fonction appelante ? Cela facilite la lecture des fonctions que j'écris, puisqu'elles ne comportent chacune que relativement peu d'instructions.

Puisqu'une comparaison a été faite entre musique et informatique, étant moi-même musicien et compositeur durant mes loisirs, je me permets d'en toucher quelques mots. Bien plus que les aspects purement techniques des programmes que j'écris, c'est la cohérence, l'harmonie, la beauté serais-je tenté de dire qui s'en dégagent du fait des algorithmes utilisés et de leurs enchaînements qui m'apportent le plus de satisfaction. Ce que je ressens en écrivant un logiciel dont je suis satisfait est comparable à ce que je ressens lorsque je compose une œuvre musicale et constitue la principale motivation du fait que je m'adonne à ces deux activités. Et, comme vous pourrez le constater en vérifiant la date à laquelle il a été posté, ce message a été écrit la veille du nouvel an, et je ne suis donc pas (encore) sous l'influence de substances plus ou moins licites, comme pourraient peut-être le penser certaines personnes à la lecture de ce dernier paragraphe (ou de ceux qui précèdent).

Envoyé par barjy

23/08/2006, 16h25 #202

Un peu sur les fesses...

Salut à tous...

Bien que nouveau (sur le forum, pas dans la programmation), je ne peux qu'être étonné :

• des chtis étudiants qui avalent tout ce qu'on leur dit et le répète sur ce forum,
• des moins débutants à qui il faut absolument passer par l'UML avant d'attaquer un projet, ne serait-ce que de quelques "dizaines de milliers de lignes",
• de la façon dont on ne répond pas à l'auteur de ce message,
• etc.

Donc, oui, je pense que "nous" (développeurs "spontanés") sommes une exception... par contre l'amalgame entre "développeur spontané" et "gens qui codent comme des porcs" est un peu trop facile...

Certes, à votre décharge, on vous bourre le mou pendant toutes vos études sur des concepts qui, au final, dans quelques années, seront totalement dépassée...

En gros, vous imaginez le "codeur spontané" comme celui qui n'arrive pas à s'intégrer dans un projet ! Pire ! Vous imaginez le "codeur spontané" comme celui qui ne pourra aucunement mener un projet à bien...

Et pourtant !

Vous avez simplement du mal à accepter que tout le monde ne travaille pas de la même façon et que certaines personnes sont capables d'imaginer / mettre en place des architectures complexes sans devoir les écrire sur papier...

Au final, c'est une certaine forme de rejet (de jalousie) de cette minorité de personnes qui ont l'informatique dans les tripes...

Programmer de façon spontanée ne veux pas dire ne pas avoir de réunions de suivi, de définition d'objectifs, de se mettre d'accord avec les autres.

Envoyé par zecreator

19/09/2006, 13h51 #229

En fin de compte, la meilleure méthode de développement n'est t-elle pas celle que l'on maîtrise le mieux. Pourquoi une méthode serait-elle plus efficace qu'une autre, si le résultat et la possibilité de modifier le projet sont là ?

Comme le dit waskol, est-ce parce qu'un homme a décrété que sa méthode était la meilleure qu'il faut l'utiliser ?

Est-ce que dans les petites structures nous donnons du temps aux développeurs de faire des diagrammes UML ? Je ne pense pas.

Productivité et rentabilité sont les méthodes les plus couramment rencontrées. Et aujourd'hui, quand on voit comment son codées les applications dans les SSII, par briques de codes, peut-on encore croire en une méthode puriste de développement ?

UML, schémas, organigrammes ne risquent-ils pas de finir par être utilisés comme des "faire-valoir" plus que par des processus utiles ?

Je développe spontanément, à la demande, on me félicite de mon travail et je m'en félicite. Le reste n'est que formatage et prise de tête.

Envoyé par zecreator

21/09/2006, 23h18 #235

Je reconnais l'efficacité de développer avec des formalismes, seulement, il ne faut pas que cela devienne une religion, où celui qui ne suit pas les règles est un hérétique.

Le développement doit surtout se faire avec passion, et avec la méthode que l'on maitrise le mieux.

Développer avec tous ces formalismes reste une image d'Épinal. J'ai rarement eu le temps nécessaire ni les moyens de mettre en place de tels formalismes.

Si vous pouviez me dire comment vous faites pour sortir 15 pages de diagramme, 30 pages de cahier des charges, 50 pages de story, 100 pages de cahier technique, et fournir l'appli au bout de 2 mois, je serais ravi.

Envoyé par zecreator

27/09/2006, 11h06 #241

Pour revenir sur la question d'origine "Qui pratique la programmation spontanée ?", je réponds "MOI".

Pour compléter ma réponse, je dirais que même si j'admets que ce n'est pas la meilleure des méthodes de développement, c'est certainement celle qui permet une réelle liberté créatrice.

Pour avoir pratiqué pendant des années le développement que j'appellerais "formaté", j'ai constaté que ça ne m'éclatait pas de passer mon temps à faire des diagrammes UML, des organigrammes, des plans et tout le bazar.

Pas par un manque de compétences, juste que j'avais plus vite fait de développer l'application une fois le story-board effectué, car j'avais déjà schématisé toute la technicité dans ma tête. Rien ne m'empêche de documenter mon application, avec quelques commentaires dans le code, un p'tit doc PDF...

Encore une fois, ce n'est pas la meilleure méthode de développement. Comme toute méthode elle a ses faiblesses, et je pense qu'elle n'est praticable que par des personnes ayant une bonne maîtrise des technologies, et une motivation à acquérir des nouvelles connaissances techniques.

Mon expérience sur de gros projets m'a permis aussi de constater que les formalismes sont surtout l'affaire de temps et d'argent. Dans les domaines comme la finance ou l'assurance, je comprends très bien la volonté de "traçabilité" des applications et des délais très serrés (compétitivité oblige).

Mais cela se ressent terriblement dans l'ergonomie des interfaces, la créativité et l'ergonomie sont deux facteurs manquants, qui semblent avoir été totalement rayés dans ces domaines (je vais me faire taper dessus je le sens).

Et pour cette raison, je préfère passer pour un développeur moins "pro", et continuer de développer spontanément...

Bref, je préfère garder du temps à ma créativité et ma veille technologique, à l'élaboration de nouvelles techniques, qui me permettent de m'épanouir dans mon métier de développeur.

Envoyé par zecreator

10/10/2006, 10h02 #308

Je pense que ceux qui pratiquent régulièrement la programmation spontanée, ne sont pas forcément des génies mais qu’ils ont sûrement la capacité d'analyser rapidement un besoin et de concevoir une solution. Je pense aussi, je prends mon cas, que ce sont des personnes qui aiment expérimenter des nouvelles techniques et qui peuvent passer beaucoup de temps sur un bout de code. Et pour finir, ce sont des personnes qui ne manquent pas de ressources et peuvent utiliser une large palette d'outils de développement différents.

Envoyé par 2Eurocents

02/10/2006, 11h10 #269

"Dali peignait après avoir effectué ses tracés au crayon. Picasso se lançait directement au pinceau. Et pourtant, c'est 2 fabuleux artistes..."

Dans ce domaine, une anecdote - attribuée à Rembrandt mais ça demande à être vérifié - ou plutôt une belle histoire :

Le peintre reçut un jour, un bourgeois de la ville qui lui demanda de peindre le portrait de sa fille. Le peintre accepta, fixa un prix prohibitif à la commande - que le bourgeois accepta - et fixa un rendez-vous six mois plus tard.

Le commanditaire n'entendit plus parler du peintre jusqu'au rendez-vous. Le jour dit, le peintre arriva chez le bourgeois avec chevalet, toile et peinture, convoqua le modèle et en peint le portrait en une journée.

Au moment du paiement, le bourgeois, satisfait du portrait, mais vexé que sa réalisation en fut si rapide, refusa de payer le tarif convenu. Il estimait qu'une journée de travail, fusse d'un artiste, ne valait pas ce prix.

Le peintre le traîna alors jusqu'à son atelier, lequel était jonché d'esquisses, de croquis de la fille pris "au naturel", d'études de drapés, de lumières, etc.

Le commanditaire comprit alors que l'œuvre qu'il avait vu naître en une journée n'était que l'accomplissement d'un travail excessivement important et totalement invisible à ses yeux.

Je respecte celui qui peut pratiquer la "programmation spontanée" à la manière de ce peintre : se jeter sur le code et le "cracher", valide du premier coup parce qu'étudié auparavant dans les moindres détails, pratiqué, éprouvé de nombreuses fois au préalable, etc. Le codage n'est alors pas si spontané car le développeur a appliqué un ensemble de méthodes, de canevas, voire de "design patterns" dont il a la parfaite maîtrise.

Celui-ci, en général, est aussi capable de réaliser, à posteriori, les documents et formalismes nécessaires à une reprise du code par un tiers ou à une date ultérieure.

Par contre, celui qui pratique la "programmation spontanée" en n'ayant pas d'idée préconçue, pas de plan d'attaque, pas d'expérience préalable du domaine, va - à mon avis - droit dans le mur sur le long terme.

Celui-là construira des programmes dont on peut douter des possibilités d'évolution, d'intégration et de maintenance. La vision d'ensemble qu'il aura de son programme sera un patchwork de résolutions individuelles de petits problèmes rencontrés au fur et à mesure du codage.

Finalement, on en vient à opposer deux approches du codage :

• Le "top-down", qui consiste à prendre le problème dans son ensemble et à le décomposer jusqu'à obtenir les éléments atomiques que l'on codera.
  
  
• Le "bottom-up" qui consiste à construire l'application pièce par pièce, en les codant "spontanément" l'une après l'autre.

Ces deux approches sont aussi opposées en conception (au sens "mécanique", "bureau d'études") et même si chacune peut avoir ponctuellement des avantages par rapport à l'autre, cela reste une querelle sans fin.

Envoyé par mumen

05/04/2013, 18h40 #467

Si cela vous plait, goûtez ma prose sur ce sujet cru, si bien tenu comme le sont les sujets sur DVP, malgré les forces antagonistes en présence ! Je vous la propose en deux parties :

• une pratique ici tout de suite, où je m'exprime du fond du cœur de développeur,
  
  
• une théorique ensuite, m'appuyant sur une science dite humaine, la typologie des caractères, qui est discrètement devenue plutôt dure - objective est le mot consacré -, par la grâce de la neuropsychologie, sous l'appellation de styles cognitifs.

PROGRAMMEUR SPONTANÉ

Je me situe sans aucun doute dans la même catégorie que tous ceux qui disent ici être programmeurs spontanés. Je ne me reconnais pas complètement dans cette appellation, mais quand même, c’est pas mal. En fait, je n’ai pas de flash, le code que je tape, je n’en sais rien avant de le taper, il se met en place en cycles d’essai/erreur, je me sens plus interprète de quelque chose qu’acteur volontaire. Je sais globalement où je veux aller et ça va où ça doit, sinon, c’est que je me suis trompé d’objectif. Je découvre plus que je n’invente, c’est une posture passive, attentive.

J’ai de profondes difficultés avec l’abstraction, je le sais. Quand je dois réfléchir à une modélisation, à un algorithme, je ne le fais pas avant, je le fais pendant. Je code et je regarde ce que ça donne, ensuite je rectifie. Si je travaille pour le client, c’est la même chose, sauf que c’est lui qui me dit si j’ai bon. En fait, quelque part, c’est toujours lui qui me dit si j’ai bon. Je réécris toujours les algorithmes clés plusieurs fois, parfois sur des années, avec un objectif multiple : clarté dedans, clarté dehors, largeur de champ, ne pas y revenir, utiliser, oublier. Ce n’est pas de la perte de temps pour tous les esprits. Cela s’appelle aussi de la re-factorisation, je l’ai appris récemment.

Il m’arrive parfois de modéliser sur le papier. C’est très rare. Si cela arrive, c’est qu’il s’agit de choses excessivement complexes pour moi. Je fais des petits dessins au crayon de bois et avec une gomme. Quand c’est fini, je n’ai généralement plus besoin de mon dessin pour faire ce que j’ai à faire. Je le garde dans un coin, parce que je trouve ça amusant, le résultat de toutes ces heures passées dans un métro, dans la rue ou bien à table, à penser à un truc qui est finalement devenu tellement évident, que ce bout de papier n'est plus que l’empreinte dérisoire d’un long et pénible travail de tâcheron. Pour moi, l’analyse est quelque chose de magique. Le fait d’avoir anticipé une chose qui s’avère exactement coller à la réalité quand elle est réalisée me laisse éperdu d’admiration. L’analyse, ce n’est pas mon art, mais alors pas mon art du tout. Je suis tellement mauvais à ce jeu-là que j’ai dû développer des outils extraordinaires, à la mesure de mon incurie, pour pouvoir assurer en clientèle. En fait, c’est pour développer des outils que je suis bon. Là mon cœur bat. Outilliste je suis, outilliste je reste.

Mon code est moche, mais il s’améliore tous les jours, c’est vital. Mon code n’est pas commenté du tout. Comme je réécris toujours tout, mes commentaires deviennent aussitôt faux. Ils ne sont pas fiables alors j’arrête avec ça. J’ai lu dans ce fil une affirmation qui a peut-être le pouvoir de changer quelque chose à ce fait, qui m’est apparue tellement évidente qu’elle s’est gravée en moi, développeur toujours en devenir : #51 « On ne commente pas le code, mais l'algorithme ». Génial. En attendant, je m’y retrouve toujours dans mon code, mais j’ai dû batailler contre moi-même, pour être plus rigoureux. Je développe « en live » une bibliothèque depuis 18 ans. Par endroits, dans cette bibliothèque, on peut voir les séquelles d'avant ces évolutions que je me suis imposées avec le temps : ici du code indenté sur une seule espace ; là un code sans déclaration de variables ; ailleurs pas d’introducteur de type avec mes variables, etc.

Pour moi, la plus grande difficulté de ce métier de développeur réside dans le nommage des entités. J’ai choisi le style « Camel Case » et je suis toujours en quête du bon mot. Je peux passer pas mal de temps, simplement à renommer plusieurs fois un code difficile pour moi. En 25 ans de pratique, j’ai atteint une espèce de sagesse qui me tient lieu de méthodologie. À mes yeux, la plus belle invention récente de structuration du code, d’amélioration de la lisibilité et de mise en perspective des parties de la procédure, c’est le bloc d’instruction With/End With qui va de pair avec l’objet. Son emploi réfléchi indique naturellement quelles variables intermédiaires il faut créer pour que le code soit « à l’aise ». Elle aère le code, le rend lisible et lui donne une cohérence dans l’accès des entrées/sorties. Bien sûr elle ne rendra pas meilleure la lisibilité du cœur de l’algorithme, mais elle le sert sur un plateau. Pour l’algorithme proprement dit, les variables clairement nommées, l’évitement des ruses et autres raccourcis, la décomposition primitive des choses complexes par l’ajout de variables intermédiaires, l’utilisation judicieuse des contrôles de flux comme le précieux Select, tout ceci et d’autres choses sont à l’origine d’un code lisible.

TOUT N'EST PAS ROSE EN CE BAS MONDE

Bien sûr, la bonne structuration procédurale est un incontournable pour moi depuis fort longtemps. Mais je regrette toujours ce moralisme sous-jacent qui prône l’interdit des structures intra procédurales que sont les GOTO et autres GOSUB, au point de les dés-implémenter dans VB.NET : non mais ! De quoi je me mêle ? Je n'utilise pas .NET et je ne suis donc pas atteint par cette facette du moralisme agissant. Mais par contre, quand Microsoft à décidé en 2000 de dés-implémenter la mémorisation de la bibliothèque de code dans ce qui est mon outil de travail, Access, m'empêchant de fonctionner comme je le fais naturellement et fondamentalement, elle m'a planté un couteau dans le dos. Je regrette beaucoup ces postures suffisantes, dont je retrouve quelque écho ici dans ce fil, qui ne tiennent pas compte de la réalité des autres, au nom d'une prétendue supériorité théorique de gens finalement trop sérieux pour de mauvaises raisons.

CE FIL DE DISCUSSION

Vous le voyez, pour certaines personnes qui se sont exprimées sur ce fil, je suis un développeur hérétique : j’ai moins de vingt ans (au moins d’âge mental), je ne suis pas professionnel, je ne travaille que sur des petits projets qui deviendront forcément des usines à gaz. Ce que veut soulever l’ironie de cette remarque, c’est qu’il y a une espèce de déni de réalité, croissant tout au long de ce fil, par des gens qui s’autoproclament les seuls professionnels en programmation. Quand bien même une bonne dizaine de personnes, au 200ème message de ce fil, auraient exprimé clairement et paisiblement ce que j’exprime ici, à savoir qu’on peut très bien être professionnel sans utiliser l’analyse avant de programmer, ces quelques personnes sérieuses continuent de nier le fait que peut exister une façon différente de programmer. Je ne leur jette pas la pierre, je veux juste souligner à leur intention que le monde est plus vaste que ce que dit la théorie institutionnelle.

Qu'il existe une façon d'être programmeur que l'on puisse caractériser de spontanée ou bien d'instantanée selon moi, opposée à une autre façon d'être qui pourrait être qualifiée de séquentielle ou encore de logique, ne fait pour moi aucun doute. Je suis persuadé que la première façon d'être programmeur est rendue difficile parce qu'elle est rendue honteuse, voire censurée, par le déni et le moralisme que je mentionne ici. Cette façon d'être, qui est loin d'être marginale, s'accompagne le plus souvent d'autodidactisme et se trouve souvent caractérisée par l’isolement, ce qui la rend d’autant plus facile à railler sans argumentation qu'on se sent soi même fort d'être membre d'un groupe cohérent et puissant.

La raison pour laquelle j'adore littéralement ce fil de discussion, c'est qu'un gars, Doloop est venu parler tout tranquillement, sans désir d'en découdre, d'une chose qui existe. La suite, c'est que tout d'un coup une « armée » s'est spontanément levée d'individus dont on n’entend jamais parler, qui se sont reconnus, qui se sont vus exister grâce à lui sans complexes. Le fait que « l'armée ennemie » se soit mobilisée pour enrayer une telle progression insupportable est parfaitement habituel. Mais comme elle n'a pas trouvé ses victimes rituelles, déjà prêtes au sacrifice sur l'autel de la rationalité triomphante, il ne lui restait plus qu'à les nier !

Comme Doloop et comme ceux qui ont parlé après lui, avec la même distance dépassionnée, je ne désire pas m'élever en combattant. J'existe en tant que personne plus sensible que raisonnable, c'est comme ça (regardez le nombre de fois que j'emploie ici le mot cœur, regardez combien de fois ces programmeurs spontanés emploient des mots décrivant les sens et comparez avec les gens sérieux), et c'est aussi comme ça que je suis programmeur professionnel.

■ Envoyés par d’autres adeptes (glanés sur la discussion)

• #43 La seule chose qui reste est effectivement l'effort personnel, spontané.
  …/…
  Je pense que le coté positif de la méthode est la notion d'effort personnel, hors de tous outils, dans sa tête. Dans sa baignoire, quoi. C'est un outil ; l'ignorer est dommage.
  
  
• #49 On peut imaginer que le chef de projet donne ses directives à un programmeur, et que celui-ci se mette en état de programmation spontanée pour arriver au résultat.
  
  Mais souvent, il y a le chemin inverse : que le programmeur dise au chef de projet ce que le projet doit faire. C'est peut être paradoxal, mais c'est une situation parfaitement courante. Et ce programmeur doit être capable de le dire avant d'avoir écrit le code, sinon cela devient totalement ingérable.
  
  
• #63 Bien que je ne sois pas convaincu par le développement spontané, je suis persuadé qu’écrire 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).
  
  Étant attiré par l'écriture romanesque, et pour ce que j'ai lu sur divers auteurs, la manière de faire d'un développeur et d'un écrivain n'est pas si éloignée.
  
  Je pense que les astuces sont bonnes pour les environnements qui en ont besoin, mais en dehors ne sont pas vraiment utiles. La clarté est plus importante que le millionième de seconde économisé.
  
  
• #114 La programmation spontanée, ce n'est pas obligatoirement brouillon et ne devrait pas être assimilé à « programmation à "l'arrache" ».
  
  Quand je me mets devant mon écran, les lignes de codes viennent immédiatement, je sais exactement ce que je dois coder, "l'algorithme" est déjà présent dès l'ébauche du projet. Jusqu'à présent, je n'ai pas besoin d'y réfléchir concrètement avant, il vient spontanément.
  
  Ce n'est pas pour autant, vous pourrez le constater en jetant un coup d'œil à mes sources que mon code est brouillon et incompréhensible.
  
  Il est plus que nécessaire de faire du code, si ce n'est bien commenté, au moins, bien organisé. Un code bien organisé, quel qu’il soit, même s'il n'est que très peu commenté est normalement compréhensible par toute personne ayant les bases d'un langage.
  
  La programmation spontanée est davantage un atout "gain de temps" qu'un risque potentiel à un projet commun.
  
  
• #175 Ce n'est pas parce qu'on ne fait pas d'algorithme qu'on est un crétin fini et qu'on code comme un cochon.
  
  
• #190 L'algorithme existe toujours, que ce soit en pensée ou qu'il soit écrit.
  
  Certains sont tout-à-fait capables de garder en mémoire tous les détails du mécanisme de leur pensée ; d'autres ont besoin de "figer" et visualiser la chose sur papier.
  
  
• #196 Lorsqu'on conçoit un algorithme, on ne fait ni plus ni moins qu'écrire du code avec son propre "langage de programmation que l'on a inventé tout seul dans sa tête".
  
  On ne se lance pas forcément à corps perdu dans du code sans trop savoir où l'on va ni comment on y va, c'est sûr... Mais une idée en tête suffit la plupart du temps.
  
  
• #210 Dans la mesure du possible, j'essaie de faire un code "autodescriptif". Ce qui est faisable pour peu que tu ne fasses pas de choses trop compliquées en une seule fois.
  
  
• #212 Ce n'est pas parce que quelqu'un est capable de comprendre un problème en programmation et de le mettre en code rapidement sans passer par un algorithme papier que c'est forcément un "mauvais programmeur".
  
  C'est assez primaire de cataloguer les programmeurs qui codent rapidement. Ce n'est pas parce que tu es doué de le faire rapidement que tu vas négliger le nom des variables pour rendre la structure du code incompréhensible !
  
  
• #214 Ce n'est pas parce que tu fais un bout de programmation spontanée que tu n'as pas étudié le problème en question avant. Les idées doivent bien partir de quelque part.
  
  
• #216 Là encore tu viens de cataloguer ceux qui programment spontanément comme de mauvais codeurs. Comme je le disais avant tu peux très bien coder vite tout en faisant attention à rester lisible et très compréhensible.
  
  
• #220 Si tu programmes directement sans faire une analyse d’une heure au papier sur chaque petite partie de ton logiciel, tu n'es pas forcément un "pisseur de code".
  
  
• #230 On ne va pas pondre un code sans savoir ce qu'on va écrire ni sans savoir quel est le schéma sur lequel on va se placer. Il faut revoir la définition de la programmation spontanée. Comme on le comprend dans le premier message à mon avis, c'est que la grande partie de l'idée à implémenter doit être dans la tête du programmeur. Qui peut programmer sans savoir ce qu'il va faire? D'ailleurs à quoi ça servirait de programmer si on n’avait pas déjà un but précis en tête.
  
  Si tu programmes tu sais forcément où tu vas ! La programmation spontanée dans la définition que j'utilise c'est plutôt pour dire que l'idée de base est là, mais que tu vois progressivement d'autres détails qui se forment d'eux même (exemple : comment procéder pour faire telle fonction, en combien de parties cela sera fait...), bref pour moi c'est un plan non absolu (c'est à dire pas totalement défini et qui peu s'étendre de toutes parts) mais qui a une idée de base solide sur laquelle on peut travailler sans craindre de modifier trop sa structure (je parle de l'idée de base).
  
  Je n'ai pas la nécessité d'écrire un algorithme sur le papier, sauf quand il y a un bug dans ma pensée, lorsque je n'arrive pas à implémenter correctement la solution ou lorsque le programme ne fait pas ce que je veux, par exemple. Ça reste très rare.
  
  
• #277 Si je peux exprimer une idée pour résoudre un problème directement de façon claire et compréhensible avec éventuellement des commentaires (je rappelle que même les commentaires sont des exceptions..) dans le langage de programmation, alors je le fais directement.
  
  Contrairement à ce que quelqu'un avait rétorqué dans un de mes précédents posts, s'exprimer simplement dans un langage de programmation, ne signifie pas qu'on est en train de traiter des problèmes triviaux. Tout dépend des capacités du programmeur à structurer simplement des choses compliquées et de la maitrise qu'il a de son langage. Faisant ainsi, on simplifie plutôt la maintenance, car on n'aura pas à naviguer entre plusieurs documents pour comprendre une application.
  
  En fait le point de départ pour comprendre le fonctionnement d'une application doit être son code source. C'est à partir de celui si, qu'on devrait avoir éventuellement des renvois vers d'autre documents, si le code source et ses commentaires ne suffisent pas à exprimer SIMPLEMENT ce qu'on l'on fait.
  
  
• #313 … Et pour la maintenance d'un code source, si on programme "proprement" avec des noms de variables, méthodes etc. non ambigus, avec une structure simple, un bon système de login, l'utilisation en plus d'un IDE riche est largement suffisant pour permettre une bonne maintenance du code. Franchement je ne vois même pas l'aide supplémentaire que pourrait m'apporter des docs externes ou des diagrammes UML.
  
  
• #319 Pour un programme simple de quelques centaines de lignes, quel que soit le langage, le développement peut être fait en programmation spontanée, ce que je fais régulièrement, avec un attachement tout particulier à commenter mes lignes de code (et là on s'y retrouve toujours plus tard).
  
  Cette manière de programmer intuitive demande de la rigueur dans sa manière de penser le programme et quelques années (!) de métier et de connaissance mais elle a l'avantage de ne pas trop perdre de temps à une analyse pas toujours essentielle dans de pareils cas.
  
  Avec le temps on acquiert une manière de travailler, non pas en bâclant une partie du travail loin de là, mais en possédant des automatismes de pensée et de programmation, mêlant rigueur et savoir-faire, pour atteindre le but recherché : que l'application tourne parfaitement, avec un code optimisé, dans des délais raisonnables.
  
  L'analogie à la littérature d'une précédente remarque me parait tout à fait bien trouvée. Certains auteurs ont besoin de structurer un récit et passer du temps à tout planifier, alors que d'autres peuvent passer à l'écriture directement, laissant libre cours à leur inspiration. Et dans l'un et l'autre des cas, il y aura des bons et des mauvais romans.
  
  
• #337 Sur le net un conseil pour l'open-source : même pour le plus petit bout de code jetable, codez le bien. Car ça vous donne l'occasion de faire un exercice de style et ça vous donne l'habitude de bien coder.
  
  
• #346 La créativité du concepteur n'est intéressante que s'il est déjà rigoureux.
  
  
• #359 Si le papier est dans la tête, c'est à dire que la mémoire du programmeur s'est déjà chargée de toute la définition du problème, est-ce de la programmation spontanée ? Personnellement, je visualise d'abord l'algorithme avant de coder et au fur et à mesure, je corrige les erreurs en fonction des bugs.
  
  
• #384 Pour ce qui est de la programmation spontanée, je pense que c'est un abus de langage. Même si on code avec de la doc devant les yeux, c'est surtout avec la mémoire du cerveau et l'imagination qu'on travaille. Donc, même un programmeur qui code devant des papiers pleins de détails techniques, pratique la programmation spontanée, car quand il code, il se focalise surtout sur les lignes de code devant lui.
  
  
• #399 Sujet passionnant ! En tout cas "Doloop" je veux bien travailler avec vous.
  
  
• #424 … Tout ça pour vous dire que le développeur doit être "tout-terrain". Les problèmes qu'on lui soumettra viendront de gauche et de droite, et il devra être capable d'improviser en fonction des besoins, d'apprendre de cas en cas ce qu'il ne sait pas encore.
  
  
• #432 À mon avis cette capacité de travailler en codant sans passer par la phase d'analyse version papier existe chez tout le monde. Cependant chez la plupart des individus elle n'est pas très développée et les oblige à déléguer une grande partie de la mémorisation de l'analyse à un autre support que leur simple réseau de neurones.
  
  Je m'explique, en réalité ceux qui affirment être capables de faire de la programmation spontanée ne font pas réellement du spontané ou du live comme ils le croient ; bien au contraire ils font une analyse du problème et le schématisent même très bien, sauf qu'à l'opposé de monsieur tout le monde ils n'ont nullement besoin d'un support extérieur pour effectuer toutes les tâches de mémorisation et de traitement des données résultant de leur analyse. En quelque sorte ceux-ci disposent de plus de mémoire vive que tout le monde dans leur système CERVEAU.
  
  De plus parmi eux il existe encore d'autres individus capables d'une prouesse encore plus grande qui est celle de pouvoir effectuer la phase d'analyse du problème en un temps très court : le fameux flash décrit par certains intervenants du débat.
  
  Après libre à chacun de croire ce qu'il veut, il y en a bien qui croient aux prophètes et pas d'autres sans que cela n'empêche le monde tourner rond. Quoi que…
  
  
• #448 À 27 ans, Alexis Lemaire est en train d'effectuer un doctorat en intelligence artificielle à Reims.
  
  "J'utilise un système d'intelligence artificielle que j'applique dans ma tête au lieu de le faire dans un ordinateur", a-t-il laconiquement commenté. "Je crois que la plupart des gens peuvent le faire, mais j'ai un cerveau qui fonctionne vite, parfois très très vite", a-t-il ajouté.
  
  Et le voilà en plein démonstration : Calcul mental : A. Lemaire (Science on tourne)
  
  
• #453 Je n'ai jamais prétendu que la spontanéité comprenait uniquement la phase de codage proprement dite. Justement ce que je soutiens comme idée c'est tout le contraire, la programmation se fait à un rythme plutôt normal par rapport aux collègues mais c'est plutôt la vitesse d'imprégnation et d'appropriation du problème ainsi que son analyse et l'élaboration d'une solution convenable qui est très rapide au point d'être nommée par certain (ici même) de spontanée ou comparée à un flash (mental).
  
  
• #455 « Le sage paraît lent, mais il sait former des plans habiles. » - Lao-Tseu
  
  Ne serait-ce pas une apologie de l'analyse avant toute action ?
  
  
• #462 Ce que décrit Doloop, c'est qu'il a moins besoin de comprendre, de réécrire le problème, de chercher les solutions possibles, d'en envisager les tenants et les aboutissants. Il comprend plus vite car il décompose le problème en sous problème, s'attaque à chaque sous problème, visualise plusieurs solutions, est capable d'extrapoler le résultat de chaque solution et donc de choisir la moins pire plus rapidement. En fait, il y a peu d'essais et pas beaucoup d'erreurs car ce qui est écrit fonctionnera de toute façon puisque que le résultat était déjà prévisible. En clair, quand il prend le clavier en main, c'est déjà plié. Le problème en cours est résolu et dans sa tête il est passé au suivant. En fait je parle de Doloop, mais c'est davantage à mon expérience que je pensais.
  
  
• #465 Je bosse depuis une dizaine d'année dans le Web de façon solitaire, c'est-à-dire que je fais toujours tout dans un site, de A à Z, du code PHP au design sous Photoshop. Ces "conditions" de travail m'ont sans doute initié à la programmation spontanée.
  
  En tout cas, je me reconnais totalement dans le post initial de ce topic, j'ai toujours tendance à visualiser ce que je veux faire avant, avant de transposer tout ça à l'écran avec plus ou moins de facilité (ça dépend de la tâche à faire). Quand un bug survient, je sais presque immédiatement d'où ça vient, il n’y a jamais de panique. J'utilise rarement, voire jamais la paperasse sauf quand il s'agit d'énumérer une liste de tâches à faire pour éviter que je les oublie.
  
  
• #471 Plutôt que les commentaires, je préfère un code explicite avec des noms de variables et de fonctions très signifiants.
  
  
• #473 Je suis certain que beaucoup de programmeurs ayant quelques années d'expérience arrivent ainsi à "visualiser" la route de ce qu'ils doivent écrire, et même si rien n'est formalisé par écrit, ils ne travaillent pas sans repères mais au contraire les ont "mentalisés".
  
  
• #481 "La programmation spontanée c'est quand on est tous seul ou sur un projet perso". Et bien non, c'est aussi dans le milieu professionnel.

CITATIONS À MÉDITER

• « Il est plus facile de croire ce que l’on nous affirme officiellement, que de s’aventurer dans l’indépendance intellectuelle. En fait, ce n’est pas l’opposition, mais le conformisme et l’inertie qui ont de tout temps été les plus sérieux obstacles à l’évolution des consciences ! » - Mahatma Gandhi
  
  
• « Nous avons tous tendance à privilégier les preuves qui confirment nos idées préconçues. Il faut donc que nous nous fassions un peu violence en cherchant à sortir de nos schémas. » - Julia Galef, Présidente et cofondatrice du Center for Applied Rationality
  
  
• « Il ne s’agit nullement de se renier soi-même pour subir l’influence de l’autre, mais bien d’ajouter aux compétences que nous avons déjà, une nouvelle compétence ou une façon différente de percevoir un problème. » - Bertrand Piccard

---