Discussion :

[duj]

C'est pas faux: un bon joueur d'echec possède une très bonne méthodologie ainsi qu'une vue stratégique de sa partie : un plan, qu'il décompose en autant de sous-problèmes qu'il y a de phases de jeux.

Ceci dit, la comparaison s'arrête là : aux echecs, on ne peut pas faire marche arrière, si on voit que l'on se trompe, ce qui devrait toujours être le cas en informatique!

[JefDeBourges]

Je ne suis pas d'accord, le programmeur est plus proche de l'ouvrier. En entreprise on ne lui demande pas de "laisser sa trace" mais de programmer.

Je préfère qu'un programmeur s'y retrouve dans n'importe quel code (normalisation, structuration, dictionnaire de données etc...) plutôt que reconnaitre un programmeur en ouvrant un code.

Les astuces et autres ruses de sioux, même si elles peuvent faire plaisir au développeur lors de la programmation, ce ne sont que des futurs pièges. Elles sont à proscrire en entreprise.

Pour ma part, j'assimile programmation spontannée avec programme jetable (à usage unique même). Ca peut arriver en entreprise mais c'est l'exception.

Bien sûr, je parle là du boulot, car à la maison faire un script Perl de la mort pour tracer, sniffer, browser les malotrus qui osent s'approcher du firewall... ahhhh ca fait du bien
Et une coding partie ca défoule

[Médiat]

JefdeBourges

En entreprise on ne lui demande pas de "laisser sa trace" mais de programmer.

Je ne vois pas la contradiction !

Je préfère qu'un programmeur s'y retrouve dans n'importe quel code (normalisation, structuration, dictionnaire de données etc...) plutôt que reconnaitre un programmeur en ouvrant un code.

dito

Les astuces et autres ruses de sioux, même si elles peuvent faire plaisir au développeur lors de la programmation, ce ne sont que des futurs pièges. Elles sont à proscrire en entreprise.

C'est exactement ce que j'ai dit, et n'est en aucun cas incompatible avec une vision artisan/joueur d'échec de ce métier

[scarabee]

Comme tout le monde y va de son avis, pourquoi pas moi !

Je dirais juste que je pense que l'on doit adapter la façon de programmer à l'activité, au besoin, à la taille de projet. Exemple :

1) Un gros projet en entreprise, avec un cahier des charges (evoluant), et plusieurs developpeurs : il faut etre tres structuré, coder les fonctions deja predefinies dans l'analyse, avoir des jeux de tests, des commentaires... Enfin le plus propre possible, disons de façon tres scolaire dans le bon sens de terme.

2) un mini programme (à usage interne par exemple) devant servir rapidement et ayant un fonctionnalité tres precise, comme par exemple transformer un document au format A --> format B. Ici on peut se lancer dans la programmation directement.

3) Celui que je connais un peu plus : faire des programmes où l'on connait vaguement (voir tres vaguement) le cahier des charges, comme dans la recherche. Les desiderata des scientifiques sont tres evolutif (de part leur facon de penser et des evolutions techniques et scientifiques). C'est pourquoi la plupart des progs liés à la recherche que j'ai vu, sont un empillage de morceaux differents (souvent en fortran), tenant comme un chateau de cartes... mais tenant quand meme. Mais apres pour aller toucher une carte, faut s'accrocher pour pas faire tout tomber.

Pour le point 3, meme en y mettant de la bonne volonté, comme ces programmes sont maintenus pendant 10 ou 20 ans, ils ont été ecrit par plusieurs personnes en ADA, puis traduit par plusieurs personnes en Fortran, puis retraduit et modifé en C... Ici le contexte de developpement fait qu'il y a une difference entre la theorie et la pratique.

Bon quand à moi je retourne à mes jeux de tests.

[cedricgirard]

1) Un gros projet en entreprise, avec un cahier des charges (evoluant), et plusieurs developpeurs : il faut etre tres structuré, coder les fonctions deja predefinies dans l'analyse, avoir des jeux de tests, des commentaires... Enfin le plus propre possible, disons de façon tres scolaire dans le bon sens de terme.

pas complétement d'accord, meme un gros projet en entreprise n'est pas borné et l'analyse initiale de résoud rien; d'accord sur le fait qu'il faut une méthode pour orienter la collaboration

2) un mini programme (à usage interne par exemple) devant servir rapidement et ayant un fonctionnalité tres precise, comme par exemple transformer un document au format A --> format B. Ici on peut se lancer dans la programmation directement.

Je dirais plutot : un programme qui va tourner un mois et on jette : on peut se passer de techniques et de sécurités; un programme même minuscule mais qui doit rester à son poste et évoluer longtemps, alors il faut des jeux de tests, une analyse minimum, etc...

3) Celui que je connais un peu plus : faire des programmes où l'on connait vaguement (voir tres vaguement) le cahier des charges, comme dans la recherche. Les desiderata des scientifiques sont tres evolutif (de part leur facon de penser et des evolutions techniques et scientifiques). C'est pourquoi la plupart des progs liés à la recherche que j'ai vu, sont un empillage de morceaux differents (souvent en fortran), tenant comme un chateau de cartes... mais tenant quand meme. Mais apres pour aller toucher une carte, faut s'accrocher pour pas faire tout tomber.

pas sur, on a le cas de projets tres evolutifs qui restent parfaitement stables et strucurés, mais à condition que tout le monde s'attache à respecter qq regles. C'est le coeur de cible d'Extreme programming, les projets qui passent leur temps à bouger. Mais les projets ont ces projets qq soit le domaine, pas que dans la recherche.

Bon quand à moi je retourne à mes jeux de tests.

Ca, ya pas de doute que les jeux de tests sont la meilleure maniere de diriger le projet vers la bonne voie, mais il faut avoir le temps de les faire si on les fait après le code, alors autant les faire avant

[jerome.fortias]

la programmation spontannée est liée aussi à une génération : ceux qui ont commencé dans les années 80 sur des z80 parcequ'on ne pouvait faire que cela ...

c'est une excellente méthode pour tester un concept une méthode une classe, etc ... ou pour du fun... Mais dans le cadre professionnel, si c'est encore fait c'est souvent un risque majeur ... Sauf à avoir des outils costauds et une méthode parfaite ... En final je suis totalement contre dans un cadre pro ... sauf si on aime ajouter des correctifs spontannées à des softs spontannées, et finir par plus pouvoir facturer (sauf l'avocat) ...

Un excellent livre "programmation professionnelle" argument de manière scientifique sur le sujet

A+

Jérôme FORTIAS

[olivier-j]

ma fois la programmation spontanné existe est cela est un faite...
en gros tu fait l'algorithme dans ta tête et tu tappe sur ton clavier.
seulement voilà imagine que tu veulent explique ton programme a une personne qui n'y comprend rien en informatique !
comment va tu faire, puisque après avoir codé tu a vidé l'algorithme qui était dans tête n'étant plus util vu que ton programme fonctionne.

c'est le principale problème de la programmation spontanné, cela ne passera pas en milieu proffessionnel je vais dire a l'emboche, bien que cela fasse toujours sourire,
dans un projet cela ne passera pas non plus.

! faut mettre sur le papier l'algorithme que tu a dans la tête

d'un point de vu personnel on poura toujours retrouver l'algorithme de celui qui a fait de la programmation spontanné en lisant le code.

la logique qui veut que l'on réfléchise avant de faire une action et là même que celle qui veut qu'on fasse des algorithmes (voir des cahier des charge pour un projet) avant de coder.

si tu n'avait pas pensé avant a vouloir faire un feu tu n'irait pas chercher du bois....
tu vera que mettre tes pensée sur le papier, mettre le raisonnement que tu a avant de faire le programme t'aportera beaucoup plus de rapidité que tu ne peut l'imaginer, et cela sera très aprécier par ton entourage.

[unicyclon]

La programmation spontanée c'est bien en dessous de 100 lignes de code. Au dessous tu t'embrouille.

Le 3e commandement du programmeur :

Jamais un papier et un crayon tu n'oublieras

A méditer...

[davcha]

En mathématiques, avant de commencer à chercher une solution, on démontre qu'il existe une solution. C'est quelque chose que beaucoup d'étudiants considèrent inutile je pense.

De la même façon, en prog, avant de coder quoique ce soit du même genre que mon histoire de maths, la moindre des choses serait d'étudier si oui ou non ça vaut le coup de se lancer dans la conception d'un algo de ce genre.

L'intuition ne remplacera jamais une vraie reflexion.

[cedricgirard]

Pas faux, seulement les maths sont un univer limité, propre, absolu, ce que n'est pas la programmation. En math on peut avoir la certitude qu'il existe ou non une solution, en prog jamais dans un cas réel.
Je ne suis pas spécialement pour la "programmation spontannée" mais je pense que parfois pour vérifier un truc, il est plus réaliste de le tester sur un programme qui sera jeté après, que de se dire que en théorie peut être et si on a pas fait d'erreur cela doit se faire.
Les entreprises sont pleines de projets qui sur le papier étaient parfaits, mais qui n'ont jamais fait qu'engloutir de l'argent parce que le calcul initial était faux. Et il était faux parce qu'il n'est pas possible de tout prendre en compte, comme cela est possible en math.

[GilMir]

DOLOOP a écrit, et je cite...
Je souhaiterai savoir s'il y a beaucoup de personne qui programme de manière spontanée comme moi.
J'ai déjà posé des questions à des personnes du domaine et ce n'était pas le cas pour eux. Cependant sur ce forum et d'autre, il y a des posts qui me semble confirmer que oui.
La question de Doloop ainsi que les réponses apportées par les divers intervenants sont très intéressantes.
Je suis en partie d'accord sur le fait que l'on ne soit pas obligé de passer par des cahiers de charges volumineux ou des organigrammes fastidieux pour pouvoir programmer sous Visual Basic.
Mais quel est l'enjeu final ?
Si la finalité est de réaliser des applications pour se faire plaisir comme s'est mon cas, je ne pense pas que cela soit indispensable.
Par contre, la ou je ne suis pas d'accord c'est de négliger les commentaires sous prétexte que le compilateur n'en tient pas compte.
Il m'arrive souvent de commencer une application, qui reste en souffrance pour diverses raisons et que je reprends après plusieurs jours(mois) avec la satisfaction de comprendre ce que j'ai voulu réaliser grâce aux nombreux commentaires que je dispense à profusion.
Visual Basic est un jeu de mécano et l'on peut récupérer des instructions ou fonctions déjà écrites dans d'autres programmes, ce qui facilite grandement l'écriture du code. (on ne réinvente pas la roue)
Avec l'évolution ainsi que l'expérience acquise au fur des années on constate que l'on écrit parfois différemment certaine routines.
J'ai commencé avec GWBasic et je suis passé au Visual Basic 3.0, lorsque j'ai décidé de' évoluer et de passer à VB6.0 j'ai gardé (peut être un peu par flaimardise) certaines instructions de VB3.0 tout simplement parce que
je me suis rendu compte que VB6 les prenaient en charge sans problème.
De temps en temps j'utilise les nouvelles instructions de VB6.0 (j'évolue)
Je ne me catalogue pas comme étant un programmeur, puisque mes études ainsi que mon parcours professionnel a été orienté dans l'ingiénérie électronique et je suis venu à l'informatique par vocation.
Tous les programmes que je réalise(à part quelques exceptions) sont écrits de manière spontanée, désolé de vous décevoir, mais c'est la vérité.
Je suis en train d'écrire un programme de gestion d'une brocante. Tout simplement parce que j'organise une brocante chaque année et que j'en ai marre de faire manuellement toujours la même chose.
Disponibilité courant 2005
Mais rassurez vous, je ne travaille que pour moi, je n'ai pas de contrainte et mes programmes ne sont pas à la vente(sauf un) mais je n'en ai vendu que trois ou quatre, et je n'attend pas après ça pour vivre.
Je tenais à donner mon point de vue, sans aucun esprit de polémique, chacun fais ce qu'il veut ou ce qu'il peut, mais le débat est sympathique et puis la critique n'est elle pas nécessaire lorsqu'elle est constructive ?
Bien cordialement à tous
Gilmir

[davcha]

Pas faux, seulement les maths sont un univer limité, propre, absolu, ce que n'est pas la programmation. En math on peut avoir la certitude qu'il existe ou non une solution, en prog jamais dans un cas réel.
Je ne suis pas spécialement pour la "programmation spontannée" mais je pense que parfois pour vérifier un truc, il est plus réaliste de le tester sur un programme qui sera jeté après, que de se dire que en théorie peut être et si on a pas fait d'erreur cela doit se faire.
Les entreprises sont pleines de projets qui sur le papier étaient parfaits, mais qui n'ont jamais fait qu'engloutir de l'argent parce que le calcul initial était faux. Et il était faux parce qu'il n'est pas possible de tout prendre en compte, comme cela est possible en math.

Oui et non. Tu vas pas aller programmer un truc pour une entreprise sous pretexte qu'il se pourrait qu'elle en ait besoin ou parce que "c'est cool". Donc, il faut déjà savoir s'il y a une utilité à tel ou tel programme. Et ça fait déjà partie de l'étude préalable.
Concernant les maths en tant qu'univers limité, propre, absolu, oui et non. Et c'est un peu la même chose en programmation. Les maths, démonstrations de maths, etc... traitent un ensemble limité d'information, tout comme un algorithme en prog.
Il serait débile de parler de développement limités pour démontrer le théorème de pythagore, tout comme il serait débile de faire du directx ou de l'opengl pour faire du SGBD :p

Maintenant, ça dépend de l'algo, comme tu le sous-entends. Si c'est quelque chose d'assez rapide à coder, il sera peut-être plus avantageux de le programmer vite fait bien fait pour voir si ça marche, que de réfléchir à la question.
Par contre, ça m'étonnerais que tu expliques à ton patron : "bon on va essayer la solution A, ça mettera 6 mois, et si ça va pas, on fera la B. Et si ça va pas, on aura bien trouvé une solution C entre temps.". Là il risques de te faire les gros yeux

[cedricgirard]

Bien evident qu'il faut déjà savoir si le projet est utile avant de commencer. Je répondais à ton message sur le fait qu'il faut "prouver" qu'un solution existe, et je pense qu'en programmation on ne peut pas toujours le démontrer.
Justement dans ma manière d'aborder le projet, on ne développe que ce dont le "client" au sens large à réellement besoin, pas ce dont lui ou moi pensons qu'il pourrait éventuellement avoir besoin.
Ensuite il arrive qu'un projet soit lancé pour vérifier que la solution est techniquement viable, possible. On suppose que oui, mais personne n'a d'autre solution que de faire un test grandeur nature pour vérifier que c'est vrai.

[Swoög]

Bonjour @ Tous,

J'arrive sûrement comme un cheveux sur la soupe, mais je souhaiterais exprimer mon point de vue au sujet du post d'origine : programmation spontané ?

Ce n'est pas obligatoirement brouillon : quand je m'attaque à un projet (récemment un traducteur d'image en grille de point de croix en C#, il est dispo en DL sur mon site, les sources sont incluses dans le Setup...)
Je me met devant l'ordi, et les lignes de codes viennet immédiatement, je sais exactement ce que je dois coder, "l'algorithme" (si on peut appeler ça comme ça) est déjà présent dès l'ébauche du projet, je n'ai pas besoin (jusqu'a présent) d'y réfléhir concrètement avant, il vient spontanément...

Ce n'est pas pour autant, vous pourrez le constater en jetant un coup d'oeil à mes sources) que mon code est brouillon et incompréhensible...

Le phénomène de programmation spontanée ne devrait pas (à mon avis) être assimilé à `programmation à "l'arrache"`...

Il est, je pense, plus que nécessaire de faire du code, si ce n'est bien commenté, au moins, bien organisé.

Un code bien organisé, quelqu'il soit, même s'il n'est que très peu commenté (comme certains le penseront vis-à-vis de mon code) est normalement compréhensible pour toute personne ayant les base d'un langage.

La Programmation spontané est plus (toujours à mon humble avis) une capacité provoquant un gain de temps relativement important, qu'un moyen de foutre en l'air (passez-moi l'expression) un projet commun.

Pour exemple, je crée avec un ami des Sites Web, à chaque fois qu'il commence un projet, je suis effaré par son organisation (il est pourtant de nature plus posée que moi qui suis bordélique [veuillez m'excuser pour ce langage plus que familier] au possible).
Alors qu'à chaque fois qu'il s'intègre à un projet que j'ai débuté, il ne se plaint pas et est beaucoup plus rapidement efficace que quand il doit reprendre un de ses propres projets qu'il a laissé inoccupé pendant quelques temps...


Voilà, je souhaite juste apporté ma petite contribution à tout cela.

Merci de m'avoir lu.
Swoög

[cedricgirard]

Disons que quand l'organisation est bonne, la méthode importe peu.

[Erwy]

il y en a qui ont beaucoup de chance de pouvoir pondre un algo optimise spontanement du prmier coup mais desole,de par mon experience je garde un gros doute sur ce sujet des que la complexite de celui ci(ou des donnees en jeux) augmente de niveau

[kemodo]

non mais sur ce point la il n y a RIEN a dire.
Les vrais GROS projets necessitent une organisation de developpement il ne peut pas etre question de programmation spontannee.
Si on choisit le developpement en cycle en V par exemple a la fin de chaque phase il y a une revue pour que le client valide l avancement et donc ca ne sert a rien de coder si la specification et la conception n'ont pas ete faites auparavant.
Il est naturel de dire : ouais mais moi je suis bien en programmation je sors des super algos et tout.........
Encore une fois comme d'autres avant moi l'ont dit : la prog
spontannee c'est uniquement pour le plaisir personnel ou de tres petits projets parceke lorsque quelque chose va evoluer
ca va etre un gros n'importe quoi si il n'y a pas des specs et de doc.

[stailer]

J'ai développé 3 logiciels de cette manière (programmation spontanée).
Résultat :
Presque 3 échecs. La maintenance est pénible, on a plus le plaisir de programmer au fur et à mesure que le projet avance. C'est l'horreur.
Et je ne parle pas de l'angoisse et du stress lorsque le client demande une amélioration remettant en cause des formulaires complets...

Donc maintenant c'est fini.
Mon dernier projet (réalisé avec Delphi7, PHP4 et MySQL) a été analysé et pensé pendant 2 mois (c'était pas un gros gros projet).
J'ai crée un max de fonctions génériques.. J'ai bien conçu mes classes et mes objets, en pensant au futur. J'ai bien mis à plat (sur Excel) ce qui devait se passer, et comment la base devait réagir.

Bref.. Réussite totale. J'ai un code clair, commenté, et facilement maintenable. Je peux aborder les modifications sans stress et elles sont généralement réalisées très rapidement.

Voila ce que j'ai a dire de ma petite expérience...

[titusutit]

Salut à tous, waw, quel long débat ! héhé !

Bon, je suis pas le big boss de la programmation, mais voilà, ce que j'ai a dire:

Je programme depuis quelques temps, et j'ai eu le plaisir de chipoter en assembleur, en java, en basic, en html et bien d'autres langages...

Pour répondre aux gars qui disent programmer de façon spontanée... c bien, je procède aussi de la même manière... mais sur des petites portion de code héhé

Je m'explique, tout comme eux (apparement), je n'ai pas besoin de faire des petits calculs ou de gros dessins pour résoudre un problème. Les solutions se présentent à mon esprit, et je peux immédiatement coder au net. J'ai ces facultés en sciences aussi (math, physique etc.), pour l'information...

Mais il faut savoir que "beaucoup" de personnes possèdent ces facultés, cette possibilité de programmer des algos spontanément, certainement encore plus, lorsqu'elles ont de l'expérience.

LE POURQUOI DU COMMENT DE LA DIFFERENCE ???!!!

A mon avis, nous réfléchissons tous plus ou moins de la même manière face à une fonctionnalité à coder. Cela dit, certains, auront besoin de coucher sur papier toute une analyse préalable au codage, tandis que d'autres la coucheront dans leur tête. En effet, après avoir atteint un certain niveau en informatique, je crois que plus personne ne code à la volée, au fur et à mesure... NON ! Tout le monde fait une petite analyse (qu'elle soit sur papier ou mentalement) pour savoir où il va, pour PREVOIR les difficultés à l'avance (c'est ici qu'agit l'intelligence) ainsi que leurs solutions, et finalement pour pouvoir estimer un délai raisonnable pour la fin du travail.

Je crois qu'ici la démonstration est faite : TOUT LE MONDE ANALYSE AVANT DE CODER... c'est la façon d'analyser qui diffère.

Maintenant, il faut aussi se placer dans le contexte du CODING... Certains le font seuls, chez eux, pour une petite application personnelle ou une petite application aux fonctions restreintes. Alors que d'autres le font en groupe en entreprise (ou chez eux parfois aussi, lol, comunauté open source etc.). Dans ce dernier contexte, lors du travail en groupe, je crois qu'il est plus intelligent et même...naturel... de procédé à une analyse papier avant. C'est bien d'avoir le code qui se trace en tête, mais ici, le travail se fait en groupe, il faut à plusieurs moments définir la voie prise, pour un moment plus tard la redéfinir et la redéfinir et encore la redéfinir... Si aucune analyse n'est faite avant, ET pendant, je vous laisse imaginer la synchro du prog, loooooool !!! Imaginez, 10 gars (pour un petit projet) qui travaillent sur une application, sans analyse, il est tout à fait possible d'avoir 10 compréhensions du problème différentes... HAHAHA ! Je vous dis pas la cata... héhéhé ! Enfin, voilà...


Pour parler un peu des commentaires... A mon avis, c'est nécessaire.
Il est clair qu'il ne faut surtout pas commenter chaque ligne, ni chaque boucle, mais plutot chaque fonction(méthode ou procédure), chaque classe (en orienté objet), et ainsi de suite. Sans oublier les morceaux astucieux...(là où on a usé de son génie....et que tout le monde ne pourrait pas comprendre du premier coup).

Mais pourquoi des commentaires ? C'est chiant...

Oui, c'est chiant, mais ça permet d'écrire des programmes EVOLUTIFS et SURVIVANTS: quelques temps après il sera facile de le maintenir (de le faire évoluer, et comprendre directement le pourquoi des bugs). Dans l'optique actuelle de la programmation, c'est important aussi, car on travaille rarement seul ! Aussi, dans des projets d'ampleur, je défie quiconque pouvoir s'y retrouver parmi les 400-500 classes pouvant faire partie d'une application ! Sans aucun commentaire, il est possible de comprendre et maitriser le programme, mais il faudra peut-être quelques mois voire quelques années pour en arriver à bout. Alors qu'avec des classes et des méthodes correctement commentées, quelques semaines suffisent pour comprendre l'ensemble du programme et DEJA commencer à maintenir le code.

Pour les petits projets personnels, c'est clair qu'il doit être facile de s'y retrouver dans 2 ou 3000 lignes de code, même sans commentaire... Quoique, je mets au défi quiconque de comprendre l'un de mes codes en ASSEMBLEUR...

Oui, je crois qu'encore une fois tout dépend du contexte et de l'outil utilisé...

Mais bon, je crois qu'en conclusion:

1) tout le monde analyse avant de coder que ce soit sur papier ou en tête.

A mon avis, on pourrait mettre ça en parrallèle avec un jeu d'échec... Certains peuvent imaginer une stratégie et calculer les 20 ou 30 meilleurs coups prochains comme un petit Kasparov. Alors que d'autres ne peuvent penser que 5 ou 6 coups à l'avance, s'ils veulent aller plus loin il leur faudra un petit bout de papier...

2) tout le monde devrait commenter son code proprement (pas inutilement).

Pour un petit algorithme perso de 1000 lignes, on peut s'en passer (quoique...j'en doute pour un algo en Asm ! ).
Pour un algo plus gros, on peut s'en passer aussi, mais, il faut 10 à 100 fois plus de temps à trouver les bugs. Pour ce qui est de l'évolutivité du programme, imaginons qu'après 5 ans vous voudriez remettre à jour les fonctionnalités d'une application de 20 000 lignes, eh bien, avec un code commenté, il faudra quelques heures pour se réapproprier le code, tandis qu'avec un code non commenté, il sera bien plus simple de virer le code et recommencer dès le départ. A moins bien sûr de ne travailler sans délai aucun...lol !

Et pour ce qui est du travail en groupe, eh bien, les problèmes d'un code non commenté sont les même que plus haut, mais puissance 4 !


L'EQUATION A RETENIR SELON MOI C'EST :

ANALYSE(S) + COMMENTAIRES = programme vite mi en place, vite corrigé si y'a un blème, vite amélioré si on lui en demande plus, et en prime (encore grâce aux chers commentaires) on peut même le passer à un copain pour qu'il nous file un tit coup de main...

lol !

Je crois que j'ai tout dit...héhé !

C'est vrai, non ?

Master T. 8)

[MadArcher]

Juste un petite précision après ce que je viens lire, je pense que partir de but en blanc rien qu'en ayant réfléchi au problème posé ne garantit en rien la qualité de la solution retenue !! Combien de fois dans mes premières années de programmation, j'ai utilisé cette démarche par orgueil pour me rendre compte au final, que mon code n'était pas du tout bien écrit, surtout beaucoup trop tordu.

Rien ne vaut la retranscription sur papier pour pouvoir prendre suffisamment de recul par rapport à notre solution pour la peaufiner ou la modifier en profondeur. Et l'expérience que j'en tire me permet de dire qu'on gagne un temps énorme à s'aider de croquis ou autres pour développer surtout si dans une dernière étape, on commente le code avant de l'écrire en détaillant les structures de données, de contrôle ou de fonctions.

On n'y prend plus plaisir de plaisir parce que la qualité du résultat s'en ressent et on a évité 95% des erreurs de développement stupides qu'on aurait faites autrement.

A bon lecteur salut