Discussion :

[hachesse]

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

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

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

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

[Admin]

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

Il faut bien des specs ?

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

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

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

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

[Catbull]

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

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

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

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

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

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

[Admin]

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

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

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

[claudus]

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

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

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

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

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

[mat.M]

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

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

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

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

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

[ErwanVDF]

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

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

[Doloop]

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

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

La première fois que je me suis concentré pour commencer à créer véritablement un programme, ça ma déconcentré immédiatement de me voir concentré à ce niveau (d'un point de vue extérieur).
Le simple fait de se concentrer permet de voir immédiatement non seulement la solution, mais les solutions. Il suffit ensuite d'effectuer son choix par rapport aux besoins futurs du programme.
J'ai même cru qu'un moment que ces visions aller finir par s'arrêter un jour ou l'autre, mais ceux-ci se sont amplifier et solidifié avec l'expérience.
Cela me fait penser au jeu d'échecs, où l'on aurait déjà précaunisé toute la stratégie de mise à mort de l'adversaire.

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

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

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

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

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

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

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

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

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

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

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

@ +

[hachesse]

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

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

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

[iubito]

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

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

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

Bein en informatique c'est pareil !

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

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

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


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

[Catbull]

Lorsqu'il y a vraiment une difficulté d'un truc que l'on souhaite faire et que l'on ne sache pas encore faire, en se concentrant je ressens un flash (<1s) qui s'apparente à de la simulation accélérée, représentant la meilleure solution pour y parvenir, pour le reste c'est toujours la même chose, on sait déjà.

Penses-tu réellement ce que tu dis? Il est possible de définir la meilleure solution en moins d'une seconde?

Mince le monde de l'informatique doit être rempli d'abrutis (et j'en fais malheureusement partie) parceque l'unité de temps utilisé pour définir une solution (optimal ou pas) n'est pas la seconde et loin s'en faut...

Personnellement je ne pense pas que tu es une vision juste et réelle du monde de l'informatique mais plutot une vision romanesque dans laquelle le héros trouve toujours une solution même s'il ne lui reste qu'une seconde...

[iubito]

disons que la solution peut venir en une seconde, d'un coup... après longue réflexions. Tu cherches, tu cherches... et d'un coup boum! tu saute du lit à 4h du mat' et poc!poc!poc! sur le clavier => compil' => "youpiiii! ça marche"

lol

mes moments favoris pour réfléchir trankilou (que ce soit à de la prog, ou imaginer une compo musicale) c dans les transports, dans le bain, ou dans le lit

Dans le même style, Beethoven s'est écrit dans sa tête une bonne partie de sa sonate Appassionnata, alors qu'il était en balade avec un ami. Il n'a pas ouvert la bouche de toute la promenade, et quand il est rentré chez lui il s'est jeté sur son piano et a joué ce qu'il avait imaginé !

[Invité]

Le coup du "flash", pourquoi pas, mais en général ça arrive après avoir tourné et retourné un point précis dans ta tête. De là à spontanément résoudre des problèmes complexes, à froid et sans élan :

Je ne veux pas casser l'ambiance, mais faudrait redevenir sérieux...

[mat.M]

Iubito tu y vas un peu fort et je partage l'avis de FLorian et Catbul.
On peut avoir des "flash" mais tout de même la musique et l'informatique ce sont des choses différentes.
La musique relève plus de l'artistique ( bien qu'il y ait un côté technique comme le solfège etc...) , un sens inné ( ? ) artistique , avoir l'oreille musicale comme tu le suggères.
Certes il faut un minimum de technique pour écrire des partitions, faire des accords.

Alors que l'informatique c'est basiquement TRES technique , encore une fois je me répète un programme informatique c'est semblable à un jeu de construction type Meccano où il faut assembler des modules avec d'autres ou bien un méchanisme d'horloge suisse.
Si tu ne conçois pas un mode d'emploi "minimal" tu vas être vite perdu .

Un programme informatique répond plus à un besoin fonctionnel ( sauf à la rigueur un jeu vidéo mais cela demeure basiquement technique aussi ) tandis qu'un morceau de musique c'est un mode d'expression....

[iubito]

dans les 2 cas c'est une construction, construction d'une symphonie ou construction d'un programme. Tout comme un architecte conçoit une maison, ou un menuisier un meuble.

Il y a du technique, et il y a de la création (de l'artistique).

Le musicien a sa clé de sol et son solfège,
Le menuisier a ses outils et ses bouts d'bois,
L'architecte a son crayon et son papier,
Le programmeur a son clavier et ses langages.

(manque plus que les rimes et un pied dans le 3e vers et ça fait un alexandrin.... je crois )
hem...bon... tout ça pour dire qu'un esprit créatif c'est très bon pour un programmeur

Pour le musicien c'est se jouer la mélodie dans sa tête, le menuisier et l'architecte c'est se représenter l'ouvrage dès le début, et pour le programmeur ça va être faire tourner un algo, ou voir le déroulement entier de son application écran par écran...

voilà quoi...

[epeios]

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ée aucune qui me convenait, je les ai conçus moi-même. Grâce à ces outils, écrire un programme consiste simplement à écrire les différents algorithmes mis en oeuvre 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 oeuvre 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 ou je l'écris, je le 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 mets 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. A 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, puisque qu'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 permet 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 oeuvre 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é écris 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) ...

[iubito]

Et, comme vous pourrez le constater en vérifiant la date à laquelle il a été posté, ce message a été écris 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) ...

moi aussi !

non je tenais juste à préciser moi aussi c'est important

[sequentaire]

Je pense qu'il faut éviter d'être sectaire, et considérer la programmation spontanée - j'en fais sans savoir que cela s'appelle comme ça - est un des outils du programmeur.

Il m'arrive souvent de programmer en considérant que ce que j'écris est si clair que il n'y a pas besoin de mettre de commentaires. Mais je m'aperçois que, s'il s'écoule un grand moment entre deux séquences de travail, j'ai du mal à retrouver pourquoi j'avais écrit telle ou telle chose. L'algo reste clair, mais je ne me souviens plus à quoi il sert. Aussi, de plus en plus, je m'astreins à commenter le pourquoi, à expliquer le cadre, à donner les justifications de mes choix ; un peu le niveau guide, quoi.

Egalement, je crois que ce mode de programmation fonctionne mal lors des travaux en groupes. Certes le programme spontanée est clair, mais il ne l'est qu'après avoir été écrit ; hors, en programmation en groupe, il faut que ce soit clair avant.

Que l'on ait un flash d'une seconde ou de 15 mn, dans sa baignoire ou au bureau n'est pas le problème, le problème est qu'il faut être capable de l'expliquer à ses petits copains, que tout le monde ait compris la même chose, et que ce qui sera écrit corresponde réellement à ce qui a été expliqué et convenu. Le cas typique est une personne qui écrit l'algo, une autre qui écrit le test. Cela c'est difficile à faire sans outils périphériques tel UML, une méthodologie, et autre.

[iubito]

Pour ce qui est du terme jusqu'à ce matin je ne savais pas vraiment que ça existait.

Pour le travail en groupe, quand je vois ce qu'on a fait à l'IUT. 14 semaines sur un projet... les premières étapes de Merise ont été utiles (surtout celle pour dire les données et les tables!), certains modèle on les a juste fait pour faire plaisir à un des jury (l'otr' n'y comprenais rien ).

Au boulot, bon j'arrive sur un programme déjà existant qu'il faut améliorer. Il manque parfois de commentaire, mais quand y'a une base de données hyper complexe et une multitudes d'écrans... beaucoup de chose n'étaient pas prévues au départ (quand le collègue a commencé y'a 5 ans).

Comme schéma on a un enchaînement des écrans, et un MCD géant (en police taille 6 ) où il manque des tables

Après c'est des petits commentaires dans le code.
Quand j'ai une idée sur un détail, parfois je vais l'écrire en français avant l'algo, mais j'vais pas m'amuser l'écrire en UML ou Merise ailleurs.

Une méthode que j'avais trouvé assez sympa c'était la SADT, mais je suis tellement bordellique et illisible sur du papier, que j'préfère écrire en français un 'tit commentaire avant mon algo

[Admin]

J'ai l'impression d'etre dans la quatrième dimension !

Que vous puissiez avoir des "flashs" pourquoi pas, mais plus dans le contexte que florian à dicter, celui d'une longue réflection puis la solution apparait d'un coup, mais maintenant avoir juste le problème et le résoudre dans le seconde, désolé je peux pas y croire, ou alors c'est des problème de syntaxe....

Maintenant cela peut dépendre de l'application, quand j'etait plus jeune, je codais à l'arrache des petites applications, mais des que tu abordes des applications compliqués je vois mal comment tu peux faire.

essaye de me trouver l'algorithme le plus rapide pour le retournement d'une matrice par la méthode de Gauss en moins de 3 heures....