IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Au Pied Levé - À Main Levée

[Sondage] Quelle est la meilleure méthode pour apprendre la programmation ?

Noter ce billet
par , 01/04/2022 à 08h45 (1089 Affichages)

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

[Sondage] Quelle est la meilleure méthode pour apprendre la programmation ?

■ ■ ■ SOMMAIRE DE LA SYNTHÈSE ■ ■ ■
AVANT-PROPOS

  1. Résultats du sondage
  2. Résultats des avis
  3. Synthèse et analyse des avis
    1. Langage (12 avis)
    2. Motivation (8 avis)
    3. Algorithmique (3 avis)
    4. Méthodologie (2 avis)
    5. Logique (2 avis)
    6. Expérience (2 avis)
  4. Conclusion

■ AVANT-PROPOS

La discussion ayant dérapé en querelle d’égos à propos de langages alors que précisément, le sujet ne concernait pas l’apprentissage d’un langage mais la méthode et la logique, ma synthèse occulte ces échanges hors sujet.

Pour donner une idée de ces débats, quelques chiffres suffisent : le langage C a été cité une centaine de fois, le langage C++ 51 fois et le langage Python 19 fois. Mais le typage bat tous les records avec 235 fois. La méthode et la logique qui étaient le vrai sujet de la discussion, n’ont été citées que 8 fois chacune et l’algorithmique 13 fois.

NB : Quelques messages ont été rendus plus lisibles (reformulés, fautes corrigées, mieux présentés).


§ 1. Résultats du sondage

Citation Envoyé par LittleWhite Voir le message
Quelle est la meilleure méthode pour apprendre la programmation ? Ici, on parle bien de la programmation, (autrement dit, de la logique) et non de l'apprentissage d'un langage en particulier.
Nom : Sondage.jpg
Affichages : 120
Taille : 72,8 Ko


§ 2. Résultats des avis

Citation Envoyé par LittleWhite Voir le message
Quel est votre point de vue sur la question ?
La discussion a recueilli différents avis classés en 6 catégories triées en ordre décroissant :

Conseils
29 Avis
Langage
12
Motivation
8
Algorithmique
3
Méthodologie
2
Logique
2
Expérience
2

§ 3. Synthèse et analyse des avis

Les types de conseils sont abordés dans l'ordre du nombre d’avis émis. Mes analyses n’engagent que moi en tant qu'informaticien de gestion "périmé". Je regrette par exemple que l’ordre des catégories ne soit pas inversé, c’est-à-dire que la logique ait recueilli le maximum d’avis, puis la méthodologie, l’algorithmique, la motivation et enfin le langage. Je regrette également que les prédispositions ou la vocation n’ait pas été évoquées.

Bien que la discussion ne concerne pas l’apprentissage d’un langage, les avis révèlent que les préoccupations techniques des développeurs sont plus importantes que leurs préoccupations conceptuelles.

§ 3.1. Langage

■ ANALYSE

Le classement du langage en tête des avis révèle bien que la préoccupation principale des développeurs est avant tout la programmation et non l’analyse, la réalisation et non la conception, les hard skills et non les soft skills.

En réalité, coder n’est pas le gros du boulot. Coder n’est que traduire en langage compréhensible et compilable un ou plusieurs algorithmes. L'intérêt du développement et le gros du boulot c’est de concevoir ces algorithmes.

Coder pour coder n'a aucun intérêt sinon satisfaire son ego. Si c’est le cas, ce n'est pas de la passion, c'est de l'addiction, une dépendance assimilable à celle du jeu. Le codage est presque un pensum. D'autant que cela revient souvent à du simple copier-coller.

La formation à un langage est de l’ordre de la semaine. Le codage se résume pratiquement à la maitrise de quelques instructions. Il n'y a pas de quoi déchainer des passions :

  • Lecture
  • Écriture
  • Condition
  • Affectation
  • Tant que condition Faire

Air-dex dit très justement qu’il suffit de se concentrer sur les spécificités liées à un langage et sur son paradigme, sans rappeler cependant que l’algorithmique, le solfège du développeur, prime sur le langage.

Un paradigme est une manière de programmer un ordinateur basé sur un ensemble de principes ou une théorie. Il existe différents paradigmes de programmation basés sur des principes ou des théories variés, comme la programmation impérative, la programmation orientée objet, la programmation fonctionnelle, ou la programmation orientée processus. Le choix d'un paradigme de programmation est un des critères principaux pour le choix d'un langage.

Paradigme de programmation (Wikipédia)
Paradigme de programmation (Techno-Sciences.net)
Paradigme de programmation (Philippe Boulanger)

La création au niveau du seul langage, c'est l'élaboration de son environnement de développement, le souci de la lisibilité de son code source par l'adoption de règles d'écriture.

La technicité s’acquiert quand on en a besoin et cela suppose de savoir s’adapter. Miser sur une technicité, c’est devenir une espèce endémique menacée de disparaitre au moindre changement environnemental. Et n’est-ce pas se confiner dans un rôle de simple Ouvrier Spécialisé ? Mais c’est rassurant, la technique a toujours une réponse rationnelle et cela évite de se confronter à ses semblables.
■ SYNTHÈSE

Citation Envoyé par walfrat Voir le message
Avant même de faire une full solution Angular + Java/Spring/Hibernate, taper du code de base pour un petit truc perso permet de se rôder aux opérations les plus simples du code et permet d'acquérir des réflexes essentiels que ce soit dans le réflexion ou l'écriture de code.
Citation Envoyé par MajorKurk Voir le message
J'avais essayé les langages de bas niveau (C++), et j'ai abandonné le développement. J'ai ensuite essayé Java, même constat. Finalement, c'est dans les langages web et python que j'ai trouvé ma rédemption.
Citation Envoyé par Madmac Voir le message
Un bon tutoriel peut être la bonne approche, mais dans mon cas, je préfère la pratique, avec un langage comme Pascal qui contrairement à Python ne demande pas une expertise préalable pour faire fonctionner l'exemple. Et pour cette raison, je suis toujours étonné de le voir dans les langages suggérés aux débutants.
Citation Envoyé par smarties Voir le message
  1. Commencer par choisir le langage de programmation
  2. Choisir un Framework populaire du langage (si applicable)
Citation Envoyé par nhugodot Voir le message
Je comprends qu'on puisse aimer le C, voire l'assembleur pour bidouiller l'ordinateur avec ses registres mémoires, maîtriser la bête depuis ses entrailles, puis monter petit à petit avec C++, Java, JS.

J'ai repris la programmation avec Visual Basic/VBA : Manipuler des tableaux Excel par exemple est fort gratifiant, puissant, efficace, utile directement au travail de tous les jours. Démarrer même l'apprentissage avec juste des macros Excel qui, rappelons-le, est de très, très loin l'outil ''de développement'' le plus utilisé au monde pour faire n'importe quoi, d'un agenda à une base de données clients ou projets. On voit d'abord le résultat, on entre ensuite dans la manipulation.

Python, Smalltalk, Pharo, Ruby, LiveCode surtout (un HyperCard en live coding comme Smalltalk, inventé par Alan Kay pour enseigner justement la programmation aux enfants, Scratch etc.) sont des outils beaucoup plus clairs intuitifs, faciles, intégrés, et cohérents donc moins rébarbatifs que C, Vi/emacs, Unix, etc. ! Si on ne veut pas écœurer un débutant dès le début...
Citation Envoyé par Fagus Voir le message
Ne pas commencer par C++, c'est un langage délicat d'expert très complexe avec des générations de sédimentation technologique.

- Commencer par un langage d'abord facile et un peu d'algo, avec un environnement de développement simple à faire marcher, et des bibliothèques graphiques natives simples et très bien documentées. Je conseille python (avec idle ou thonny au début, et tkinter) et le livre de Swinnen https://python.developpez.com/cours/apprendre-python3/. Puis de maîtriser le langage en suivant des cours plus avancés tout en se faisant des projets. Les cours de l'Inria en python sur fun mooc sont biens.

- Plus tard, apprendre le C et savoir vaguement comment marche un PC, juste pour savoir écrire du code plus sensé pour la machine, et parce que c'est un peu le langage historique incontournable.
Citation Envoyé par Matthieu Vergne Voir le message
Dans le cas de la programmation, la pratique se fait difficilement sans langage. Apprendre la programmation nécessite donc au minimum de pratiquer sur un langage donné (on n'exécute pas grand-chose avec du pseudo code).
Citation Envoyé par smarties Voir le message
Commencer par choisir le langage de programmation.
Citation Envoyé par air-dex Voir le message
L'une des choses les plus importantes est de savoir différencier les concepts et leurs implémentations. Un langage c'est d'abord l'implémentation de ces concepts-là. Des concepts fondamentaux tels que la boucle IF ne sont pas totalement réinventés à chaque fois que tu passes d'un langage à un autre. Si tu sais faire la différence tu seras déjà dans tes petits souliers à chaque fois que tu découvres un nouveau langage. Tu n'as alors plus qu'à te concentrer sur les spécificités liées à ce langage et sur son paradigme s'il t'est étranger. C'est pareil dans les langues vivantes. Que tu dises "wagen" en allemand, "car" en anglais, "voiture" en français ou "coche" en espagnol, ça reste de même tas de ferailles avec 4 roues et un volant. C'est pareil pour les langages de programmation.

Niveau langages, j'ai envie de conseiller le C et Python. Pour de l'objet, je conseille fortement le C++. Éviter dans un premier temps les Framework.

Quant à la méthode ça dépend de chacun, de sa manière de fonctionner. Rien ne vaut un bon bouquin et des tutos écrits.

La programmation requiert davantage de logique que de mathématique. Les maths requises dans le développement ne sont pas très élaborées, ni nombreuses :

  • Les cinq opérations de base : +, -, *, / et %.

  • Les comparaisons : <, >, == et !=, ainsi que <= et >= par extension.

    Un besoin de davantage de maths révèle très probablement des savoir-faire mathématiques qui n'ont pas de liens directs avec la programmation en elle-même.
Citation Envoyé par Jacti Voir le message
"Le Langage C est très (trop) tolérant en ce qui concerne les mélanges de types dans une expression. C'est au programmeur de vérifier que les conversions implicites réalisées par le compilateur ont le sens désiré... Cet allègre mélange des types est un des plus gros pièges pour le débutant, à qui un langage fortement typé convient mieux. En l’absence de cadre rigoureux, il est facile de réaliser sans s’en douter des opérations hasardeuses… et fausses."

Référence : Les conversions de type : implicites et explicites (cast)

http://<u>https://public.iutenligne...._cast.html</u>).

L'assembleur est à bannir sauf dans des cas bien particuliers.
Citation Envoyé par Matthieu Vergne Voir le message
Avec un sujet aussi sensible que "la meilleure méthode de programmation", on aura finalement eu une polémique sur le typage des langages.
§ 3.2. Motivation

■ ANALYSE

Devenir développeur est un choix qui suppose à priori la motivation de l’étudiant. Proposer des sujets intéressants proches de la réalité relève d’un savoir-faire pédagogique et ne devrait pas être un sujet. Professionnellement par contre, il ne doit pas être évident d’être confronté à des sujets sans intérêt.

Les problématiques de gestion sont toutes très spécifiques. Il n’est pas évident d’abstraire de leurs développements des tutoriels d’algorithmique originaux, attractifs, représentatifs de la réalité du développement. Parmi plus de 2.000 programmes développés, à peine trois programmes m’ont permis de créer des tutoriels d’algorithmique répondant à ces critères. Le hasard des discussions m’en a inspiré deux autres, soit cinq en tout à ce jour (avril 2023).
■ SYNTHÈSE

Citation Envoyé par Uther Voir le message
La clé est de cerner les exercices qui feront le plus envie à l'étudiant pour le motiver, après c'est gagné, l'outil est vraiment annexe.
Citation Envoyé par Zefling Voir le message
Avec des projets intéressants. C'est toujours ce qui m'a poussé à apprendre, l'envie de réaliser quelque chose.
Citation Envoyé par MajorKurk Voir le message
Pour le web, j'avais un projet concret en PHP / JavaScript. Ça a dû aider. Un projet concret permet de ne pas se perdre dans l'apprentissage, d'avoir une ligne directrice, un chemin à suivre et des cas concrets sous les yeux.
Citation Envoyé par Matthieu Vergne Voir le message
Apprendre est une chose, encore faut-il être motivé et en avoir l'intérêt (apprendre pour ne pas appliquer diminue grandement l'intérêt).

Pour résumer :

  • trouver du fond théorique et pratique
  • trouver une forme adaptée à la personne
Citation Envoyé par smarties Voir le message
Se développer un projet assez simple et intéressant (logiciel de gestion de quelque chose, bibliothèque…).
Citation Envoyé par der§en Voir le message
Se donner un objectif à atteindre ! Cela oblige à creuser des fonctions/méthodes qui permettent de sortir de sa zone de confort…
Citation Envoyé par air-dex Voir le message
Un projet personnel (ou pas) peut être une bonne source de motivation à ne pas négliger. C'est l'idéal pour tester son apprentissage, maitriser un langage et devenir autonome.
Citation Envoyé par nhugodot Voir le message
La première des choses est de stimuler la motivation de l'élève dans sa personnalité, ce qu'il aime et déteste, comment il appréhende le monde et sa manipulation mentale.
§ 3.3. Algorithmique

ANALYSE

Apprendre l’algorithmique, c’est apprendre à structurer logiquement un programme en devenir. Mais ce n’est pas la même chose d’avoir à coder un programme qui traduit un sujet en moins d’une centaine de lignes et un programme qui traduit une problématique en deux, trois mille lignes, voire davantage.

La démarche intellectuelle est différente et distinguer ces deux approches revient à distinguer deux types de logiques, la logique combinatoire et la logique conceptuelle.

  • Dans le premier cas, c’est le pseudo langage ou le langage qui constitue l’objet de la réflexion du programmeur.
    L’algorithmique fait appel à la logique combinatoire. L’algorigramme est le terme approprié pour définir sa représentation visuelle.

  • Dans le second cas, c’est la problématique qui constitue l’objet de la réflexion du développeur.
    L’algorithmique fait appel à la logique conceptuelle. Le logigramme est un terme plus approprié pour définir sa représentation visuelle.

  1. Algorithmique et logique combinatoire

    Le cours d'initiation à l'algorithmique Introduction aux algorigrammes est censé apprendre le concept d'algorigramme, outil visuel pour décrire un algorithme. Ce cours se réfère à la norme ISO 5807 qui officialise ni plus, ni moins, la méthode sauvage des années 60 où l’algorigramme ne décrit pas la problématique mais décrit la solution.

    On retrouve cette symbolique algorithmique dans ce normographe des années 60-70 avec d’autres symboles de l’époque comme la carte perforée et la bande magnétique.

    Nom : Normographe ou Organigraphe (40%).jpg
Affichages : 95
Taille : 78,7 Ko


    … focalisent la réflexion algorithmique sur le pseudo codage ou le codage de sujets théoriques à base de chiffres, de nombres ou de caractères. La nature de ces sujets ne nécessite aucune réflexion personnelle vis-à-vis des sujets eux-mêmes. Ce sont des sujets mais en aucun cas des problématiques. Dans le monde réel du développement, un algorithme est censé rester au niveau logique des traitements et non décomposer la réflexion au niveau de l’instruction. En traduisant leurs sujets en pseudo langage, ces exercices apprennent à coder et assimilent insidieusement l’algorithme à un programme.

  2. Algorithmique et logique conceptuelle

    La logique conceptuelle se focalise sur la problématique dans sa globalité.

    Généralement, les programmes sont constitués de deux parties, une partie Données et une partie Procédurale. La partie Données (DATA DIVISION COBOL, CLAUSE DEFINE SGBD...) qui rassemble les données que doit traiter la partie Procédurale fait appel à une logique dite séquentielle.

    La logique conceptuelle concerne la partie Procédurale ; elle analyse la problématique dans sa globalité et reste au niveau logique des traitements. Le codage n’est pas le sujet, la décomposition de la réflexion au niveau de l’instruction reste mentale.

    Quand on pratique LCP (Logique de Construction des Programmes), il n'y a pas vraiment de création car c’est la réflexion et l'analyse par traitements qui construisent l’algorithme.

    De même qu’un plan diffère d’une dissertation classique à une dissertation juridique, les règles et techniques algorithmiques diffèrent selon la méthodologie de programmation adoptée.
■ SYNTHÈSE

Citation Envoyé par grunk Voir le message
Si on veut en faire un métier et durer dans le temps :

  • La première des choses est d’acquérir une culture informatique, savoir comment marche un ordinateur.
  • Travailler un minimum la logique et l'algorithmique. Des outils à base de blocs sont plutôt pas mal pour ceux qui n'ont pas la formation mathématique qui apporte normalement cette réflexion.
Citation Envoyé par air-dex Voir le message
L'algorithmique d'abord, les langages ensuite : ne jamais négliger l'algorithmique, qui est le solfège du développeur.
Citation Envoyé par ext1812 Voir le message
Apprendre les principes et ce qui est derrière ! Peu importe le langage, il faut toujours apprendre les concepts. Il faut toujours se poser la question pourquoi et comment.

Creuser toujours plus ce que vous utilisez et comme on dit "How doest it wotk under the hood" ?
§ 3.4. Méthodologie

■ ANALYSE

Si l’on excepte la norme ISO 5807 qui n'est pas une méthode, les trois principales méthodologies de programmation sont apparues au début des années 1970 :

  1. Norme ISO 5807 (méthode sauvage des années 60)
  2. CORIG - COnception et Réalisation de l’Informatique de Gestion
  3. LCP - Logique de Construction de Programme
  4. PS - Programmation Structurée (Arbre programmatique)

La révolution software a pourtant bien eu lieu fin des années 60, début des années 70, avec les méthodologies LCP et CORIG, mais nous ne sommes plus que deux ou trois à en pérenniser le souvenir.

■ SYNTHÈSE

Citation Envoyé par air-dex Voir le message
Quant à la méthode ça dépend de chacun, de sa manière de fonctionner. Perso je suis très rat de bibliothèque sur ce point et rien ne vaudra mieux pour MOI que le nez dans un bon bouquin et des tutos écrits.
Citation Envoyé par nhugodot Voir le message
Alan Kay dit dans ses conférences TedX qu'on attend toujours la révolution software qu'on a eu en hardware. Plus de 40 ans après son Smalltalk, on code toujours plus mal qu'avant, de quoi en écœurer plus d'un, moi le premier... Quel gâchis.
§ 3.5. Logique

■ ANALYSE

La logique structure le raisonnement censé satisfaire un besoin, encore faut-il comprendre et savoir traduire ce besoin…

  • Décoder le besoin de l'utilisateur qui ne sait pas qu'il sait et lui réaliser devant lui son outil informatique qu'il crée lui-même sans le savoir, ça oui, c'est palpitant, et on ne s'en lasse pas…

  • Intégrer des paramètres comme l’ergonomie et la convivialité, tenir compte du fait que la plupart des gens zappent et ne lisent pas. Il n’y a pas de recettes pour créer un écran, un état, cela ne s'enseigne pas. C'est également un cheminement personnel ou la spécialité aujourd’hui d’un webdesigner.

  • S'intéresser aux gestionnaires plutôt qu'à leur hiérarchie, qui connait certes les règles de gestion mais ignore la façon dont elles sont appliquées. Quel responsable est capable de remplacer l'un(e) de ses gestionnaires derrière son écran ?

Finalement, la logique qui devrait être la qualité essentielle de l’informaticien, est à peine évoquée. Sans doute parce qu’elle ne s’enseigne pas. Chacun possède son raisonnement propre et possède donc sa propre logique. La logique n’a pas de norme, mais elle peut être évaluée par des tests psychotechniques. Plus qu’une qualité, ce serait un don consubstantiel de l’informatique.

On ne peut pas percevoir la programmation uniquement comme l’expertise d’un langage et la mise en œuvre d’un astucieux savoir. La programmation n’est pas un but en soi mais la phase finale et concrète d’une démarche conceptuelle.

"Analyste" et "Programmeur" ne sont plus des qualifications cloisonnées comme autrefois. La conception utilise les mêmes mécanismes intellectuels que la programmation, à un niveau d’abstraction plus élevé. Aujourd’hui, le "développeur" intègre la conception détaillée de l’analyste et la réalisation du programmeur.

La programmation, exige toujours logique, méthodologie, algorithmique, et technicité, mais pas seulement. Elle est impactée par la démarche conceptuelle qui elle, s’alimente d’autonomie, de liberté, de réflexion, de raisonnement, de créativité, de curiosité, d’audace, d’aventure, d’expérimentation, de défi, d’initiative, de prise de risque, d’adrénaline, de responsabilité, de professionnalisme, de nouveauté, d’incertitude, de surprise, de coïncidence, d’opportunité, de passion, de plaisir, de communication, de philosophie, de psychologie, d’empathie...

Ces aptitudes humaines, ces qualités relationnelles, ces savoirs comportementaux… donnent l’agilité nécessaire pour s’adapter et rester performant dans un environnement changeant.

Ce sont des compétences qui créent de la valeur, dans un monde où la valeur ajoutée se situe dans la gestion des interfaces, dans la résolution de situations complexes, dans la conduite du changement, etc.

Ces compétences ou aptitudes, non liées à un contexte technique particulier se nomment des soft skills, par opposition aux compétences purement techniques que l’on nomme des hard skills.
■ SYNTHÈSE

Citation Envoyé par Jacti Voir le message
Dans le développement, ce n’est pas la partie programmation la plus importante mais la partie conception globale et détaillée et là, on ne trouve pas grand monde de compétent… hélas.
Citation Envoyé par Matthieu Vergne Voir le message
Si l’on parle d'apprendre la logique, il y a 2 aspects à prendre en compte :

  • la théorie, pour comprendre les intentions et le fonctionnement,
  • la pratique, pour illustrer et confirmer ce que dit la théorie.

Les tutos se focalisent en général sur la partie pratique, donc plutôt orienté sur un langage, mais il est possible d'en avoir qui donnent une partie théorique. Ce sont ces derniers qu'il faut privilégier.

Pour résumer :

  • trouver du fond théorique et pratique
  • trouver une forme adaptée à la personne
§ 3.6. Expérience

■ ANALYSE

45 votants, 21 intervenants et seulement deux expériences d’apprentissage de la programmation par des autodidactes. En fait, leur témoignage relève davantage de leur apprentissage des langages que de celui de la programmation proprement dite. Globalement, on peut dire que « Programmation » = « Codage ».

L’apprentissage de la programmation en école (38 %) ou en formation (31 %) ne laisse guère de souvenirs impérissables. Curieusement, l’apprentissage par un formateur (38 % + 31 %) totalise autant de votes qu’avec des tutoriels écrits (69%).

Ces deux témoignages d’apprentissage n’évoquent ni méthodologie, ni acquisition d’un savoir-faire, ni logique, ni réflexion personnelle, conceptuelle, analytique.
Leur discours est essentiellement orienté langage : C, C++, PHP, GUI, MFC, langage de script, Basic, API Windows, multithread, Python, POO.

Il semble que l’apprentissage de la programmation soit un processus difficile à exprimer du point de vue de la logique ou des soft skills, la partie immergée de l’iceberg « développement ».

Personnellement, ma période d’apprentissage s’est étalée de mi-1966, j’avais 18 ans, à mi-1971. Au cours de ces cinq années, j’aurais été successivement « Préparateur de commandes », « Coursier », « Militaire », « Chômeur », à nouveau « Coursier », « Opérateur-Pupitreur » et enfin « programmeur ».

Ce que je retiens de mon apprentissage de la programmation tient en trois mots : prédispositions, détermination, autoformation...

■ SYNTHÈSE

Citation Envoyé par walfrat Voir le message
Personnellement, j'avais bidouillé gentiment PHP en autodidacte et même fais un peu de C, je m'étais arrêté au pointeur.

Mon niveau de programmation ne volait pas donc haut. Il m'a pourtant été d'une grande aide une fois en BTS info & réseau puis INSA.

Pourquoi ? Je m'étais déjà suffisamment payé de boucles, de petits tests de logique, d'erreurs du débutant, que quand j'ai commencé l'info en BTS j'étais "fluent" en écriture de code. Tout ce que j'avais fait c'était un site web pour une guile dans un jeu où l'on pouvait s'authentifier et saisir un formulaire pour remplir des tableaux.
Citation Envoyé par Fagus Voir le message
J'ai appris tout seul, et on m'avait conseillé le C++ à l'époque où c'était un mélange de C++ et de C et où il n'y avait pas vraiment de cours gratuits en ligne, et où les RAD étaient tous payants. J'ai commencé par un petit livre poche de 350 pages, mais avec ça je ne pouvais rien faire en dehors d'un programme en console basique et très décevant, et les codes en ligne à cause du C mélangé n'étaient pas clairs.

J'ai avalé un livre énorme (1-2kg) de C/C++, d’algorithmie, de notions de machine bas niveau. Gros coup de cœur avec le C. J'ai beaucoup appris, mais à la fin, pour faire des GUI, il m'envoyait vers les MFC à la main ou des outils payants. C'était vraiment une expérience punitive et programmer en C n'est pas très productif pour un débutant à réinventer l'eau tiède et à boucher les fuites de mémoire.

Ce sont les langages de script à la basic qui m'ont sauvé. J'en ai appris un en un week-end avec cette base et avec un environnement intégré et un accès pré-mâché aux API windows tout était si simple et la productivité énorme, mais ça devenait galère sans programmation objet ni multi-thread bien fichu pour quelque chose de plus qu'un script.

Python m'a sauvé une 3e fois avec sa polyvalence et haute productivité avec la documentation et les lib énormes, d'autant plus que j'ai pu beaucoup bénéficier du C/C++ conceptuellement (typage optionnel du python, POO, culture etc.)
§ 5. Conclusion

Développeur = Analyste + Programmeur

Les développeurs pensent avant tout en programmeur. C’est le langage qu’ils pratiquent qui impacte leur réflexion. Ils adaptent la problématique à leur technicité alors que ce devrait être l’inverse. Il suffit de suivre les discussions sur les forums pour le constater.

Citation Envoyé par Mat.M Voir le message
Mais non le problème n'a pas été résolu vous êtes en train de perdre votre temps à faire des tableaux totalement inutiles "à la main".

Faire du code, ça prend autant de temps que de faire ce genre de tableaux.

Donc, ce que je conseille de faire, c'est de faire du code, j'en ai fait une ébauche quitte à le rectifier et à l'améliorer pour obtenir les bons résultats.

Ensuite, si vous voulez obtenir des tableaux de sortie des traitements de données afin de vérifier l'intégrité de l'ensemble des données, c'est précisément l'intérêt de faire du code fonctionnel.

Sans code, ne serait-ce que du pseudocode ou bien sans organigramme minimum, on ne peut pas voir ce qui pose problème.

Faites-nous du code en JavaScript ou en Java que tout le monde comprenne sur ce forum et on verra les problèmes de logique.
Sur le Forum Algorithmes et structures de données, les deux discussions qui m’ont inspiré chacune un tutoriel, sont très révélatrices. Les développeurs ne lisent pas l’énoncé, ils l’interprètent et dégainent du code sans analyser la problématique. C’est tellement vrai que les deux discussions que j’évoque ont été résolues uniquement de façon algorithmique, sans avoir besoin de coder.

Logique vs Codage

  • La logique traduit une problématique en algorithme.

    Autrement dit : l’algorithme décode la problématique.

  • Le codage traduit l’algorithme dans un pseudo codage ou un langage de programmation,

    Autrement dit : le programme code l’algorithme.

Tutoriels de développement

Ces tutoriels sont des tutoriels complets d’analyse-programmation pour lesquels l’objet de la réflexion concerne la problématique et non le codage ou le pseudo codage comme c’est souvent le cas concernant les exercices d’algorithmique.

On enseigne les méthodes d’analyse, l’algorithmique, les langages mais on n’enseigne pas la réflexion. Il appartient à chacun d’instruire et d’enrichir sa propre réflexion. Développer, ne se limite pas à appliquer des recettes rassurantes. Développer, c’est réfléchir par soi-même en utilisant ce que l’on a appris.

Chacun de ces tutoriels commence soit par une anecdote exposant la problématique étudiée, soit par le message du prime posteur sur un forum d’entre-aide. Mis en situation, il convient de s’approprier la problématique et de concevoir sa propre solution avant de s’intéresser au corrigé proposé.

D’autres membres DVP proposent ce genre de tutoriels de développement :

Shell, EDI

Étonnamment, aucun intervenant n’a évoqué le shell pas plus que l’outil indispensable du développeur, l’éditeur, et pas davantage l’EDI d’un SGBD. Programmer, c’est écrire un programme, donc utiliser un éditeur ; c’est exécuter un programme, donc utiliser le shell du serveur. Un shell comme Unix est bien plus complexe qu’un langage. Un shell d’exécution peut compter plusieurs centaines de lignes et fait appel à la même logique que pour un programme. Développer dans le cadre d’un SGBD, suppose d’autres connaissances que celle d’un langage comme l’Environnement de Développement Intégré (EDI).

Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Viadeo Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Twitter Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Google Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Facebook Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Digg Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Delicious Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog MySpace Envoyer le billet « [Sondage] Quelle est la meilleure méthode pour apprendre la programmation ? » dans le blog Yahoo

Mis à jour 17/03/2024 à 09h53 par APL-AML

Catégories
■ FORUMS , I-2. Synthèses de discussions

Commentaires

  1. Avatar de APL-AML
    • |
    • permalink
    ■ Expérience d’apprentissage APL-AML

    ■ ■ ■ SOMMAIRE ■ ■ ■

    AVANT-PROPOS
    1. Prédispositions
    2. Détermination
    3. Autoformation
    4. Conclusion



    ■ AVANT-PROPOS

    Citation Envoyé par LittleWhite Voir le message
    Quelle est la meilleure méthode pour apprendre la programmation ? Ici, on parle bien de programmation (ou autrement dit, la logique) et non de l'apprentissage d'un langage en particulier.

    N'hésitez pas à partager votre expérience d'apprentissage, ou encore, de dire comment vous, vous auriez aimé apprendre la programmation.
    45 votants, 21 intervenants et seulement deux expériences d’apprentissage de la programmation par des autodidactes. En fait, leurs témoignages relèvent davantage de leur apprentissage des langages que de celui de la programmation proprement dite. Globalement, on peut dire que Programmation = Codage.

    Citation Envoyé par walfrat Voir le message
    Personnellement, j'avais bidouillé gentiment PHP en autodidacte et même fais un peu de C, je m'étais arrêté au pointeur.

    Mon niveau de programmation ne volait pas donc haut. Il m'a pourtant été d'une grande aide une fois en BTS info & réseau puis INSA.

    Pourquoi ? Je m'étais déjà suffisamment payé de boucles, de petits tests de logique, d'erreurs du débutant, que quand j'ai commencé l'info en BTS j'étais "fluent" en écriture de code. Tout ce que j'avais fait c'était un site web pour une guile dans un jeu où l'on pouvait s'authentifier et saisir un formulaire pour remplir des tableaux.
    Citation Envoyé par Fagus Voir le message
    J'ai appris tout seul, et on m'avait conseillé le C++ à l'époque où c'était un mélange de C++ et de C et où il n'y avait pas vraiment de cours gratuits en ligne, et où les RAD étaient tous payants. J'ai commencé par un petit livre poche de 350 pages, mais avec ça je ne pouvais rien faire en dehors d'un programme en console basique et très décevant, et les codes en ligne à cause du C mélangé n'étaient pas clairs.

    J'ai avalé un livre énorme (1-2kg) de C/C++, d’algorithmie, de notions de machine bas niveau. Gros coup de cœur avec le C. J'ai beaucoup appris, mais à la fin, pour faire des GUI, il m'envoyait vers les MFC à la main ou des outils payants. C'était vraiment une expérience punitive et programmer en C n'est pas très productif pour un débutant à réinventer l'eau tiède et à boucher les fuites de mémoire.

    Ce sont les langages de script à la basic qui m'ont sauvé. J'en ai appris un en un week-end avec cette base et avec un environnement intégré et un accès pré-mâché aux API windows tout était si simple et la productivité énorme, mais ça devenait galère sans programmation objet ni multithread bien fichu pour quelque chose de plus qu'un script.

    Python m'a sauvé une 3e fois avec sa polyvalence et haute productivité avec la documentation et les lib énormes, d'autant plus que j'ai pu beaucoup bénéficier du C/C++ conceptuellement (typage optionnel du python, POO, culture, etc.)
    Il n’y est question ni de méthodologie, ni d’acquisition d’un savoir-faire, ni de logique, de réflexion personnelle, conceptuelle, analytique.

    Le discours est essentiellement orienté hard skills : pointeur, boucles, code, guile, C, C++, PHP, GUI, MFC, langage de script, Basic, API Windows, programmation objet, multithread, Python, lib, typage, POO.

    Il semble que l’apprentissage de la programmation soit un processus difficile à exprimer du point de vue de la logique, des soft skills, la partie immergée de l’iceberg « développement ».



    § 1. Expérience d’apprentissage

    Ce que je retiens de mon apprentissage de la programmation tient en trois mots : prédispositions, détermination, autoformation.

    § 1.1. Prédispositions

    Prédisposition, vocation ou syndrome psychologique

    Citation Envoyé par Claude40 Voir le message
    La « vocation » : Il faut se lancer dans la programmation, non pas parce que c’est réputé être bien payé, mais parce que vous sentez que vous allez y prendre du plaisir.

    L’esprit « Sherlock Holmes » : Vous avez un certain goût et une certaine propension à résoudre les problèmes, à trouver les solutions, à détecter les anomalies et leurs causes. C’est une disposition d’esprit qui n’est pas donnée à tout le monde. Vous gagnerez du temps en mise au point de vos programmes.
    On peut posséder certaines dispositions pour l’art, la peinture, la musique, le chant… et l’informatique.

    Mon cerveau génétiquement câblé
    « logique, perfectionniste, créatif, empathique » était connu de toute la famille. Un soir, mon cousin passe me voir et m’annonce :

    - « Je sais ce que tu vas faire comme métier : programmeur »…

    C’était en 1966, j’avais 18 ans. Cette année-là, l'Académie française consacre officiellement l'usage du mot “ Informatique ” pour désigner la « science du traitement de l'information ».

    Oubliées mes trois années d’enseignement technique à dessiner des vues de dessus à l’encre de chine, à mémoriser la composition des alliages, les rondelles Grower. Oubliées les heures d’atelier à fraiser, tourner, forer et limer le petit poil au centre de mes objets d’art, tantôt une clavette, tantôt un trusquin.

    § 1.2. Détermination

    Après le collège, mon père m’a dit :

    « tu sais ce qu’il te reste à faire… »

    Étant l’ainé, j’ai supposé que je devais aller travailler. Et c’est comme ça que je me suis retrouvé O.S. en attendant le service militaire. Mon petit salaire presque entièrement donné à ma mère pour l’aider à faire vivre notre famille nombreuse, m’a quand même permis de suivre les cours par correspondance "Programmeur assembleur IBM 1401" dispensés par l’école privée EPSI.

    Dans le même temps, j'ai fait la connaissance accidentelle d’une analyste chez IBM. "Accidentelle" parce qu’elle a maladroitement cabossé ma super Chambord sagement garée devant chez moi. En dédommagement, elle m’a proposé de faire saisir puis compiler mes exercices de cours à son travail. C’était impressionnant le nombre d’erreurs que signalait le compilateur. Mes premiers programmes datent donc de mi-1966-début 1967. Tout allait bien mais au moment de passer l’examen final, la France a eu besoin de moi.

    L’EPSI proposait d’intervenir pour favoriser une affectation de ses élèves au service informatique de l’armée. Incorporé dans les parachutistes au 13ème RDP, il m’a été difficile psychologiquement de solliciter une intervention sans passer pour un dégonflé. In situ, il n’est pas facile de troquer son béret rouge pour un béret noir. Les deux derniers mois de mon service, nous étions quatre de la même classe à préparer les championnats de France de pentathlon militaire. Très privilégiés, nous logions dans un petit appartement d’un bâtiment du régiment très à l’écart. À l’écart de tout d’ailleurs, notamment de l’actualité. En dehors des entrainements, je révisais mes cours en vue de passer l’examen final dès mon retour à la vie civile. Pour une raison que nous ignorions, la date des championnats a été repoussée et il a été convenu que nous fassions deux mois de plus sous couvert d’une peine fictive de prison. Nous savions que le régiment était consigné mais nous ne savions pas pourquoi. Finalement, toute la classe 67 1B a été libérée en deux jours fin juin 68. Entre nous, nous discutions de ce que nous allions faire une fois rentrés chez nous. Lorsque je leur dévoilais mon projet d’être programmeur et leur expliquais en quoi cela consistait, cela les faisait bien rire et ils me rétorquaient que ce métier n’existait même pas.

    De retour à la vie civile, je me suis évidemment retrouvé au chômage. Comme prévu avec 16 mois de retard, j’ai passé mon examen de "Programmeur assembleur IBM 1401" mais entre-temps, l’IBM 360 avait remplacé l’IBM 1401. Au chômage, j’ai pu suivre très rapidement les cours "Programmeur assembleur IBM 360". Au lieu de poster mes devoirs et attendre de recevoir le cours suivant, j’allais faire l’échange "devoirs contre prochain cours", directement chez EPSI.

    Pédagogiquement, une formation par correspondance (cours écrits) n’est pas la même chose qu’une formation en présentiel (cours oraux). Les cours par correspondance obligent à s’impliquer davantage.

    Compte tenu du contexte, les propositions d’emploi en informatique étaient rares. On trouvait quelques annonces en mécanographie classique. Puis j’ai eu la chance d’être embauché au service informatique d’une administration… comme opérateur-pupitreur. Surpris d’être convoqué pour un entretien, j’avais sans doute envoyé un CV dont je ne me souvenais plus. Bien plus que mes deux diplômes EPSI inutiles, mes états de service militaire ont dû favoriser mon embauche car à l’époque, pour intégrer l’administration, il y avait une enquête préalable de bonne moralité. Je me souviens avoir repéré des gendarmes roder près de chez moi et interroger les voisins. Mais peut-être me suis-je fait des idées ?

    Lors de l’entretien pour ce poste d’opérateur-pupitreur, je n’ai surtout rien dit de mes activités sportives. La personne qui m’a embauché ne l’a appris que deux ans plus tard en lisant l’Équipe. Elle-même avait arrêté récemment sa carrière d'athlète et sans le savoir, nous étions du même club.

    À mes débuts comme pupitreur, je pensais bien faire en essayant de mémoriser le processus d’initialisation de l’ordinateur. Le chef d’exploitation qui m’initiait m’a arrêté tout de suite en me disant :

    - « Ne cherche pas à apprendre ce que tu dois faire mais comprends ce que tu fais. Certes pour démarrer il faut appuyer successivement sur Clear, Load, Run, mais mentalement tu dois comprendre qu’il faut d'abord initialiser la mémoire avant de charger le système puis l’exécuter. »

    Bertrand PICCARD dit :

    - « Apprendre à ne rien faire sans comprendre pourquoi on doit le faire. »

    Le chef d’exploitation était un ancien garde forestier reconverti dans l’informatique car trop mal payé. Il me disait qu’il ne servait à rien que les garde-forestiers fassent grève car ça n’empêchait pas les arbres de pousser.

    Je n’ai été intronisé « programmeur » que le 1er janvier 1971… Après deux ans à l’exploitation à travailler une semaine du matin, une semaine de l’après-midi et une semaine de nuit. La quatrième semaine était de repos mais la plupart du temps on remplaçait un collègue qui devait faire le matin ou la nuit. Du matin ou de nuit, nous assurions le week-end, soit deux fois 12 heures consécutives. Ces semaines faisaient 69 heures. Nous gagnions davantage que les programmeurs.

    Les DUT informatiques datent de 1971. Avant cette date, les programmeurs se recrutaient à la faveur d’une batterie de tests psychotechniques censés révéler leurs capacités de réflexion et de logique. Le niveau d’études n’était pas un critère. Mon BEPC de 1964, Brevet des Collèges d’aujourd’hui, n’a pas été un handicap.

    Dans le privé, les tests les plus courants étaient dits "Tests IBM". Je les ai passés plusieurs fois avec succès mais l’entretien final m’était fatal lorsque j’évoquais mes activités sportives de haut niveau.

    Apparemment ce genre de loisir leur paraissait incompatible avec la profession. Pourtant la pratique d’un sport participe au formatage de notre réflexion. Deux à trois heures d’entrainement par jour, c’est deux à trois heures de travail mental, de réflexion complexe pour gérer son effort, la distance, les obstacles, le chronomètre, pour se situer dans un plan de progression annuel et pluriannuel. En compétition, s’ajoutent la maitrise du stress, de ses émotions, la gestion des opportunités, la capacité à passer d’un état mental extrême à un autre... Cette stratégie de flexibilité psychologique conduit le sportif à s’adapter en toutes circonstances et très rapidement, aux fluctuations permanentes des situations et du milieu, à switcher entre disponibilité et décision, entre vigilance et passage à l’action.

    De son côté, l’administration recrutait ses programmeurs par concours de catégorie B "Secrétaire Administratif spécial programmeur". Mais auparavant il fallait être autorisé à concourir, c’est-à-dire avoir été admis à deux batteries de tests psychotechniques. Il n’était possible de passer ces tests qu’une seule fois. Échouer à ces tests signifiait envisager un autre métier. Conscient de l’enjeu, je les ai préparés comme pour une compétition, physiquement, psychologiquement et mentalement.

    Les premiers tests dits "Tests PTT" étaient collectifs. Réunis dans une grande salle, chaque candidat avait sur sa table un cahier d’une quinzaine de pages. Un appariteur, juché sur une estrade, donnait le top départ pour tourner une page et faire l’exercice, puis le top fin d’exercice où l’on devait impérativement poser son stylo.

    Admis aux premiers tests, les deuxièmes tests, individuels, se passaient face à un psychologue. Selon le candidat, ils pouvaient durer plus ou moins longtemps, jusqu’à facilement une heure. L’un de ces tests consistait à reconstituer un puzzle en 3D, en fait un parallélépipède rectangle composé de 9 pièces différentes peintes en noir. On fermait les yeux et quand on les rouvrait, les 9 pièces étaient éparpillées sur la table. On pouvait faire ce test deux voire trois fois de suite selon la méthode de reconstitution utilisée. J’en ai utilisé trois différentes, ce qui a déconcerté mon psychologue, à deux doigts de me proposer un quatrième essai pour cerner ce qui se passait dans mon cerveau.

    Pour devenir programmeur, il fallait non seulement avoir certaines dispositions mais il fallait également être très déterminé. Admis aux tests, le concours lui-même se préparait par correspondance pendant un an. Les cours étaient assurés par le Ministère des Finances et un examen final délivrait un Certificat d’Aptitude aux Fonctions de Programmeur. Au concours administratif il y avait les épreuves classiques, dissertation ou résumé de texte et droit administratif, auxquelles s’ajoutait un programme COBOL. La réussite au concours permettait d’être titularisé.

    Titularisé le 1er janvier 1971, la veille, je montais encore du papier sur l’imprimante et des bandes magnétiques sur les dérouleurs. Le lendemain, j’étais programmeur aux Études et mes nouveaux collègues étaient soit ingénieurs (ITR ou IGREF), soit professeurs de math. Je n’avais pour ma part qu'un Brevet de Parachutiste et seulement réussi des tests psychotechniques puis un concours administratif de catégorie B. J’avais 23 ans et la moyenne d’âge de notre entité informatique était de moins de 30 ans.

    Anecdote : le 1er janvier 1971 parait « La méthode informatique » de Robert Mallet (texte fondateur de la méthode CORIG).
    Tous découvraient l’informatique et s’étaient sans doute initiés à leur rôle de chef de projet et d’analyste par des stages chez le constructeur. Confrontés à ces nouveaux métiers, nous étions tous égaux et chacun apprenait de sa recherche personnelle. Bien que nous n’en fussions qu’aux balbutiements de l’informatique et qu’il n’exista pas de corps d’informaticiens, la hiérarchie administrative avait déjà cloisonné les fonctions de chef de projet, d’analyste et de programmeur.

    Dans la dynamique de mai 68, les collègues se réunissaient de temps en temps dans un couloir pour refaire le monde. Il faut dire qu’aucune application ne donnait vraiment satisfaction aux utilisateurs. Ce cloisonnement « chef de projet/analyste/programmeur » était régulièrement contesté, pas seulement pour la méthode de développement mais également à cause de l’impossibilité d’être tantôt l’un, tantôt l’autre. Ce sont ces réunions contestataires qui ont inspiré ma démarche de développement.

    Parmi mes collègues aux profils hétéroclites, bien trop occupés à apprendre leur nouveau métier, je me suis retrouvé livré à moi-même. Marginalisé dès le départ, je le suis resté durant toute ma carrière avec pour objectif d’inventer ma propre méthode de développement en décloisonnant le développement et en me rapprochant le plus possible de l’utilisateur jusqu’à développer dans leur entité métier.

    Une fois nommé, comme tout le monde, j’ai fait mes classes chez le constructeur : Système d’exploitation (JCL), Assembleur, Fortran, Cobol, LCP… et selon nos préférences de langage, l’Assembleur nous destinait à intégrer l’équipe système, le Fortran, les statistiques et le Cobol, la gestion. J’ai opté pour la gestion.

    Le service Documentation jouait un rôle important dans notre auto-formation. Périodiquement, une revue de presse concoctée par notre documentaliste circulait dans les bureaux avec une liste d’émargement et une liste des derniers ouvrages acquis. Un formateur permanent organisait régulièrement des formations animées par un intervenant extérieur. Nous-mêmes étions sollicités pour assurer des formations en vue de faire partager nos acquis.

    § 1.3. Autoformation

    Fin des années 60 – début des années 70, les fichiers étaient des fichiers consécutifs sur bandes magnétiques. Les disques n’existaient pas encore, ni les terminaux, ni à fortiori l’éditeur.

    La programmation comportait plusieurs étapes :

    • L’analyste : Rédaction de l’analyse de la fonctionnalité à programmer,
    • Le programmeur : Conception de l’algorigramme à partir de l’analyse, Écriture du programme au crayon noir HB sur des feuilles de saisie,
    • L’atelier de saisie : Saisie du programme sur cartes perforées,
    • L’exploitation : Compilation du programme source => programme binaire (cartes perforées),
    • Le programmeur : Test du programme compilé.

    1969-1970 : J’étais durant cette période, opérateur-pupitreur. Les programmeurs corrigeaient leurs programmes à l’aide de cartes octales de couleur, réalisées avec une perforatrice manuelle, et ajoutées après le programme compilé. Sur le dessus du programme compilé, nous tracions un trait oblique au feutre au cas où… Car les cartes du binaire n’avaient pas de numéros d’ordre comme les cartes du programme source.

    1971-1976 : Programmeur à partir de 1971, je n’ai jamais utilisé de cartes octales pour mettre au point mes programmes. Pour autant, les premiers terminaux TTY étaient rares, nous en étions encore au 100% batch et à la carte perforée.
    Pour mettre au point nos programmes ou assurer leur maintenance, nous faisions manuellement ce que l’on fait aujourd’hui avec un éditeur. C’est-à-dire avec notre crayon, notre gomme, nos feuilles de saisie et nos cartes perforées. Autant dire que l’on avait intérêt à programmer correctement du premier coup. J’ai continué toute ma carrière à développer correctement du premier coup.

    1977-1980 : Affecté à la Maintenance, nous disposions d’une TTY pour tout le service (6 développeurs).
    TTY (TeleTYpewriter), sorte de machine à écrire connectée (téléscripteur). En 1980, notre TTY a été remplacée par un terminal écran mais nos programmes "conversationnels" fonctionnaient toujours ligne à ligne.

    Autoformation

    Par autoformation, j’entends ne pas attendre passivement des recettes à appliquer mais être actif intellectuellement, réfléchir, penser par soi-même, s’interroger, piller, entretenir sa curiosité pour enrichir son savoir-faire et formater le petit disque dur que l’on a entre les deux oreilles.

    Les stages chez le constructeur, langage (COBOL), méthodologie (LCP), enseignent la théorie. Assis à son bureau devant son analyse, il faut s’inventer, traduire ce que l’on a appris en codage sur des feuilles de saisie (25 lignes de 80 cases). La difficulté de mettre au point un programme implique de ne pas se rater.

    Mon plus gros programme réalisé dans ces conditions, un programme "conversationnel", totalisait 8.000 lignes, soit 320 pages de rédaction au crayon. Heureusement, entre temps, nous étions passés des GE 400 à l’IRIS 80, des bandes aux disques de 600 millions de caractères.

    Mon parcours initiatique, mon excellente orthographe et peut-être mes années de dessin industriel, m’ont permis de penser et créer dans l’instant mes tables BDD, mes écrans, mes états, mes documents administratifs. Face à une problématique, tout s’organise instantanément dans mon cerveau. Pas besoin de réunions, de modèles conceptuels, pas de tâtonnements. C'est pratiquement parfait du premier coup.

    Si la programmation se limitait à l’usage d’un langage, on ne parlerait pas d’apprentissage de la programmation mais d’apprentissage d’un langage.

    Programmer ne consiste pas à coder pour coder comme le suggèrent tous les exercices d’algorithmique, c’est-à-dire avec pour seul objectif en tête, un unique problème théorique. Programmer, c’est concevoir le code optimal traduisant une réflexion plurielle gouvernée par un mode opératoire.

    Chaque programme est développé selon l’adoption de règles personnelles, d’un mode opératoire qui s’affine, qui s’adapte aux langages et aux diverses évolutions techniques. Ces règles personnelles rendent le développement quasi « industriel ».

    Il ne s’agit rien d’autre que de concevoir un AGL minimaliste de développement, le moins contraignant possible, pour optimiser, standardiser la programmation, pour créer une continuité intellectuelle d’un programme à l’autre, pour organiser une synergie des investissements plutôt que de programmer isolément chaque programme.

    ■ Mode opératoire du « serial développeur »

    Intelligible, le programme est impacté par :


    Fonctionnel, le programme est impacté par :


    Aparté

    Il se trouve qu’entre 1981 et 1984, j’ai suivi une formation permanente pour l’obtention d’un DUT Informatique. Cette formation s'adressait à des professionnels aguerris, autodidactes et sans diplôme.

    Le DUT ne me servait à rien puisque j’étais dans la fonction publique où une promotion ne dépend pas d’un diplôme mais d’un concours. L’intérêt était de savoir ce qu’il s’y disait, d’officialiser en quelque sorte ce que j’avais découvert par moi-même.

    Concernant l’apprentissage de la programmation, était-ce parce que nous étions déjà des professionnels, toujours est-il qu’à part un cours sur la méthodologie LCP et une heure sur la conception d’un écran par un professionnel auto entrepreneur qui enseignait à l’IUT pour pouvoir le mettre sur sa carte de visite, je n’ai jamais rien entendu concernant la façon de programmer (simulation, règles de nommage, règles de mise en page, etc.). Ces sujets sont-ils abordés dans le cycle universitaire des étudiants ou appartient-il à chacun d’y réfléchir lui-même ?
    À partir d’un écran ou d’un état, on peut estimer le degré de réflexion du développeur et déceler, par exemple, s’il tient compte ou non des difficultés visuelles de beaucoup d’utilisateurs, de leur éventuelle fatigue mentale, ou du fait que la plupart des gens ne lisent pas. La simple conception d’un écran ou d'un état met en évidence l’esprit d’analyse et de synthèse, la créativité, la technicité, la simplicité, la personnalité, l’empathie du programmeur.

    L’apprentissage de la programmation ne se termine jamais vraiment, on est toujours en mode recherche. Il suffit parfois de peu de chose pour reconsidérer sa façon de programmer, le design original d’un écran aperçu par hasard, une instruction délaissée qui devient capitale comme le MOVE CORRESPONDING du COBOL ou le PRINT FILE du SGBD INFORMIX.

    Deux programmes fondateurs

    Les applications batch d’autrefois mettaient en œuvre trois programmes principaux, contrôle, mise à jour et édition.

    Mes deux premiers programmes en tant que professionnel, une mise à jour et une édition, ont formaté durablement ma démarche de développement. Mes collègues, "conditionnés" depuis plus longtemps que moi n’ont jamais vraiment réussi à penser par traitements, en termes d'actions. Irrésistiblement, leur réflexion en termes de conditions finissait par s’imposer.

    Mise à jour

    À la suite de la formation LCP qui terminait mon cycle de formation chez le constructeur, je me suis installé par hasard dans un bureau où 7 collègues développaient l’application de gestion du personnel du Ministère.

    Les développements étaient sur le point de se terminer mais il manquait encore le programme le plus important, la mise-à-jour. Deux tentatives de développement n’avaient pas abouti et la troisième venait d’être interrompue. Le chef de projet a alors manifesté son impatience et exhorté l’équipe à prendre ses responsabilités. Ne faisant pas partie de l’équipe et n’étant pas sollicité, sans doute à cause de mon inexpérience supposée en programmation, j’ai quand même relevé le défi en proposant :

    - « Si vous vous voulez, je veux bien le faire votre programme ! »

    Une analyste (ex-prof de math) qui avait fait le stage LCP avec moi, m’avait vu à l’œuvre au cours de ce stage et s’est immédiatement proposée pour faire l’analyse.

    Réponse du chef de projet :

    - « Pourquoi pas, on n’a plus rien à perdre. »

    Deux mois plus tard, le programme était développé. Ce fut mon premier algorigramme LCP et mon premier programme en tant que professionnel. Les collègues qui ont maintenu mon programme ont respecté ma façon de programmer. Il a géré le personnel pendant 14 ans. Ma façon de programmer a intrigué beaucoup de monde. Notamment notre formateur qui un jour m’a présenté un enseignant, curieux de voir mon programme. Sa réflexion a été :

    « Ah bon ! C’est comme ça que les professionnels travaillent ? »

    Puis il est reparti avec le listing de mon programme. Deux particularités ont dû l’interpeller, mes noms de données préfixés de l’étiquette logique de leur fichier et la structuration "LCP" de mon programme.

    Aujourd’hui, préfixer les noms de données du nom de leur table est une convention, pour ne pas dire une règle SQL. L’étiquette logique du COBOL s’est juste transformée en un pseudo court (2 à 5 caractère) du nom complet mais théorique de la table. Ainsi, les tables "Départements", "Communes", "Établissements", etc. se nomment concrètement "DP", "CM", "ET", etc. à l’instar des étiquettes logiques d’autrefois.

    J’avais réalisé ce programme en appliquant les principes LCP que je venais tout juste d’apprendre. Ce fut un effort mental très important car je devais me débarrasser de la démarche par conditions qui m’avait jusque-là été enseignée. Ce fut vraiment deux mois d’effort mental quasi permanent, y compris dans les transports et chez moi. À cet effort mental s’en est ajouté un autre, car mon analyste me donnait son analyse en CORIG. La démarche CORIG est à l’opposé de la démarche LCS (Logique de Construction de Système). L’analyse CORIG découpe la problématique en tâches. Je devais donc traduire le besoin en lisant les tâches horizontalement. La programmation CORIG quant-à elle, est une démarche verticale, linéaire dont l’exécution de chaque fonctionnalité dépend du résultat de conditions.

    L’algorigramme LCP d’une mise à jour est une succession de structures alternatives qui s’étirent horizontalement vers la droite.

    Mais ce que ma programmation ne montre pas, c’est ma démarche intellectuelle. Ma programmation ne se limite pas à transcrire l’analyse dans un langage. Je m’approprie la problématique, l’efficience des programmes que je développe ne dépend que de moi et de mon implication.

    À travers l’analyse, je cherche à comprendre ce qu’attendent le chef de projet, l’analyste et surtout l’utilisateur. J’alimente un dialogue entre les différents intervenants. Cela m’amène à m’interroger, à faire préciser certaines informations par l’utilisateur, à ajouter éventuellement de nouvelles données, de nouvelles fonctionnalités.

    Édition

    Mon programme de mise à jour terminé, l’équipe a été dissoute pour constituer de nouvelles équipes de développement. Oublié, j’ai dû laisser mon poste de travail et retrouver une place ailleurs. J’ai pu m’installer trois bureaux plus loin où une équipe développait une application pour le compte de l’Office des Vins.

    Le chef de projet, jeune Ingénieur des Travaux Ruraux, s'initait à l’informatique et l’un des développeurs faisait son stage en entreprise dans le cadre de son DUT Informatique.

    L’ambiance dans ce bureau était plutôt tendue, chacun travaillant en silence, concentré sur son listing. Tout à son travail, le chef de projet laisse échapper :

    - « On ne sera jamais dans les temps, on va avoir des pénalités de retard. »

    À leur grande surprise, je leur dit :

    - « Si vous voulez, je peux vous aider ? »

    J’ai d’abord été testé avec un programme d’édition d’erreurs que j’ai écrit en une semaine avec quasiment une seule instruction, un « MOVE CORRESPONDING », le seul que j’ai utilisé dans toute ma carrière de coboliste. Rassurés, ils m’ont confié LE programme d’édition de l’application, un programme qu’ils considéraient comme particulièrement complexe. Deux mois plus tard, le programme imprimait les premières fiches d’encépagement et l’application était opérationnelle dans les temps. Le programme sera vendu quelques années plus tard au CIVC (Comité Interprofessionnel des Vins de Champagne).

    La difficulté d’un programme d’édition réside dans la gestion des en-têtes et des sauts de pages que l’on doit intégrer dans la structure LCP.

    Un algorigramme d’édition est souvent une succession verticale de structures alternatives. Avec ce programme, ce fut donc mon deuxième algorigramme LCP. Après ça, je n’ai plus eu besoin d’en réaliser, je développais à main levée.

    Contrôle

    L’algorigramme d’un programme de contrôle s’accorde très bien avec la démarche CORIG en se déployant verticalement en une succession de traitements à faire ou à ne pas faire.

    § 1.4. Conclusion

    Algorithmique

    On propose des exercices corrigés d’algorithmique mais enseigne-t-on vraiment l’algorithmique ?

    Les exercices corrigés d’algorithmique sont censés être compris par le lecteur mais ils ne s’accompagnent ni d’un raisonnement argumentée, ni même d’un algorigramme. Il appartient au lecteur de s’approprier le raisonnement de l’auteur à la seule lecture du code ou du pseudocode.

    L’algorithmique, c’est comprendre le processus logique d’une problématique et identifier l’enchainement des étapes à automatiser. Cela suppose de mener une réflexion sur le sujet mais réfléchir est un cheminement intellectuel personnel et spécifique à chaque problématique. Chaque méthodologie de programmation propose sa recette, son modèle de réflexion.

    On peut expliquer pédagogiquement le cheminement de sa propre réflexion vis-à-vis d’une problématique mais cela ne constituera aucunement une référence, une démarche reproductible qui dispense d’une réflexion personnelle influencée ou non par la pratique d’une méthode de programmation.

    Programmation

    On apprend un langage, un système d’exploitation (Shell), une méthodologie mais enseigne-t-on vraiment la programmation ?

    Programmer, c’est structurer logiquement le non-dit d’une problématique. Concrètement, cette structuration logique passe par trois phases :

    • Concevoir le Fichier Logique d’Entrée (FLE).
      Autrement dit, identifier et structurer les entités, leurs identifiants et leurs attributs nécessaires à l’obtention d’un résultat.

    • Concevoir le Fichier Logique de Sortie (FLS).
      Autrement dit, identifier les besoins en sortie et les corréler structurellement aux entrées.

    • Concevoir l’algorithme du traitement.
      Autrement dit, structurer logiquement les traitements permettant à partir du FLE d’obtenir le FLS. Selon que le programmeur est étudiant, débutant ou confirmé, la conception de l’algorithme peut nécessiter trois représentations successives : pédagogique, graphique et mentale.

    Programmer résulte d’un raisonnement logique et d’une réflexion synthétisant plusieurs savoirs propres à chacun de nous. On peut éventuellement expliquer pédagogiquement le cheminement de sa propre réflexion vis-à-vis d’un développement mais chaque développement est spécifique et chaque développeur possède son propre raisonnement, sa propre expérience.

    Un programme est une œuvre de l’esprit, une œuvre originale qui porte l’empreinte, la patte, le style, l’expérience, la conception personnelle de son créateur, le programmeur.

    Il suffit, à partir d’un énoncé très simple, de soumettre la création d’un écran à 30 programmeurs chevronnés pour obtenir 30 versions différentes.

    Apprentissage

    Ma période d’apprentissage s’est étalée de mi-1966, j’avais 18 ans, à mi-1971. Au cours de ces cinq années d’apprentissage de la programmation, j’aurais été successivement « Préparateur de commandes », « Coursier », « Militaire », « Chômeur », à nouveau « Coursier », « Opérateur-Pupitreur » et enfin programmeur.

    Évidemment, je n’ai rien conservé de mes premiers cours d’assembleur chez EPSI et je ne me souviens que de la pédagogie des cours du Ministère des Finances pour expliquer la condition. Un dessin en trois parties représentant en haut, un réservoir de billes de couleurs, au milieu un labyrinthe de tubes et en bas des bocaux, chacun censé recevoir les billes d’une même couleur. Après mon stage LCP, j’en ai beaucoup voulu à cette pédagogie qui avait participé au formatage de ma réflexion en termes de conditions.

    Échappant à un destin d’ouvrier, j’ai eu la chance grâce à mes prédispositions et à ma détermination de faire partie des pionniers de l’informatique. Depuis la fin des années 60 jusqu’au début des années 90 pour certains, jusqu’à la retraite pour d’autres, mes collègues et moi avons vécu ensemble, passionnément, les mutations technologiques et la diversification de l’informatique. Ces 30 premières années de l’informatique ont correspondu à notre tranche de vie 20-50 ans. Notre lieu de travail, un ancien monastère, a été l’épicentre de notre vie professionnelle et sociale. Après notre apprentissage de la programmation, chacun de nous a tracé sa propre route mais la trentaine de pionniers que nous étions au début continue de se fréquenter cinquante ans plus tard.

    L’un de nous qui avait choisi le Fortran a sorti pendant quatre ans presqu’exclusivement des tableaux statistiques avant de passer le concours d’Attaché de l’INSEE. Étudiant pendant deux ans à l’ENSAE, il s’est fait détacher de l’INSEE au SCEES, puis affecter successivement à l’INSEE Paris et Orléans.

    Un autre a misé sur le CNAM. Ayant obtenu un DUT d’économie, une maitrise d’organisation et une maitrise d’informatique, il a terminé sa carrière comme Ingénieur Technico-Commercial dans différents services publics : pompiers, police, lycées, services techniques, etc.

    Un autre encore a révolutionné la bureaucratie du ministère en s’intéressant très tôt à la bureautique. Ce fut le sujet de mon mémoire à l’IUT Paris-Descartes en 1983-84.

    Quant-à moi, j’ai déjà évoqué mon parcours tortueux de fonctionnaire, jalonné par ma quête obsessionnelle d’un contexte favorable à ma recherche des mécanismes d’un développement bottom-up dans l'entité métier de l'utilisateur.

    Nous avons pris des directions différentes mais toujours animés de notre esprit pionnier, ce besoin d’avancer dans l’inconnu, de découvrir, d’apprendre, de réfléchir par nous-même, de tracer notre propre route.

    Vous pouvez retrouver la suite de mes aventures dans un précédent sondage qui propose un autre éclairage de notre apprentissage de la programmation :

    07/11/2016 Sondage : Pourquoi avez-vous choisi de devenir développeur ?

    06/02/2017 Message : Inventer ma propre démarche d’informatisation

    1. On peut dire que je suis né programmeur
    2. La passion pour la résolution de problèmes
    3. La passion pour le codage
    4. Inventer ma propre démarche d’informatisation


    Mis à jour 12/03/2024 à 16h01 par APL-AML