IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Qui pratique la programmation spontanée ?


Sujet :

Débats sur le développement - Le Best Of

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Nouveau membre du Club
    Inscrit en
    Décembre 2003
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 7
    Par défaut Qui pratique la programmation spontanée ?
    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.

    @+

  2. #2
    Membre chevronné
    Avatar de hachesse
    Inscrit en
    Mars 2002
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 189
    Par défaut
    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/

  3. #3
    Membre confirmé
    Profil pro
    Ingenieur
    Inscrit en
    Décembre 2003
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingenieur

    Informations forums :
    Inscription : Décembre 2003
    Messages : 138
    Par défaut
    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

  4. #4
    Membre Expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    Juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Juin 2004
    Messages : 2 932
    Par défaut
    Moi, je programme comme toi

    Sinon :
    Citation Envoyé par 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...
    En fait c'est plutot l'inverse : c'est parce que j'ai sentis/compris l'ensemble du programme que je me passe de l'algorithme : je t'assure que ça vient tout seul...
    En fait je commence en "structurant" de façon globale mon programme, puis petit à petit je descend dans les détails. En gros je crée mon algorithme avec le langage de programmation que j'utilise.

    Celà dit, il m'arrive parfois (c'est rare) d'avoir recours à un petit croquis, ou des prendre des notes sur telle ou telle variable importante. J'ai toujours un bloc note à portée de main.
    Citation Envoyé par quicky2000
    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
    Ben si, j'y arrive aussi (18000 lignes de code environ, ça m'est déjà arrivé)

    Celà dit, ça ne m'empêche pas de bien documenter après (procedures, structure des fichiers utilisés, reprise des annotations et croquis sur mon bloc-note, etc...)...
    Sinon, je comprends que ça puisse être difficile de comprendre ce que j'ai fait pour ceux qui passent après moi.

    Enfin, je suis aussi un accroc du developpement...

  5. #5
    Membre Expert
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    Décembre 2004
    Messages
    2 493
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2004
    Messages : 2 493
    Par défaut
    La programmation spontanée c'est pour ceux qui ne savent pas que le dévelloppement est un cycle. C'est pour les pisseurs de code quoi !
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  6. #6
    Membre Expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    Juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Juin 2004
    Messages : 2 932
    Par défaut
    Citation Envoyé par Hephaistos007
    La programmation spontanée c'est pour ceux qui ne savent pas que le dévelloppement est un cycle. C'est pour les pisseurs de code quoi !
    1) En tout cas je sais que développement ne prend qu'un "l"
    2) Faut pas pisser à coté c'est sur, sinon ça ne fait pas propre après... (je parle de la propreté du code bien sur !)

    Excuses moi, ce n'est pas méchant mais c'est vrai que je n'ai pas pu m'en empêcher.

    Blague à part : rien n'empêche d'être structuré dans ce style de programmation. Tout comme dans la façon "académique" de le faire, si tu ne suis pas certaines rêgles, tu ne risques pas d'aller bien loin...

    En fait, je ne pense pas que le problême soit la façon de faire, de programmer, de développer mais plutôt un problême de rigueur dans le style que tu choisis.

    J'ai vu des projets abominablement codés et documentés aussi bien chez les "pisseurs de code" (on est d'accord là dessus), que chez les (appelons les comme ça) "Académiques" (si, si je vous le jure, livré à la DGAC par une boite très connue - j'ai peur de facher en donnant le nom de l'entreprise... ne m'en voulez pas si vous travaillez chez eux : GFI), ou à contrario des codes magnifiquement documentés dans les deux camps.

    Celà dit, il faut être honnète et reconnaitre que le style "Académique" conduit à un tout (Expression du besoin/Cahier des charges/Code/Documentation/Formation/Maintenance) acceptable plus souvent qu'avec "l'Extreme Programming" (je n'aime pas ce terme, mais bon).
    Bien souvent, les mauvais résultats donnés par les "pisseurs de codes" proviennent du fait qu'ils ne connaissent pas, ne se fixent pas, nient ou rejettent (bandes de fainéants vas..) la rigueur nécessaire à un développement correct.

    Il ne faut donc pas, selon moi, s'enfoncer dans un "absolutisme 100% comme ça" qui n'existe pas.

    Personnellement, j'estime avoir la chance d'avoir les facilités qui me permettent de me passer d'un algorithme (il est modeste le gars...), mais ça ne m'empêche pas d'être rigoureux dans mon travail et d'obtenir, malgrès le scepticisme que je comprend, des résultats apréciés de tous (les utilisateurs, et ceux qui passent derrière moi); Et c'est tout ce qui compte à mes yeux... C'est à la fin du bal que l'on compte les musiciens, pas vrai ?

  7. #7
    Membre Expert Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Par défaut
    Citation Envoyé par waskol
    bandes de fénéants vas..
    La fainéantise ne prend pas deux e accents aigus.

    Citation Envoyé par waskol
    Personnellement, j'estime avoir la chance d'avoir les facilités qui me permettent de me passer d'un algorithme (il est modeste le gars...)
    En réalité, tu ne te passes pas d'un algorithme. Tu te passes de la description manuscrite d'un algorithme, ça oui. Mais c'est le cas de beaucoup de développeurs, je pense.

    Comme tu parles de musiciens après, c'est un peu comme si tu disais que les musiciens se passaient de la notion de mesure, de gamme ou du rythme pour jouer ou improviser, tout ça parce qu'ils ont "le rythme dans la peau".
    En réalité, ils ne s'en passent pas, mais ils sont tellement habitués (ou doués) qu'ils se passent peut-être volontiers des partitions.

    Dans la discussion de ce sujet, c'est pareil, il me semble.

    Par contre, tout comme je souhaiterais bonne chance à un musicien qui composerait de tête un morceau de 35 minutes, je souhaiterais bonne chance à un développeur qui "pisserait du code" sur 50000 lignes.

  8. #8
    Membre éprouvé Avatar de alexrtz
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2003
    Messages
    639
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juin 2003
    Messages : 639
    Par défaut
    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.

  9. #9
    Membre chevronné
    Avatar de hachesse
    Inscrit en
    Mars 2002
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 189
    Par défaut
    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

  10. #10
    Membre éprouvé
    Avatar de Asdorve
    Homme Profil pro
    Inscrit en
    Mars 2004
    Messages
    1 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : Mars 2004
    Messages : 1 336
    Par défaut
    Citation Envoyé par hachesse
    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.
    Salut à tous, j'arrive un peu en retard, mais ce que tu dis, Hachesse, n'est pas forcément le cas.

    Personnellement, j'ai participé à un projet de fin d'étude en bts informatique qui a duré 5 mois. Certes, nous avons passé pas mal d'heure à réfléchir à 6 sur le cahier des charges. Puis ensuite nous nous sommes mis à programmer après avoir fait toute la partie "analyse".

    Toutefois, nous nous sommes heurtés à des problèmes auquels nous n'avions pas prété attention au départ, qui nous ont obligé à changer d'optique et de revoir notre manière de procéder.

  11. #11
    duj
    duj est déconnecté
    Membre chevronné

    Profil pro
    Inscrit en
    Juillet 2003
    Messages
    141
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2003
    Messages : 141
    Par défaut
    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...

  12. #12
    Membre Expert
    Avatar de e-ric
    Homme Profil pro
    Apprenti chat, bienfaiteur de tritons et autres bestioles
    Inscrit en
    Mars 2002
    Messages
    1 568
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Apprenti chat, bienfaiteur de tritons et autres bestioles

    Informations forums :
    Inscription : Mars 2002
    Messages : 1 568
    Par défaut
    Citation Envoyé par duj Voir le message
    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...
    Cela me semble très théorique, t'as sans doute jamais travaillé sur un projet de merde où il faut rendre les copies la veille... Passer des heures à concevoir n'est pas forcément un gage de réussite, j'ai déjà vu des "super" projets où tout était conçu sur plusieurs mois et qu'on laissé quelques semaines pour coder, bon courage... Après c'est aux développeurs de maintenance de panser les plaies...

    M E N S . A G I T A T . M O L E M
    Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal

    "La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
    Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."

  13. #13
    Membre très actif
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2008
    Messages : 612
    Par défaut
    Salut
    -----

    Pour ma part, je pense que travailler sans fil conducteur est une hérésie. Mon expérience concernant les débutants, par exemple, me montre que ceux qui tentent l'aventure sont les premiers à crier au secours et à afficher du code totalement déstructuré.

    Maintenant faut-il dessiner un ordinogramme ou écrire un pseudo-code systématiquement? Ma réponse est mitigée:

    Déjà si on est débutant, c'est clairement "oui, il faut le faire".

    Si on est expérimenté, on peut arriver à s'en passer selon les cas, mais cette "impasse" n'est souvent qu'une apparence et non une véritable lacune.

    En effet, si je prends mon propre cas, quand je commence un projet, j'utilise souvent un papier pour y griffonner les réflexions, la façon de distribuer les bits d'une trame, d'organiser mes données en mémoire, et autres "stratégies". Rien de formel, juste une base de réflexion.

    Ensuite, il m'arrive de commencer à coder, sans ordinogramme apparent.

    MAIS ça ne veut pas dire qu'en fait il n'y a pas un fil conducteur, c'est juste que, selon la taille et la complexité du projet, selon la cible et le langage, il m'arrive souvent de "voir" dans ma tête l'organisation de mon code, de façon "claire". L'ordinogramme, le fil conducteur, la structure, existent donc en réalité, ils ne sont simplement pas forcément transcrits. Il m'arrive même dans ces cas-là de commencer mon code par les commentaires, sorte de pseudo-code directeur.

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

    Maintenant, il est clair également que si on travaille à plusieurs sur un même projet, qu'on est bien contraint de formaliser par écrit la route à suivre, si on ne veut pas que chacun parte de son propre côté. Je travaille actuellement sur un projet à base de plugins: j'écris la base, puis les docs, et ensuite on continue en groupe à partir des documents écrits, en sachant explicitement où on va et comment on y va.

    A+
    Claude

  14. #14
    Invité
    Invité(e)
    Par défaut La programmation mentale
    Crévindiou ! C’est-y donc qu’l’est point crevé, l’bestiau, qu’y bouge encore ? Plus de 16 ans qu’il a le p’tiot !... Et plus de 110.000 affichages !
    Bon, moi, je ne l’ai connu qu’en 2008, il avait déjà quatre ans. Il s’est assoupi 5 ans de 2008 à 2013 puis s’est à nouveau endormi pendant 7 ans. Il faut une bonne raison pour le réveiller.

    La raison, c’est que j’ai publié dernièrement un blog dont l’un de mes billets répond à la question de Doloop :

    Citation Envoyé par Doloop Voir le message
    Ce type de programmation porte-t-elle un autre nom ?
    C’est l’été 2018 et adepte de ce type de programmation, la question de Doloop me taraude le cerveau alors que j’aborde le sujet dans mon blog.

    Quand je suis dans ces dispositions, je cours. Ce matin là, je décide donc d’aller courir avec la ferme intention de lui trouver un autre nom, moins polémique. Je n’ai pas fait 300 mètres que l’idée s’invite dans mon esprit, tel un flash aurait dit Doloop. L’idée, c’est le parallèle devenu évident entre le calcul mental et ce type de programmation. Je termine mon footing en cherchant la faille, en me persuadant que c’est bien là, la locution idéale, que je cherche. Et puis, c'est une façon élégante de clore cette discussion. Je vous livre le fruit de ma réflexion sur le sujet…



    Billet : La programmation mentale

    Ce blog est une monographie fragmentée en plusieurs billets pour des raisons de volume.
    Un billet SYNOPSIS faisant office de SOMMAIRE agrège ces billets via des liens hypertextes.

    ■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

    • Le calcul mental
    • Programmer mentalement
    • Utiliser sa mémoire procédurale plutôt que sa mémoire immédiate
    • Sophrologie et apprentissage procédural
    • Programmation spontanée
    • Flash
    • Apprendre / Comprendre
    La programmation mentale procède de la même manière que le calcul mental.

    Le calcul mental

    Source : Les astuces en calcul mental pour mieux calculer (Superprof Magazine)

    Si certains ont des facilités, cela ne veut pas dire qu’il s’agisse de capacités innées. C’est une aptitude qui se travaille.

    Certains scientifiques ont pu déterminer que le calcul mental active des zones du cerveau liées à l’attention spatiale. La représentation des nombres serait ainsi comparable à la représentation spatiale. Quand on compte, qu’on additionne ou qu’on soustraie, c’est comme si on faisait mentalement un déplacement vers la droite ou la gauche pour trouver un résultat. Une donnée importante quand on a des difficultés en calcul.

    D’autres chercheurs se sont intéressés à Rüdiger Gamm, un génie du calcul mental, pour comprendre comment il parvenait à calculer de tête si facilement et résoudre des opérations incroyablement complexes.

    Il apparaît dans ce cas que le génie du calcul, active des zones temporales préfrontales du cerveau, généralement impliquées dans la mémoire à long terme. Il dispose ainsi d’une multitude d’informations enregistrées qui lui permettent de battre des records de rapidité dans ses calculs.

    Ce qu’il faut retenir, c’est que notre mémoire est notre meilleure alliée pour devenir bon en calcul !

    Quoi qu’il arrive, la pratique du calcul mental doit être récurrente, régulière, environ 10 minutes par jours suffisent : notre cerveau doit acquérir des automatismes et pour cela, rien ne vaut de rabâcher encore et encore les mêmes formules, les mêmes calculs jusqu’à ce que cela devienne évident et naturel, comme le fait de faire du vélo ou simplement de respirer.

    Le calcul mental s’exerce aussi bien à l’oral qu’à l’écrit et cette pratique doit s’appuyer sur des supports et des outils divers comme un cahier, un fichier de mathématiques, une ardoise, des cartes, des dés, un logiciel, etc.

    Les outils basiques pour booster notre capacité en calcul mental :

    • Les tables d’addition et de multiplication,
    • Les connaissances des compléments du nombre 10,
    • Connaissance des carrés jusqu’à 15² (=225) ainsi que des puissances de 2. Petite astuce concernant les puissances de 2, ce sont les mêmes que les tailles de stockage des disques durs ou des cartes mémoires (8 go, 16 go, 32 go, 64 go, 128 go…). Facile, non ?
    • Technique de multiplication par des puissances de 10 avec des exposants négatifs (il faut déplacer la virgule vers la gauche) et des exposants positifs (déplacer la virgule vers la droite),
    • Utilisation de la propriété « Diviser par un nombre = multiplier par son inverse », par exemple, diviser par 0.25, c’est multiplier 4),
    • Apprendre les identités remarquables : (a+b) ² = a²+2ab+b², (a-b) ² = a²-2ab+b², (a+b) (a-b) = a²-b²,
    • Apprendre les règles de la factorisation,
    • Connaître des ordres de grandeur comme pour ϖ (3.14159), nombre d’or (1.618), racine de 2 (1,41).

    Penser pratique !

    Chacun doit trouver la méthode la plus efficace pour lui, un peu comme lorsqu’on apprend une langue et qu’on pense à des repères mnémotechniques que seul nous pouvons comprendre. L’important est que cela fonctionne pour nous et notre cerveau.

    Exemple : en cas de panne avec la table de multiplication par 9. Il suffit de visualiser ses dix doigts levés, de baisser mentalement celui qui correspond au chiffre que l’on souhaite multiplier par 9, puis de compter le nombre doigts levés à gauche et à droite du doigt baissé. Soit 4 x 9 : on baisse le quatrième doigt, il est alors facile de compter mentalement 3 doigts à gauche et 6 à droite, donc 4 x 9 = 36.

    On se rend compte que pour progresser en mathématiques et notamment en calcul mental, la question de la mémorisation est très importante : on doit apprendre par cœur les principes de base des mathématiques, connaître ses tables d’addition et de multiplication. Répétez sans cesse, encore et encore. Si on ne les pratique pas, on oublie !

    Plus on entraîne son cerveau à se souvenir, plus des automatismes apparaissent et plus notre capacité en calcul mental augmente. Pour progresser, il faut s’entrainer, mettre en place diverses stratégies pour que les choses deviennent naturelles.

    Cela demande, bien sûr, du temps, de l’investissement personnel mais le résultat en vaut franchement la chandelle puisque l’on conserve ces réflexes toute notre vie par la suite.


    La première chose à garder en tête est que le calcul mental n’est pas inné.

    • L’on pourrait résumer en deux mots l’idée du progrès en calcul mental : astuces et répétition. Effectivement, sans avoir jamais entendu ou constaté par soi-même qu’un nombre divisible par 9 l’est parce que la somme des chiffres qui le compose est un multiple de 9, sans connaître l’astuce pour multiplier tous les nombres entiers par 11, il est parfois difficile de calculer plus rapidement.

    • Ceux qui calculent ne sont pas nécessairement des génies, ils ont juste conscience de ces astuces, les ont utilisés plusieurs fois jusqu’à ce qu’elles deviennent presque naturelles. Car comme toute chose, il ne suffit pas d’avoir simplement déjà eu connaissance de ces astuces pour progresser, il faut les utiliser. La répétition permet d’intérioriser chacun des processus et cela n’est pas simplement vrai que pour le calcul mental.

    Cette gymnastique de l’esprit prend réellement corps à mesure que l’on fait des opérations. Le cerveau va développer avec la répétition, des raccourcis logiques qui permettent de calculer bien plus rapidement.

    Programmer mentalement

    Mentaliser sa programmation, c’est s’affranchir des contraintes, des carcans, des méthodes rigides, des algorithmes modélisés, des normes, des documentations, etc. C’est se simplifier la vie, épurer sa démarche, être autonome, prendre des raccourcis pour être efficace.

    La programmation mentale n'implique pas "arrache", "bidouille", "manque de qualité", "affinité avec certains problèmes spécifiques", "intuition", "aucune analyse", etc… comme l’affirment ceux qui condamnent le concept sans même le comprendre. Bien au contraire, cela signifie que dans sa tête, il faut être en quelque sorte "câblé", que le programmeur maîtrise son sujet, qu'il se soit interrogé, qu'il ait installé puis personnalisé sur son petit disque dur (sa mémoire procédurale) diverses méthodes de développement et de travail lui permettant d'avancer sans se tenir à son trotteur.

    Reste à exprimer le non-dit, à identifier quels acquis ont participé à un formatage cérébral libérateur des contraintes conventionnelles. Mais la programmation mentale est difficilement verbalisable car elle concerne l’acquisition d’automatismes, la mise en place de stratégies pour que les choses deviennent naturelles. Il appartient à chacun de trouver la méthode la plus efficace pour penser pratique, un peu comme lorsqu’on pense à des repères mnémotechniques que seul nous pouvons comprendre.

    Les développeurs arcboutés sur leurs conditionnements universitaires attribuent à cette démarche tous les maux qu’ils rencontrent dans leur environnement. Cela ne fait que révéler leur incapacité à entreprendre une démarche personnelle. La qualité de la programmation mentale est exceptionnelle car elle est inspirée par une réflexion murie.

    L'important, c'est de témoigner que l'on peut développer autrement. Ceux que cela dérange ne sont pas obligés de changer leur façon de travailler.

    Utiliser sa mémoire procédurale plutôt que sa mémoire immédiate

    Il s’agit de substituer au développement jouissif exploitant la mémoire immédiate, la maitrise d’un développement sur le court, le moyen et le long terme.

    La passion du codage pour le codage doit satisfaire les addicts au jeu. Cela doit correspondre à un mode de raisonnement par conditions qui participe à une programmation jubilatoire exploitant la mémoire immédiate. Ce faisant, c’est la personnalité du programmeur qui structure la programmation et non le raisonnement sur la base des actions. La maintenance du programme consiste alors à comprendre la démarche alambiquée du programmeur plutôt que d’en comprendre les fonctionnalités.

    Quand on a assimilé le raisonnement par traitements (LCP), le codage est là où il doit être, comme il doit être et rien de plus. L’intérêt du codage est moins dans le fond que dans la forme, à savoir l’adoption de règles d’écriture.

    Ne pas exploiter sa mémoire immédiate mais sa mémoire procédurale oblige à s’organiser, à structurer sa pensée (LCP), à s’inventer une codification, une normalisation, une charte graphique (indentations, minuscules/MAJUSCULES, etc.), à se créer des automatismes simplificateurs, à construire cette mémoire procédurale pour être en mesure de programmer facilement, rapidement, sainement, et de toujours être capable de se relire, de comprendre ce que l’on programme. Ainsi, l’algorithme se concrétise mentalement en même temps que la prise de connaissance et l’exploration de la fonctionnalité à programmer. La démarche algorithmique structurée dans la mémoire procédurale s’adapte instinctivement à la spécificité de la fonctionnalité.

    La mémoire procédurale est également très sollicitée chez les sportifs de haut niveau comme chez les artistes : elle permet d’acquérir des procédures gestuelles parfaites et atteindre l’excellence dans une discipline sportive ou un domaine musical… ou dans le développement informatique.

    La mémoire procédurale fait partie des types de mémoire qui résistent le mieux aux années qui passent. Elle occupe ainsi une place majeure de notre mémoire à long terme. Les souvenirs qui y sont stockés sont en réalité une association de savoir-faire : des automatismes que nous avons enregistrés à force de répétition.

    La mémoire procédurale est considérée comme une “mémoire implicite”, c’est-à-dire inconsciente. Il existe une phase explicite d’apprentissage en début d’acquisition, puis la procédure s’automatise et sa mise en œuvre finit par ne plus demander d’effort mental particulier. Nous appliquons, comme par réflexe, la méthode gestuelle que nous avons acquise lors de notre apprentissage.

    Sophrologie et apprentissage procédural

    Je l’ai évoqué à plusieurs reprises dans des discussions sans faire le rapprochement avec la mémoire procédurale, avec ce que j’appelle dorénavant la programmation mentale.

    Comme pour le calcul mental :

    • la pratique de la programmation mentale doit être récurrente, régulière.

    • Plus on entraîne son cerveau à se souvenir, plus des automatismes apparaissent, plus des raccourci logiques se créent et plus notre capacité en programmation mentale augmente. Pour progresser, il faut s’entrainer, mettre en place diverses stratégies pour que les choses deviennent naturelles.

    • Les progrès en programmation mentale reposent sur les astuces et la répétition. La répétition permet d’intérioriser chacun des processus.

    La sophrologie participe à ce que l’on appelle l’apprentissage procédural.

    Discussion : Qui pratique la programmation spontanée ?

    IFA2377 :
    Je ne vais pas reprendre tout ce qui s'est dit dans cet esprit depuis plus de quatre ans. Je rappelle simplement quelques-uns de ses premiers arguments pour identifier sa façon de fonctionner que j'assimile à la "sophrologie".

    Le Docteur Alfonso CAYCEDO, psychiatre d’origine colombienne, ne formalisa le concept qu’à partir de 1960. Sa « RELAXATION DYNAMIQUE » comme il l’appelle alors, synthétise et occidentalise les pratiques du Yoga, du Bouddhisme et du Zen. Leurs effets sur la conscience humaine devant lui permettre de traiter ses patients.

    Intuitivement mais consciemment, je pratique la sophrologie depuis toujours. C'est en quelque sorte un mode de vie. Beaucoup de personnes la pratiquent sans le savoir. Pour ma part, j'ai toujours eu conscience de fournir l'effort mental qui consiste à se sophroniser. Les principaux domaines pour lesquels j'ai ou j'ai eu recours à la sophrologie sont les études, le sport de haut niveau, mon métier de développeur, la conduite automobile, etc.

    Je n'ai mis un mot sur ce que je pratiquais, qu'à l'occasion de la naissance de mon ainé, en 1977. Un médecin, le docteur Davrou, proposait alors à un groupe de femmes enceintes de les préparer à l'accouchement par la sophrologie. Le docteur Davrou enseignait déjà les pratiques de la sophrologie aux cancéreux en phase terminale. Il s'impliquait également dans le sport, notamment dans l'entraînement de l'équipe nationale de volley-ball.

    Petite digression à propos de la sophrologie et du sport :

    Disciple du Docteur Alfonso CAYCEDO depuis 1963, le docteur Raymond ABREZOL est l’un des premiers Sophrologues à avoir adapté les techniques sophrologiques au sport (dès 1966).

    Manuel AGUILA (SOPHROLOGIE ET SPORT) décrit l’entraînement sophrologique comme une stimulation de l’imagination par le biais de phases de visualisation : « L’athlète découvre cet état particulier où il peut corriger les épreuves qui le nécessitent et programmer ses futures performances. Lors d’une compétition, son cerveau met tout en œuvre pour reproduire ce qui a été précédemment enregistré. Au-delà de l’apprentissage technique conscient survient l’art. L’atteinte de ce niveau de réalisation, dans le cadre sportif, passe par ce que l’on nomme "le lâcher prise".

    En associant les pratiques sophrologiques à son entraînement, on intervient sur sa capacité de concentration et d’attention, son énergie et sa puissance physique, sa capacité de récupération après l’effort, sa motivation et sa combativité, d’éventuelles inhibitions, la confiance en soi et en ses potentiels, l’image que l’on a de soi-même, l’intégration de son schéma corporel, la sensibilité interne de son propre organisme (apprentissage des mouvements – cénesthésie, synesthésie, somesthésie), la fluidité de ses mouvements, la mémorisation de ses séquences sportives, la gestion de son seuil de douleur, sa capacité à gérer le stress, etc. ».

    Concrètement, la sophronisation de l’athlète peut être vue comme un travail mental d’auto-programmation, de maîtrise de soi dans l’espace et dans le temps, chaque paramètre (effort, récupération, concentration, motivation, etc.) s’intégrant dans l’approche globale d’un ou plusieurs objectifs. Les athlètes se sophronisent tous plus ou moins consciemment et à des degrés divers. Au début du siècle dernier, lorsque le lanceur de poids Raoul PAOLI, en pleine concentration, demande à un athlète venu l’encourager, de le laisser tranquille parce qu’il est en train de devenir champion olympique, n’était-il pas en phase de visualisation pour utiliser le langage d’aujourd’hui. C’est sans doute sur les sautoirs, notamment celui de la hauteur, que les athlètes extériorisent le plus leur processus de sophronisation en mimant le saut qu’ils visualisent mentalement.

    Je me suis permis cette parenthèse sportive pour mieux concrétiser l'effort mental que représente la pratique de la sophrologie et assimiler son principe dans une démarche de développement.
    Programmation spontanée

    Il est fait ici référence à une discussion ouverte par Doloop le 28/12/2003 et qui s’est prolongée jusqu'au 22/07/2008, soit pendant 4 ans ½.

    Dans son texte initial, il se demandait si ce qu’il appelle la programmation spontanée portait un autre nom. Le thème de la discussion étant très proche de mes préoccupations, il était intéressant de prendre connaissance des arguments échangés puis d’apporter mon point de vue.

    Discussion : Qui pratique la programmation spontanée ?

    Doloop :

    Salut à tous,

    Je souhaiterais savoir si beaucoup de personnes programment 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'autres, il y a des posts qui me semblent confirmer que oui.

    L'auteur d'un livre dans les années 80, annonçait 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 se focaliser 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.

    Face à un bug, aucune panique par rapport à nos débuts, 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 la mémoire qui retient facilement les récitations, en contrepartie j'utilise la mémoire dite procédurale.

    La mémoire procédurale est peut être la mémoire la plus sollicité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 prouve 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.

    @+
    ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

    Sans reprendre tout ce qui s’est dit en plus de quatre ans, je comprends tout-à-fait ce que veut dire Doloop quand il dit :

    • Devant le clavier, on sait immédiatement ce que l'on a à faire, il suffit de transposer sur l'écran ce que l'on voit mentalement.

    • L'algorithme, on l'invente directement dans le programme au fur et à mesure des besoins qui se font ressentir au moment de se focaliser sur des points précis.

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

    • Une personne sur un autre forum disait qu'il devenait en quelque sorte le programme.

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

    • Avec l'expérience, par concentration, les solutions sur les points délicats des programmes, apparaissent dans la tête sous forme de flash.

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

    • La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode.

    • Je n'ai jamais prétendu que la programmation spontanée était facile surtout au début, cela demande beaucoup d'effort mental à cause de tout ce qu'il y a à apprendre, ensuite c'est l’expérience qui fait le reste.

    • Un programme qui emploie des noms de variables, de sous-programmes et de fonctions significatifs pour moi contient plus d'informations que nécessaire, c'est comme pour le Port-Salut, c'est marqué dessus.
    • Qu'est ce que l'on peut apprendre lorsque l'on est obligé de tout faire !

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

    • À chaque programme réalisé, l'autosatisfaction est quasi inexistante, on est content que le programme soit terminé, on n'est pas déçu mais sans plus, on pense davantage au prochain qu'à celui qui vient d'être fait.

    • La seule envie finale, c'est de surpasser le programme, pour que ce ne soit plus le programme qui nous dépasse.


    Doloop disait :

    - Je rajoute une information qui me concerne et qui a peut-être son importance, c'est que je n'ai pas la mémoire qui retient facilement les récitations, en contrepartie j'utilise la mémoire dite procédurale.

    - La mémoire procédurale est peut être la mémoire la plus sollicitée pour programmer ?

    ErwanVDF lui répondait :

    - Je pense que la plupart des gens ne comprennent même pas ce que tu entends par là.

    Flash

    Le flash évoqué par Doloop correspond en quelque sorte à un alignement des planètes ou au jackpot d’une machine à sous. Pendant que l’esprit réfléchit à un problème, plusieurs zones du cerveau « tournent » en arrière plan, notamment les zones impliquées dans la mémoire à long terme. À un moment donné, un détail de la réflexion en cours réveille les processus en tâche de fond, une réaction en chaine se déclenche et apporte la solution aussi soudaine qu’évidente. Le flash devient l'aboutissement conscient, contrôlé, maîtrisé de la solution.

    Nom : Mémoire.jpg
Affichages : 484
Taille : 29,1 Ko

    La perte de la mémoire immédiate :

    De façon schématique, le processus de mémorisation peut se décrire en 4 phases :

    1. L’apprentissage : analyse immédiate de l'information sensorielle ;

    2. La mémoire immédiate : persistance au niveau cérébral de la trace sensorielle. L'ensemble des informations ainsi conservées constitue l'empan de la mémoire (quantité d'informations pouvant être stockées par la mémoire à court terme).

    3. Le stockage mnésique : regroupement des données et leur codage. Ce stockage dépasse l'empan. Il est basé sur l'élaboration de processus associatifs et comporte une phase de consolidation dans le temps qui évite la perte d'information.

    4. Le rappel mnésique : réutilisation des informations stockées. Si le sujet les raconte ou les revit mentalement, c'est l'évocation. S'il les retrouve lors d'une nouvelle confrontation, c'est la reconnaissance.

    On distingue plusieurs sortes de troubles de la mémoire (amnésies) :

    1. L'amnésie antérograde (syndrome de Korsakoff) : le patient ne fixe plus les souvenirs et oublie tous les événements au fur et à mesure qu'ils se présentent. C'est une amnésie des faits récents alors que le souvenir des faits anciens est conservé.

    2. L'ictus amnésique : perte de mémoire isolée, antérograde, chez un sujet âgé de 50 à 70 ans, sans cause déclenchante apparente, sans signes prémonitoires, durant quelques heures et ne laissant comme séquelle qu'une amnésie lacunaire pour cette période. Le malade est incapable de se souvenir de ce qu'il vient de faire : il pose les mêmes questions et répète sans arrêt les mêmes choses. En revanche, il connaît son âge et son identité. Les capacités intellectuelles sont conservées. C'est en général un incident bénin et sans cause.

    3. L'amnésie globale concerne les faits récents et anciens et se voit dans les démences.

    La mémoire procédurale

    La mémoire procédurale est une forme de mémoire non déclarative. La mémoire procédurale est une mémoire à long terme implicite qui permet la motricité automatique. Elle concerne l’apprentissage et le stockage des savoir-faire comme jouer du piano, faire du vélo, planter un clou, marcher, etc. En pratiquant ces activités, la mémoire améliore nos performances jusqu’à créer des automatismes. C’est une mémoire que l’on active alors de façon quasi inconsciente. Cette mémoire n’est donc pas verbalisable puisqu’elle ne concerne que des mouvements.

    Elle fonctionne grâce à différentes zones du cerveau, comme le cervelet ou le striatum. Ces zones sont toutes reliées entre elles par des synapses fonctionnant avec des neurotransmetteurs. Cette association permet l’apprentissage progressif de procédures. Celles-ci sont d’abord traitées par la mémoire déclarative et de travail puis sont intégrées dans la mémoire procédurale grâce à la répétition.

    Mémoire à long terme

    La mémoire à long terme est essentielle pour pouvoir progresser. Il n’existe pas “un” centre de la mémoire dans le cerveau, mais bien plusieurs réseaux neuronaux distincts interagissant entre eux. Ils sont observables notamment par IRM au cours de tâches de mémorisation. Un élément à mémoriser est constitué des diverses informations sensorielles, temporelles ou encore émotionnelles. Elles ne sont pas conservées au même endroit.

    Le cerveau conserve le souvenir de la synchronisation de ces différentes informations. Un souvenir n’est pas un enregistrement forcément valide de la situation réelle et peut varier au cours du temps. Lorsque l’on se souvient, la tâche de reconstruction du cerveau peut être plus ou moins fidèle selon la date du souvenir, et est influencée par le présent.

    Les mémoires s’appuient les unes sur les autres. Par exemple, la mémoire épisodique utilise la face interne des lobes temporaux et plus spécifiquement les réseaux neuronaux de l’hippocampe. La mémoire sémantique, quant à elle, utilise davantage de réseaux dans les parties intérieures des lobes temporaux. Enfin, la mémoire procédurale utilise des réseaux neuronaux sous-corticaux et le cervelet, qui joue un rôle très important dans le contrôle moteur. Selon Charles Scott Sherrington, « la mémoire se forme au sein de réseaux de neurones qui, après avoir été activés de manière intense ou répétée, gardent une trace de cette activation en renforçant leurs contacts ».

    Le fonctionnement de la mémoire à long terme dont fait partie la mémoire procédurale se fait en trois grandes étapes :

    1. L’encodage est la capacité à transformer l’information entrante et les stimuli. Il peut être intentionnel ou non. C’est l’apprentissage et l’entrée de l’information, la mise en mémoire de celle-ci, venant de nos différents sens, que ça soit la vue, l’ouïe, l’odorat, le toucher ou encore le goût. De la qualité de cette phase dépendra la qualité des phases suivantes, que ça soit dans la durée des souvenirs ou bien de leur fiabilité, leur exactitude. Plus l’attention portée à la phase de l’apprentissage est importante, plus celui-ci sera de qualité. Afin de faciliter l’encodage, on peut aussi utiliser des stratégies, par exemple sémantique (placer un mot dans une catégorie telle que l’animal, ou encore associer des attributs à un mot…). On appelle les informations transformées traces mnésiques.

    2. Le stockage ou conservation : lors de cette phase, les informations sont maintenues en mémoire et consolidées. Cette phase peut durer de quelques secondes à plusieurs années, elle peut aussi avoir lieu lors du sommeil, c’est pourquoi celui-ci est essentiel dans le processus de mémorisation. Le cerveau va répéter, sans que l’on s’en rende compte, les informations enregistrées lors de l’encodage et va ainsi les ancrer plus profondément dans la mémoire. Ces traces mnésiques vont, dans cette étape, passer de la mémoire à court terme à la mémoire à long terme.

    3. Rappel ou récupération ou restitution : lors de cette phase, les souvenirs et les informations sont récupérés, cette phase se fait de façon consciente ou inconsciente. L’information présente dans la mémoire à long terme revient dans la mémoire à court terme afin d’être accessible. Cette information peut alors être utilisée, on dit qu’elle est extraite de la mémoire. L’information est donc appliquée, c’est comme cela qu’on se rappelle comment faire du vélo, comment faire du piano… Cette phase de rappel permet de retourner une information déjà apprise et mémorisée. Cette récupération peut être consciente ou non.


    Apprentissage procédural

    La mémoire procédurale est une mémoire qui implique l’apprentissage d’un processus cognitif, permettant la réalisation inconsciente d’une procédure motrice. Ce processus n’est possible que par la répétition, qui va permettre une amélioration de la précision spatiale et temporelle et une diminution de l’attention nécessaire à sa résolution. La résolution de n’importe quelle activité donnée implique un apprentissage, qui repose sur la mémoire procédurale. Son but est d’économiser les ressources cognitives et de permettre la réalisation simultanée d’autres tâches.

    La mémoire procédurale est permise grâce aux propriétés malléables des circuits neuronaux dans différentes zones du cerveau. Pour les biologistes, la trace mnésique repose sur la neuro-plasticité qui permet des modifications à long terme des neurones au niveau de leur biochimie et de leurs aptitudes à faire des synapses. L'avènement de nouvelles techniques d’imagerie cérébrales, comme l’IRM fonctionnelle, permet d’examiner sur une longue période les corrélats neurobiologiques et l’apprentissage. L’étude de l’apprentissage de mouvements des doigts suggère que l’acquisition et l'utilisation d’une nouvelle tâche motrice se fait par une réorganisation significative de certaines zones (par exemple des lobes temporaux) se produisant en plusieurs étapes.

    La mémoire procédurale est caractérisée par une grande résistance aux pathologies, c’est pourquoi son acquisition est de la plus grande importance, mais celle-ci est relativement longue (de quelques semaines à plusieurs mois voir plus). D’après l’étude et les résultats de Francis Eustache et Hélène Beaunieux, on démontre bien 3 phases essentielles dans l’acquisition de la mémoire procédurale. Pour la première fois, ils démontrent aussi l’implication de la mémoire sémantique et des fonctions exécutives lors de la 1ère phase d’apprentissage. D’après le modèle ACT-R (Adaptive Control of Thoughts) de John Robert Anderson (1999), les trois phases d’apprentissages sont les suivantes : cognitive, associative et autonomie.

    La pratique peut déclencher des processus neuronaux évoluant plusieurs heures après la phase d’attention. Chaque expérience, même courte, peut entraîner des effets à long terme.

    L’apprentissage procédural se déroule de la manière suivante :

    1. phase précoce d'amélioration rapide, avec une forte progression dans l’apprentissage (établissement d’un plan optimal d'exécution), qui demande de nombreuses ressources et s’appuie sur la mémoire déclarative ;

    2. phase tardive lente, de nouvelles acquisitions se mettent en place, l’apprentissage devient plus long, démarrage de la procéduralisation ;

    3. phase de consolidation (permise si aucune activité n’est réalisée), lors du sommeil par exemple ;
      L'automatisation de l’activité s’organise, et permet d’utiliser de faibles ressources attentionnelles ;

    4. étape de maintien, où l'habileté peut être exécutée après une longue période de non utilisation ;
      en cas de non répétitions sur une très longue durée, oubli progressif de l’apprentissage.

    Apprendre / Comprendre

    On apprend une recette avec l’objectif de la reproduire mais comprendre une recette, c’est bien davantage, c’est se donner les moyens de la réinventer, c’est réfléchir par soi-même, c’est ne rien faire sans comprendre pourquoi on doit le faire.

    Apprendre, c’est hériter d’une maison, c’est stocker des connaissances.

    Comprendre, c’est construire sa maison, c’est façonner du lien, du sens, c’est s’approprier des savoirs.

    Pour mentaliser LCP, il faut avoir exploré la démarche dans tous ses recoins, il faut avoir compris le cheminement algorithmique dans chaque situation : contrôle, mise-à-jour, édition, interactif. Il faut savoir corréler la démarche avec le langage pratiqué. Cela demande du temps et la volonté d’ancrer la logique hiérarchique par traitements au plus profond de soi. L’effort mental est intense et continu, jusqu’à ce que l’organigramme s’impose de lui-même, devienne évident et naturel, ne soit plus nécessaire sur le papier.
    APPRENDRE
    COMPRENDRE
    • Stocker des connaissances
    • Fait appel à la mémoire
    • De l’ordre de la technique
      (du comment)
      Mécanique Logique
    • Pas de qualificatif dérivé
    • Gain de temps
    • Transfert parfois aléatoire
    • Plus facile à enseigner
    • Créer des liens entre des informations
    • Fait appel à l’intelligence
    • De l’ordre de la démarche ;
      du pourquoi au pour quoi
      (une suite d’étapes ordonnées)
    • Deux qualificatifs : (in) compréhensible
    • La démarche se construit et prend du temps
    • Transfert facilité dans le réseau conceptuel
    • Difficile d’aider à comprendre

  15. #15
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par IFA2377 Voir le message
    Bon, moi, je ne l’ai connu qu’en 2008, il avait déjà quatre ans. Il s’est assoupi 5 ans de 2008 à 2013 puis s’est à nouveau endormi pendant 7 ans. Il faut une bonne raison pour le réveiller.
    ...
    Merci pour le déterrage, j'ai 3 questions :

    1. en quoi la programmation informatique mettrait-elle en jeu les mêmes processus mentaux que le calcul mental et la mémorisation ?

    2. as-tu des exemples concrets (en conditions réelles) de projets informatiques qui valideraient tes théories ?

    3. penses-tu que l'article "Les astuces en calcul mental pour mieux calculer" (Superprof Magazine) est une source de confiance étant donné que parmi les quelques commentaires qui le suivent, 3 indiquent des erreurs dans les calculs présentés ?

  16. #16
    Expert confirmé
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 532
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 532
    Par défaut
    Citation Envoyé par IFA2377 Voir le message
    Apprendre, c’est hériter d’une maison, c’est stocker des connaissances.
    Comprendre, c’est construire sa maison, c’est façonner du lien, du sens, c’est s’approprier des savoirs.
    je rajouterais un 3ième point : " satisfaire aux injonctions du développement personnel c'est devenir un crétin fini" ..
    ne m'en voulez pas mais tout ce que vous nous avez écrit ça ressemble à de la Programmation Neuro Linguistique bref un truc qui prend bien les gens pour les idiots

  17. #17
    Membre chevronné
    Avatar de hachesse
    Inscrit en
    Mars 2002
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 189
    Par défaut
    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

  18. #18
    Nouveau membre du Club
    Inscrit en
    Décembre 2003
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 7
    Par défaut
    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à.

    @ +

  19. #19
    LFE
    LFE est déconnecté
    Membre Expert

    Profil pro
    Inscrit en
    Juillet 2002
    Messages
    95
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juillet 2002
    Messages : 95
    Par défaut
    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.

  20. #20
    Membre chevronné
    Avatar de hachesse
    Inscrit en
    Mars 2002
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : Mars 2002
    Messages : 189
    Par défaut
    Citation Envoyé par Doloop
    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

    Citation Envoyé par Doloop
    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

    Citation Envoyé par Doloop
    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

    Citation Envoyé par Doloop
    La méthode est mauvaise ?
    Assurement, OUI

    Citation Envoyé par Doloop
    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.


    Citation Envoyé par Doloop
    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.


    Citation Envoyé par Doloop
    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é

    Citation Envoyé par Doloop
    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)

    Citation Envoyé par Doloop
    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

    Citation Envoyé par Doloop
    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

Discussions similaires

  1. Logiciel qui permet de programmer en Fortran ?
    Par lesvacances dans le forum Fortran
    Réponses: 2
    Dernier message: 05/11/2007, 21h53
  2. Tutorial bonne pratique du programmation avec JAVA
    Par menzlitsh dans le forum Langage
    Réponses: 10
    Dernier message: 02/07/2007, 11h56
  3. Script Shell qui lance un programme sur un ordi distant avec SSH
    Par bilibou dans le forum Shell et commandes GNU
    Réponses: 5
    Dernier message: 02/06/2007, 11h18
  4. Erreur qui bloque mon programme
    Par bugland dans le forum Langage
    Réponses: 6
    Dernier message: 21/12/2006, 22h32
  5. Réponses: 19
    Dernier message: 26/12/2005, 01h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo