Discussion :

[Doloop]

Salut à tous,

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.

L'auteur d'un livre dans les années 80, annoncait qu'il n'y aurait que 10 % des programmeurs qui peuvent se passer de dessiner un algorithme pour faire un programme.
Faisait-il allusion à la programmation spontanée, ou ce type de programmation porte t'elle un autre nom ?

Double définition : Qui se fait de façon naturelle, sans arrière-pensée / Que l'on fait de soi-même, sans sollicitation extérieure.

L'algorithme, on l'invente directement dans le programme au fur et à mesure des besoins qui se font ressentir au moment de focalisation sur des points précis.
Devant le clavier, on sait immédiatement ce que l'on a faire, il suffit de transposer ce que l'on voit mentalement sur l'écran.
(Avec l'expérience, par concentration les solutions sur les points délicats des programmes, apparaissent dans la tête sous forme de flash.)

Attention cela ne veut pas dire que l'on ne fasse pas de bugs, si bug il y a, il n'est pas de structure, le programme est destiné à fonctionner sans modifier l'algorithme pensé initialement.
Fasse à un bug, aucune panique par rapport à nos debuts, on sait qu'on va le trouver, ça remplace un jeu de déduction sans plus.

Il n'est même pas nécessaire de rajouter le moindre commentaire pour comprendre ses propres programmes ou ceux des autres.
A la lecture des lignes d'instruction, on les simule dans sa tête. (inutile de paraphraser ce que l'on est en train de lire)

Je suis persuadé que tout le monde peut y arriver à force de pratiquer.
Cela fait penser aux dessinateurs comme Cabu et Plantu qui peuvent commencer leurs dessins par n'importe quel bout et parvenir au même résultat à la fin.
(En ce qui concerne le dessin, ça doit être moins sûr. On doit avoir le truc en série ou on ne l'a pas)

Je rajoute une information qui me concerne et qui a peut être son importance, c'est que je n'ai pas mémoire qui retient facilement les récitations, en contre partie j'utilise en remplacement la mémoire dite procédurale.
La mémoire procédurale est peut être la memoire la plus solicitée pour programmer ?

Une personne sur un autre forum avait dit qu'il devenait en quelque sorte le programme (un peu comme Rambo devient la guerre).
Ce qui prouvent bien que ce cas n'est pas une exception.

Qu'en est-il de vous et de ceux que vous connaissez ?

Merci pour vos réponses, et joyeuses fêtes à tous.

@+

[hachesse]

En tout cas une chose est sur, j'espere ne jamais avoir a travailler sur le meme projet que toi.

Si ce type de demarche est possible lors des TP qu'on te donne a faire quand tu commences a programmé, aucun projet de grande taille ne peut etre mené a bien de cette facon

Je ne peut que te conseilé de lire et surtout d'appliquer http://smeric.developpez.com/java/astuces/

[quicky2000]

Je suis complètement d'accord, exécuter dans sa tête des lignes de code une a une ne peut pas permettre de comprendre l'ensemble du programme a moins de l'avoir fait 5 minutes avant...
Si tu reviens dessus quelques mois apres je pense que tu seras perdu
Il faut toujours programmer en pensant que d'autres personnes vont relire le code sans l'avoir conçu et donc leur laisser des informations..
et comme le dit hachesse ça me parait impossible d'appliquer ça sur un gros projet ou sur du travail en équipe ou chacun est chargé d'un morceau du programme

[alexrtz]

Salut,

Pour le projet du semestre j'ai fait la partie obligatoire en spontané et je ferais la partie facultative quand je me serais décidé à réfléchir.

Je pense que notre spontanéité à coder dépend non-seulement de la taille du projet mais aussi du niveau de maîtrise que l'on a du sujet.

[hachesse]

Tu parles d'un projet fait a la fac, ce n'est pas un vrai projet.
Les projets d'etudes sont de tres petits projets (200 ou 300 heures pour les plus gros) et le contexte est vraiement différent.
Le cachier des charges (énnoncé plutot) ne change pas au fur et a mesur du developpement ce qui est generalement le cas dans les projets fait en entreprise.

De plus en cas d'un projet de groupe, tout les intervenant ont la meme formation et les meme connaissance, ce qui n'est pas le cas dans un vrai projet qui fait intervenir des personnes au competance et a la culture tres variée

[duj]

Qu'en est-il de vous et de ceux que vous connaissez ?

Je connais 2 genres de programmeurs :

1. ceux qui font de la "programmation spontanée" et qui rament pendant des jours dans un code merdique à creuver. Qui ne comprennent pas la moindre ligne du code qu'ils ont écrit le jour d'avant et dans lequel ils cherchent un bugs, bien évidemment.
Ce sont les mêmes qui bien sûr commencent directement à taper, sans la moindre reflexion préalable (ben oui, ils sont en quelque sorte le programme).
Finalement, ils abandonnent... (et demande à un mec de la catégorie 2 de les aider, et le mieux est de tout recommencer)

2. Ceux qui prennent leur temps de tout plannifer et de concevoir avant de commencer à implémenter, qui connaissent déjà le noms de toutes les fonctions (methodes) et leurs spécifications. Bref, quand ils commencent à taper, ils n'ont aucun doute sur le fonctionnement final. Ils codent de manière claire et commentent le plus possible. Si parfois, il y a une erreur, ils la trouvent facilement : c'est souvent une faute d'inattention quelquepart où la fonction ne correspond pas à la spécification....

Généralement, les gens de la catégorie 1 sont déjà au mileu de l'implémentation quand les gens de la catégorie 2 commencent...

Il n'y a que des amateurs pour penser que la methode de la catégorie 1 est la meilleure! Ou des génis incompris...

[hachesse]

Sans oublier tous ceux qui passent de la catégorie 2 à la categorie 1 au fur et a mesure que la deadline approche

Pour etre serieux, je pense qu'il y a un compromis a faire entre les 2
Se lancer dans le code directement est une chose a ne jamais faire, mais passer tout sont temps sur l'analyse et la conception ne fait pas avancer le projet et tu te retrouve a utiliser tout ton temps a spécifier.

Il faut bien degrossir le projet dans les grande ligne avant de commencer le code, et ensuite faire les 2 en meme temps.

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

[Doloop]

Merci pour vos réponses.

Le travail en équipe est différent, le niveau de compréhension de chacun et aussi variable.

La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode, lorsque l'on commence un programme on sait tout de suite ce qu'il nous manque à chaque étape.
Il n'est pas utile de comprendre tout le programme à chaque secondes, mais de se focaliser sur les points qui nous manquent au présent.
Revenir sur un ancien programme, n'est absolument pas un problème.
Si chaque partie de programme à été testé conforme au attente, il n'y a plus à revenir dessus, il n'y aura pas de bugs.
Si modification il doit y avoir du programme, quelques tests et on identifie les lignes souhaités.

La méthode est mauvaise ? Mes premiers pas se sont porté sur un logiciel complet pour se faire la main alors que je n'y connaissais pas grand chose (tout à découvrir, comme ceux qui commencent leurs études).
Le total de nombre de ligne du logiciel terminé :
45338 lignes dont 38063 lignes non espacées, programme compilé 1 Mo tout rond soit 743755 caractères saisis au clavier + quelques programmes complementaires <100 Ko. (temps de réalisation 2.5 ans, c'est pas terrible comme délai, mais qu'est ce que l'on peut apprendre lorsque l'on est obligé de tout faire)
En tant que débutant à l'époque, si la programmation spontanée n'avait pas été réalisable, je me serais arrêté à la 100 ème ligne.
Je n'ai jamais prétendu que la programmation spontanée était facile surtout au debut, cela demande beaucoup d'effort mentale à cause de tout ce qu'il y a à apprendre, ensuite c'est expérience qui fait le reste.

Le programmeur qui se perd dans son propre programme, c'est qu'il n'a pas assez programmé ou alors il s'est trompé d'orientation.

Se passer de commentaire c'est peut être dur au début, mais ensuite on développe d'autres facultés, celle de simuler le fonctionnement de chaque ligne observée.
Si l'on part du principe qui peut le plus peut le moins. Rajouter des commentaires ne pose pas de problème en soi, tant que cela peut aider les autres.
Mais lorsque l'on a le choix entre rajouter un commentaire et poursuivre le programme à la ligne suivante, j'ai fait le choix que la sortie de mon programme était prioritaire avant tout.
Les commentaires ça peut toujours se rajouter ultérieurement une fois le programme achevé voir même vendue (d'ailleurs les compilateurs n'en tiennent même pas compte).

Un programme qui emploie des noms de variables, de sous-programmes et de fonctions significatifs pour moi contient plus d'information que nécessaire, c'est comme pour Port-Salut, c'est marqué dessus.

Si quelqu'un fait une erreur de structure de programme (algorithme), le programme ne fonctionnera pas peu importe les commentaires employés même avec ; Jésus revient (quoi que).
S'il faut passer 2 fois plus de temps à établir un algorithme qui à une chance de fonctionner que de faire le programme, moi je suis le patron je pleure pour l'argent perdu à l'étude. Car s'il y a un endroit ou l'on peut gagner du temps et de l'argent, c'est bien à celui là.

@ +

[LFE]

Je rejoins Hachesse dans sa remarque : je ne voudrais travailler pour rien au monde avec toi.

La façon de travailler (je n'arrive pas à appeler ca méthode) est acceptable pour des petits 'tools de rattrapage'.
Pour ce qui est de projet de taille raisonnable, je ne veux même pas imaginer ce que ca pourrait donner en dehors de quelqu'un qui travaille seul.
Dans une équipe, ce 'gain de temps' sur l'étude préalable se paiera tôt ou tard, et très cher.

[hachesse]

Le travail en équipe est différent, le niveau de compréhension de chacun et aussi variable.

C'est pour cette raison qu'il existe des notations standardisées tel que UML pour que tout le monde puisse parler le meme langage

Revenir sur un ancien programme, n'est absolument pas un problème.
Si chaque partie de programme à été testé conforme au attente, il n'y a plus à revenir dessus, il n'y aura pas de bugs.

On ne palre pas forcement de correction de bug, mais simplement d'evolution du programme. Et quand il se passe plusieurs mois entre les 2 intervention, mois durant lesquels tu as travaillé sur d'autre projet, tu ne peu plus avoir le code en tete

Si modification il doit y avoir du programme, quelques tests et on identifie les lignes souhaités.

Je ne doute pas que ce soit faisaible sur une centaine de ligne de code, mais sur un porjet complet, je suis septique

La méthode est mauvaise ?

Assurement, OUI

Le total de nombre de ligne du logiciel terminé :
45338 lignes dont 38063 lignes non espacées, programme compilé 1 Mo

Bel exemple de modularité et de capitalisation de code.

Le programmeur qui se perd dans son propre programme, c'est qu'il n'a pas assez programmé ou alors il s'est trompé d'orientation.

Mais tu n'a pas toujours a faire a ton propre code, ou bien peut etre que d'autre personne auront a faire a ton code.

Se passer de commentaire c'est peut être dur au début, mais ensuite on développe d'autres facultés, celle de simuler le fonctionnement de chaque ligne observée.

Le probleme est là, tu iras toujours plus vite a lire quelque ligne de commentaire ecrite en langage naturel que de lire et comprendre un pavé de ligne de code non commenté. D'autant plus, que pour comprendre une fonction, il te faut souvent comprendre une autre fonction assosié

Si l'on part du principe qui peut le plus peut le moins. Rajouter des commentaires ne pose pas de problème en soi, tant que cela peut aider les autres.

FAUX, dans ce cas, le moins ce sont les commentaires, celui qui arrive a comprendre un code sans commentaire (et personne ne le peu), c'est lui le plus)

Mais lorsque l'on a le choix entre rajouter un commentaire et poursuivre le programme à la ligne suivante, j'ai fait le choix que la sortie de mon programme était prioritaire avant tout.

Tu as une vision du projet a tres court terme. Avec l'experience, tout le monde sera d'accord pour dire que ajouter un commentaire, fait gagnerdu temps sur le reste du projet

Les commentaires ça peut toujours se rajouter ultérieurement une fois le programme achevé voir même vendue (d'ailleurs les compilateurs n'en tiennent même pas compte).

Pur utopie

[neo.51]

Je pense que ton raisonnement marche, pour un petit outils, avec une durée de vie trés courte, et ou une seule personne travaille dessus.

Je prends un exemple ou ton raisonnement à ses limites :

Dans ma sociètèe, nous vendons un progiciel qui fait environ 800 000 lignes de C++.

L'applis est en constante évolution depuis 5 ans. Imaginne sans documentation, sans commentaire, comment débugger une telle applis ? Comment faire évoluer l'applis et demander par exemple à un stagiaire de développer une nouvelle fonctionnalitée si l'applis n'est pas documentée et qu'il n'y a pas de commentaires ? Comment travailler en équipe si on ne se met pas d'accord sur les spécifs avant de commencer à coder ?

Certainnes parties de notre applis sont encore mal documentée. Et on passe un temps fou à éssayer de redocumenter ces parties "aprés coup"... je te parle même pas du debug qui est une horreur. Résultats on pert des mois à reprendre des modules mal documentés pour le débug.

[Etienne Bar]

Dans un contexte professionnel, vu la durée de vie des applications (plusieurs années, voire 1 ou 2 dizaines dans des contextes gros systèmes/grosses applications), il est très fortement probable que l'informaticien qui modifiera le code ne sera pas le même que celui qui l'a écrit initialement.

Si toi tu peux te passer de commentaires, c'est envisageable dans un contexte personnel (tu n'embêtes que toi ;-)). Mais dans un contexte profesionnel, c'est un manque de savoir-faire et de savoir-vivre.

[ovh]

Je rejoins bien évidemment l'avis des autres. 8)

Programmer sans analyse préalable, ça peut encore s'envisager dans le cas d'un tout petit outil où on sait bien ce qu'on va faire car la tâche à accomplir est légère et bien délimitée. Mais même là-dedans, si tu as plusieurs dizaines de lignes de code, un minimum c'est de le présenter le plus clairement possible pour pouvoir s'y retrouver soi-même par après : quelques espacements bien positionnés, quelques commentaires judicieux pour détailler un gros bloc de code, etc.
Je suis d'accord qu'il ne faut pas pondre des diagrammes UML et écrire des cas d'utilisation pour le moindre petit programme, ni écrire une tartine de commentaires normalisé ISO-9002 en en-tête de chaque fonction... mais de là à ne pas commenter du tout, ça c'est de la folie. Tu crois pouvoir t'en sortir pour l'instant car tu es plongé à fond dans ce que tu fais, mais dès que tu laisseras un peu de côté ton application et que tu devras y revenir par après... je te souhaite bien du plaisir...

PS : Je serais curieux de connaître ton âge ? Sans vouloir dénigrer, ça ne m'étonnerait pas que tu aies moins de 20 ans. En effet dans mon jeune temps moi non plus je ne mettais pas beaucoup de commentaires, je trouvais ça inutile, mais quand j'ai commencé à écrire plusieurs programmes, à faire d'autres choses, et que j'ai voulu revenir à mes propres programmes plusieurs mois après... hé bien je perdais de plus en plus de temps à recomprendre ce que j'avais fait (souvent pour me rendre compte d'énormes défauts de conception).

Crois-moi, l'analyse et le "commentage" ne sont pas des préceptes inutiles de vieux croutons. Il faut cependant rester proportionné avec le projet, c'est évident.

[duj]

S'il faut passer 2 fois plus de temps à établir un algorithme qui à une chance de fonctionner que de faire le programme, moi je suis le patron je pleure pour l'argent perdu à l'étude. Car s'il y a un endroit ou l'on peut gagner du temps et de l'argent, c'est bien à celui là.

Si il y a bien un erreur dans ce que tu dis, c'est celle-là!!!

Je t'assure que ce n'est pas une perte de temps, au contraire, c'est une assurance de terminer le projet à temps.

Le patron qui pleure, c'est celui qui voulait se dépecher de vite finir, et qui se retrouve dans une situation catastrophique. Et là il se rend compte de son erreur (mai bien sûr, c'est trop tard)

Le pire, c'est que bien, sûr, on a plus le temps de revenir en arrière, et on tombe dans une spirale infernale ! Je connais des projets qui ont des années de retard et dont personne ne veut s'occuper, tellement le code est mal écrit, etc... Et ceux qui doivent y aller abandonnent l'informatique ou sombrent dans la déprime (c'est vrai, là, s'éxagère un peu...)


Le mieux pour toi serait que que tu fasses l'experience douloureuse toi-même, tu verras, tu comprendras vite !

C'est d'ailleurs comme cela que je m'en suis rendu compte moi-même, et je ne revivrai plus jamais ça !!

[mat.M]

Bonjour ,

j'ai été pris de cours car je voulais poster un message avec sujet similaire avec comme titre "Avez-vous travaillé sur des projets "dégoutants"
( excusez pour la terminologie )

Je compatis avec ce qui a été affirmé précedemment
Tout ce que je peux dire :

RAS LE BOL des projets

* non commentés
* où des blocs sont copiés-collés sur des milliers de lignes
Par exemple une boucle qui commence

Code :

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

1
2
3
4
Pour valeur_initiale A valeur_finale 
 1000 lignes de code
Faire

Ou bien

Code :

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

1
2
3
4
5
6
7
8
Si condition Alors

copie colle 2000 lignes de code
Sinon 
copie colle 2000 lignes de code

Fin SI

*pas d'indentations


Je suis en train de reprendre un projet , la prestation a été facturée quelques milliers d'euros à un client final et cela traîne depuis des mois.
Et ce n'est malheureusement pas le premier projet que je reprends comme cela.
Dans la majorité de mes expériences en informatique ça a quasiment toujours été le cas sauf dans des grosses structures , pour des projets en équipe .

Bon OK tout le monde fait des erreurs , mais je ne comprends pas ce qui passe par la tête des gens , pourquoi ils ne structurent pas un minimum leur projet et qui développent comme ils pensent.
Il y a des personnes qui ne savent même pas ce que c'est qu'une procédure ou bien cela ne leur viendrait pas à l'idée de regrouper des traitements de donnée dans une procédure

Par exemple , vous bossez sur un projet de compta : logique que vous créez une fonction de calcul de TVA qui serve une bonne fois pour toute , non ??
Et appelée à plusieurs endroits du programme ?
Non , la personne qui est passée avant n'a pu faire cela.
Et qu'on ne m'avance pas l'excuse : manque de temps.

Cela fait penser aux dessinateurs comme Cabu et Plantu qui peuvent commencer leurs dessins par n'importe quel bout et parvenir au même résultat à la fin.

L'informatique et les arts se sont tout de même des choses différentes.

Dans ma sociètèe, nous vendons un progiciel qui fait environ 800 000 lignes de C++.

Damned !

Le patron qui pleure, c'est celui qui voulait se dépecher de vite finir, et qui se retrouve dans une situation catastrophique. Et là il se rend compte de son erreur (mai bien sûr, c'est trop tard)

Et de préciser aussi : qui est-ce qui trinque quand le projet est baclé ???

[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".

[mat.M]

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 .

[Invité]

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".

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!