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

Au Pied Levé - À Main Levée

I-1.1.2. Adeptes VS Détracteurs

Noter ce billet
par , 01/03/2021 à 11h45 (285 Affichages)
2. FORUMS

SOMMAIRE de la FAQ
SOMMAIRE « Contributions aux forums »
SOMMAIRE « Synthèses de discussions »

Discussion : Qui pratique la programmation spontanée ?

■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■

  • Avant-propos
  • Adeptes VS Détracteurs
    1. Développeur VS Programmeur
    2. Programmation spontanée VS Programmation improvisée
    3. Logigramme VS Algorigramme
    4. Adeptes pondérés VS Détracteurs spontanés
    5. Traitements (Mode plan) VS Conditions (Mode street)
    6. Mise en page VS Commentaires
  • Conclusion
■ Avant-propos

Dans son premier message, Doloop faisait référence à l'auteur d'un livre paru dans les années 80, qui annonçait qu'il n'y aurait que 10 % des programmeurs en capacité de se passer de dessiner un algorithme pour faire un programme.

Vous savez quoi ? J’ai recensé le nombre d’intervenants dans cette discussion et identifié parmi ceux-ci les adeptes auto-déclarés ou potentiellement adeptes de la programmation spontanée… en capacité, donc, de se passer de dessiner un algorithme pour faire un programme :

  • Nombre d’intervenants : 153
  • Nombre d’adeptes : entre 15 et 20

Étonnamment, le rapport du nombre d’adeptes est proche des 10% prévus il y a quarante ans par l’auteur Zaks Rodnay.

Citation Envoyé par IFA2377 Voir le message
« Communiquer, c’est davantage que transmettre des informations. »

Ce que nous croyons être un dialogue entre deux individus, n'est en réalité que deux monologues. Le premier a lieu entre nous-même et notre imaginaire et le second entre notre interlocuteur et son propre imaginaire.

Il faut bien comprendre que quelqu’un qui entend nos paroles, il les passe au filtre de ce qu’il est prêt à comprendre, qu’il essaie de les intégrer en fonction de son propre vécu pour ensuite se créer une représentation mentale de ce que l’on a voulu dire.
Les détracteurs de la démarche ont tous de bonnes raisons personnelles de critiquer le concept de programmation spontanée. Toutefois, il en est une commune à tous : celle de ne pas pratiquer cette démarche et donc in fine d’en ignorer toute la réalité. Persuadés qu’ils détiennent la vérité inoculée par l’enseignement formel, chaque détracteur imagine le concept en l’assimilant à tort à la programmation improvisée des bidouilleurs.

Alors que valent toutes leurs critiques virulentes, acerbes, ironiques ? Rien !

Le 8 décembre dernier (2020), la discussion a fêté ses 17 ans d’activité. Et depuis tout ce temps, l’incompréhension entre les Adeptes et les Détracteurs se poursuit comme aux premiers jours grâce à l’interprétation discordante de l'expression programmation spontanée. Cette expression ayant suscité un certain nombre de réactions épidermiques, j’avais proposé en son temps deux autres expressions, Programmation à main levée puis Programmation mentale. En fait, le ferment de cette discussion ne réside pas dans l’expression elle-même mais dans son interprétation par au moins deux profils d’informaticiens antagonistes :

  • les Développeurs d’un côté,
  • les Programmeurs de l’autre.

■ Adeptes VS Détracteurs

Afin de lever toute ambiguïté d'interprétation, ce billet oppose deux à deux plusieurs termes ou expressions plus ou moins ambivalents :

  1. Développeur VS Programmeur

    Doloop a réalisé qu’il développait ses programmes et non qu’il les programmait. En initiant sa discussion, il s’adressait à d’autres Développeurs pour tenter d’expliquer et de comprendre son ressenti.

    L’incompréhension entre les deux profils d’informaticiens vient de ce que le champ de compétences de l’un et de l’autre inclue la programmation (le codage) qui est la partie visible, concrète et commune à chacun des deux profils. Chacun se sent donc concerné par le sujet mais l’aborde avec son vécu, son environnement de développement, son niveau de compétence, son état d’esprit Développeur ou son état d’esprit Programmeur.

    Je parle d’état d’esprit car on peut très bien avoir un statut de programmeur et exercer son métier avec l’état d’esprit d’un développeur. Les détracteurs qui exercent leur métier avec l’état d’esprit Programmeur confondent la programmation spontanée des développeurs avec la programmation improvisée des bidouilleurs.

    Développeur

    Développer, c’est penser à tout. Le champ de compétences d’un Développeur ne se limite pas à la programmation. Son métier inclue des compétences dans tous les domaines (chef de projet, analyste, organisateur, concepteur, coordinateur, webdesigner, etc.).

    C’est la personnalité de l’informaticien, sa curiosité, son investissement, ses initiatives, ses rencontres, la nécessité, le défi, le risque, le contexte, la spécialité informatique, en un mot son parcours qui fait que progressivement, le développeur agrandit son champ de compétences, prend de l’assurance, maitrise son sujet, invente des raccourcis, et formate finalement son cerveau jusqu’à le rendre capable de programmer spontanément et capable même de développer une application spontanément... Mais ça, c’est une autre histoire !

    Programmeur

    Un Programmeur qui code un programme peut très bien dire qu’il développe. Cela n’en fait pas pour autant un développeur. Entre un programmeur débutant et un développeur confirmé qui excelle dans son professionnalisme, il existe une grande palette de niveaux de compétence.

    Qu’un bidouilleur joue les apprentis sorciers en adoptant la démarche d’un développeur chevronné sans en avoir les capacités n’est pas le sujet. Toutes les remarques désobligeantes sont tout simplement hors sujet. Elles n’ont rien à voir avec la programmation spontanée mais avec la programmation improvisée.

    Un Développeur qui programme spontanément ne subit pas, il agit. Il s’approprie mentalement les problématiques. Il sait ce qu’il fait et le fait dans les règles de l’art. Dénigrer, fantasmer négativement la démarche ne fait que révéler l’inexpérience, le manque de curiosité et le manque d’ouverture d’esprit des auteurs de ces remarques désobligeantes.

    Quand on critique, on se doit d’être soi-même irréprochable. Les posts de ces détracteurs parlent d’eux-mêmes : pas de titre, fautes d’orthographe, de grammaire, de syntaxe, de frappe, aucun effort de présentation, argumentation présumée ne prouvant rien. L’absence d’empathie cognitive, de recul, de réflexion dans la composition de ces posts laisse imaginer la qualité, la rigueur de leur programmation. Prisonniers de leurs dogmes éducatifs et donc assurés de détenir la vérité, le potentiel qu’ils affichent ne plaide pourtant pas en leur faveur. En confondant Programmation spontanée et Programmation improvisée, ils continuent depuis 17 ans à assimiler les Développeurs qui sont de vrais professionnels aux Bidouilleurs qu’ils côtoient.

    Ce n’est pas parce que l’on ignore la démarche qu’elle n’existe pas et qu’il faut continuer de l’ignorer en se satisfaisant de son statut d’Ouvrier Spécialisé Programmeur, conditionné par un enseignement qui l’ignore également. L’apprentissage de son métier ne s’arrête pas à la théorie des salles de cours. Il appartient à chacun de prolonger ses acquis par la valeur ajoutée de sa réflexion personnelle. Comprendre et assimiler la démarche, c’est gagner en maturité, c’est acquérir son autonomie, c’est booster son potentiel, c’est façonner sa valeur ajoutée, c’est adopter l’état d’esprit développeur.

    Le programmeur qui lit ce billet sans en comprendre le message malgré force explications peut et doit comprendre qu’il fait simplement partie des 90% de programmeurs qui selon Rodnay Zaks ne peuvent se passer de dessiner un algorithme pour faire un programme. Faire partie du troupeau n’autorise pas pour autant à juger les 10% d’adeptes de la programmation spontanée sans autre réflexion que le seul rapprochement de l’expression avec son propre vécu.

  2. ■ Logigramme VS Algorigramme

    Quatre termes sont utilisés pour nommer la représentation graphique d’une structure : organigramme, algorigramme, logigramme, ordinogramme. Certains de ces termes peuvent être associés à une symbolique qui leur est propre, ce qui permet de les différencier. Une décomposition au niveau de l’instruction n’a rien à voir avec une décomposition au niveau logique des traitements. Cette distinction n’a rien d’officiel, c’est simplement le résultat d’une réflexion personnelle sur le sujet.

    Algorithme

    L’Algorithme décrit la manière dont un système réalise une tâche, soit à l’aide d’un pseudo-langage, soit en programmant une suite ordonnée d’instructions propres à un langage. Le terme d’algorithme est généralement perçu comme un synonyme de programme. L’algorithme est donc spécifique d’un langage.

    Organigramme

    L’Organigramme est le terme générique pour définir la représentation graphique d’une structure, qu’elle soit informatique ou non. L’organigramme peut donc représenter l’organisation hiérarchique d’une entreprise, d’une administration. En informatique, l’organigramme définit la représentation graphique d’un programme lorsque l’on ignore à quelle symbolique il est fait référence.

    Algorigramme

    L’Algorigramme, proche du terme algorithme, sous-tend l’idée d’une représentation graphique de l’algorithme, donc du codage. De fait un pseudo-langage visuel, l’algorigramme recourt à une symbolique normalisée.

    Les symboles normalisés datent des années 60 et de la programmation dite "sauvage". Ces symboles représentent graphiquement les instructions d’un pseudo-langage ou d’un langage. Cette symbolique sans doute normalisée mais néanmoins archaïque n’est finalement qu’un pseudo-langage visuel. C'est une représentation graphique au niveau de l’instruction digne des Shadocks et impossible à utiliser concrètement... sans normographe en plastique (orange) ou un logiciel graphique spécifique.

    Norme ISO 5807 Introduction aux algorigrammes

    Logigramme

    Le terme Logigramme est plus adapté pour définir la représentation graphique de l’approche logique d’un processus correspondant à un raisonnement par traitements. Il structure visuellement, à l’aide des symboles de deux structures types (répétitive et alternative), les étapes logiques (traitements) d’un processus, d’un programme.

    Les deux structures types de la symbolique LCP peuvent se combiner pour former des structures dites complexes pouvant adopter deux formes de hiérarchie, simple ou complexe :

    Les deux structures types : répétitive et alternative

    • Structure répétitive (ou itérative) : Pour représenter la structure répétitive dans l’algorigramme, on place un branchement conditionnel à la fin de l’ensemble répétitif.
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
                     ┌─────────────┐
                     │    D-PROG   │
                     └──────┬──────┘
                            ├──────────┐
                     ┌──────┴──────┐   │
                     │   T-ARTICLE │   │
                     └──────┬──────┘   │
                            ◊──────────┘
                     ┌──────┴──────┐
                     │    F-PROG   │
                     └─────────────┘
    • Structure alternative : Pour réaliser une structure alternative, on doit programmer deux actions alors que seulement l’une d’entre elles est exécutée.
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
                     ┌─────────────┐
                     │    D-PROG   │
                     └──────┬──────┘
                            ├───────────────────┐
                     ┌──────┴──────┐            │
                     │  D-ARTICLE  │            │
                     └──────┬──────┘            │
                  ┌─────────◊─────────┐         │
           ┌──────┴──────┐     ┌──────┴──────┐  │
           │  T-ARTICLE  │     │  T-ARTICLE  │  │
           └─────┬───────┘     └─────┬───────┘  │
                 └──────────┬────────┘          │
                     ┌──────┴──────┐            │
                     │  F-ARTICLE  │            │
                     └──────┬──────┘            │
                            ◊───────────────────┘
                     ┌──────┴──────┐
                     │    F-PROG   │
                     └─────────────┘

    Billet APL-AML LA PROGRAMMATION RATIONNELLE

    Ordinogramme

    L’Ordinogramme, premier terme utilisé pour définir un organigramme informatique, peut être utilisé pour définir un organigramme n’ayant recours ni à la symbolique normalisée ISO 5807, ni à la symbolique LCP… à la symbolique de la Programmation Structurée, par exemple.

    Forum Algorithmes et structures de données

    Bien que concevant mentalement mes algorigrammes, je remarque que je suis sans doute le seul à poster des algorigrammes dans le Forum Algorithmes et structures de données :


  3. Programmation spontanée VS Programmation improvisée

    La Programmation spontanée est au Développeur ce que la Programmation improvisée est au Bidouilleur.

    Citation Envoyé par davcha Voir le message
    Le mot "spontané" est très mal choisi. Le dictionnaire va dire quelque chose comme : "Ce qui se fait naturellement, sans intervention extérieure".

    Dans notre débat, ce n'est vraiment pas clair comme définition, donc pas clair non plus comme mot.
    Citation Envoyé par LadyWasky Voir le message
    Le terme "Spontané" est franchement ambigu.

    Définition 1 : sans idée, même floue, de comment on va aboutir au résultat.

    Définition 2 : sans avoir pris soin, au préalable, d'avoir écrit un algorithme sur le papier.

    La première définition est suicidaire, je me demande même si c'est possible de réaliser quelque chose avec ce genre de spontanéité ! La deuxième est, avouons le, franchement plus concevable.
    Citation Envoyé par LadyWasky Voir le message
    On s'est surtout rendu compte que nos désaccords dépendaient de la définition que l'on donnait à ce terme : "la programmation spontanée". C'est cette expression qui est en fait le piège de tout le fil de discussion.

    C'est quoi pour toi "la programmation spontanée" ?

    Ne me dis pas que c'est développer sans avoir tout planifié ou sans avoir un but précis, parce si ça peut te rassurer c'est impossible de se lancer dans un programme si on a pas une idée de ce qu'on veut faire ni même d'aboutir à quelque chose de sérieux si on ne sait pas comment on va s'y prendre : que ce soit déjà écrit sur le papier ou non.
    Citation Envoyé par zecreator Voir le message
    Pour moi, le programmeur spontané part d'une idée de base. Il visualise l'application finale, son utilisation et éventuellement pense déjà aux technologies qui seront utilisées.

    C'est quelqu'un qui n'aime pas être dépendant de méthodes, de contraintes (temps, techniques...) et qui n'applique que les siennes. C'est quelqu'un de créatif, qui possède une bonne expérience des NTIC et est un "touche-à-tout".

    Souvent étiqueté de "bidouilleur" ou de "pisseur de code", car ne suivant que très rarement les formalismes du métier, il n'en est pas moins productif et compétent.

    C'est aussi quelqu'un qui rencontre des difficultés à formuler les aspects d'un projet car il lui manque souvent du vocabulaire technique (quelque chose dont il ne trouve que rarement l'utilité).

    Voila ma définition en ce qui concerne la programmation spontanée et le profil que j'ai souvent rencontré par ceux qui la pratique.
    Programmation spontanée

    Citation Envoyé par Gnomial Voir le message
    Quand le développeur écrit son programme, il a son propre "environnement de réflexion"
    La programmation spontanée n'implique pas "arrache", "bidouille", "manque de qualité", "affinité avec certains problèmes spécifiques", "intuition", "aucune analyse", etc., comme l’affirment ses détracteurs. Bien au contraire, cela signifie que dans sa tête, il faut être en quelque sorte "câblé", que l’on maîtrise son sujet, que l’on se soit interrogé, que l’on ait installé puis personnalisé sur son petit disque dur (sa mémoire procédurale) son propre environnement mental de développement permettant de s’affranchir des contraintes (recettes, algorigrammes, modèles, normes, commentaires, documentation, etc.), d’être autonome, de se simplifier la vie, d’épurer sa réflexion, de prendre des raccourcis pour être efficace.

    La programmation spontanée est un processus mental qui se construit en éduquant, en conditionnant sa mémoire procédurale. Ça ne s’apprend pas dans une salle de cours, c’est une découverte de ses possibilités et l’acquisition d’une confiance en soi. Quand on y a recours, c’est que l’on maitrise son sujet, que l’on a enlevé définitivement les roues stabilisatrices de son vélo, que l’on est responsable. Il faut juste oser, lâcher le lest de ses certitudes, s’approprier les problèmes, être autonome et penser par soi-même.

    Répondre spontanément à une question n’est possible que si l’on connait déjà la réponse.

    Programmer spontanément n’est possible que si le développeur sait déjà ce qu’il doit faire. Sa réflexion est professionnelle et parfaitement maitrisée grâce à son formatage mental intégrant :

    • Une méthodologie de programmation,
    • Une structure d’accueil de ses programmes avec :
      • squelette du programme (mise en page, canevas, skin),
      • identification du programme,
      • objet du programme
      • spécifications fonctionnelles,
      • titres des modules,
      • utilisation des majuscules et des minuscules,
      • indentations,
      • noms de variables communs à tous les programmes de l'application,
      • règle d'écriture des paramètres et des variables spécifiques,
      • shell d'exécution documenté en fin de programme.
    • Une charte graphique,
    • Des règles de développement,
    • L’adoption de standards,
    • Etc.

    La programmation spontanée suppose simplement de penser par soi-même, d’avoir cherché sa propre vérité, d’avoir acquis son autonomie, d’être pluridisciplinaire, d’être inventif :

    • C’est une quête de perfectionnisme toujours en éveil,
    • C’est la faculté de "faire tourner le code dans sa tête", de la même façon que l’on anticipe plusieurs coups aux échecs,
    • C’est la faculté de concevoir diligemment selon une structure solide mentalement,
    • C’est du savoir faire, des bonnes pratiques à concevoir soi-même.

      Il appartient à chacun de chercher sa vérité en lisant, en pillant ce que font les autres, en créant ses propres bonnes pratiques, en les adaptant aux innovations technologiques (langages, SGBD, médias, etc.).

      Cela, hélas ne s’enseigne pas. Ce qui s’enseigne, ce sont les langages, l’algorithmique, les recettes. C’est pratique, c’est concret, pas besoin de réfléchir ni de s’investir, c’est rassurant, il suffit d’appliquer.

    Billet APL-AML :arrow: I-2.2.4. La programmation mentale

    Pilotée en tâche de fond par la mémoire procédurale, la structure du programme s’élabore mentalement, en même temps que le codage des spécifications fonctionnelles (objet) et techniques (données, paramètres, variables) tout en se projetant dans le futur d’une problématique en construction.

    C’est la hiérarchisation des données qui permet de concevoir mentalement l’algorigramme, de structurer le programme selon la Logique de Construction de Programme. L’algorithme d’un programme étant conçu, que ce soit mentalement ou assistée d’un algorigramme, l’affaire est pliée.

    • « Quand on commence à tapoter on a déjà une "structure" en tête, la façon dont les différentes parties de la solution vont s'assembler ; le codage en lui même n'est que la réalisation des pièces du puzzle, mais l'image du puzzle et la forme des pièces qui le composent sont déjà dans ma tête, en tout cas pour la majeure partie. » - ErwanVDF

    • « La plupart du temps, je n'ai pas besoin de dessiner un algorithme ou de poser la chose sur papier au préalable. J'ai une structure en tête, le codage n'est qu'une forme d'expression de ma solution. » - ErwanVDF

    Si le Développeur n’évoque pas les spécifications (fonctionnelles, techniques), ce n’est pas qu’il les ignore, c’est tout simplement que cela ne constitue pas pour lui une préoccupation puisqu’il les crée en même temps qu’il code.

    Le non-dit n’empêche pas de travailler dans les règles de l’art. Pour ce qui me concerne, les spécifications ne sont tellement pas une préoccupation que je ne comprenais même pas de quoi il s’agissait. En fait, il s’agit tout simplement de ce que l’on appelait autrefois le dossier d’analyse.

    Il arrive que le Développeur doive mener une réflexion distincte avant d’entreprendre la réalisation d’une fonctionnalité mais la plupart du temps, sa réflexion en termes de spécifications a lieu en même temps qu’il développe. Les spécifications de ce qu’il développe ne se présentent pas sous forme de dossier mais elles existent belles et bien dans le programme lui-même :

    • dans sa partie déclarative (spécifications fonctionnelles : objet),
    • dans sa partie passive (spécifications techniques : données, paramètres, variables).

    Les détracteurs qui associent la supposée absence de spécifications à la programmation spontanée, révèlent parfaitement bien leurs conditions de travail dans un système cloisonné où le chef de projet donne son cahier des charges aux analystes qui donnent leurs analyses aux programmeurs qui programment. Les spécifications (dossier d’analyse) sont dès lors l’indispensable interface entre les deux métiers, analyste et programmeur.

    Programmation improvisée

    Le Programmeur Bidouilleur n’agit pas, il réagit, séquentiellement, en navigant à vue, sans réflexion préalable. C’est ce que dénoncent les détracteurs qui se trompent donc de cible en assimilant les adeptes de la programmation spontanée à des Bidouilleurs.

  4. Adeptes pondérés VS Détracteurs spontanés

    Curieusement, les messages des uns et des autres révèlent l’inverse de ce qu’ils sont dans leur démarche de développement.

    Adeptes pondérés

    Ainsi, les adeptes postent des messages élaborés, structurés, soignés, argumentés, pédagogiques, finement analysés psychologiquement, dépourvus d'agressivité. Leurs messages ne font que témoigner avec sagesse de leur expérience, de leur savoir-faire, du cheminement de leur réflexion.

    Contrairement aux messages de leurs détracteurs, les leurs ne sont nullement spontanés. Dépassionnés, à aucun moment, ils envisagent d’imposer leur démarche.

    Détracteurs spontanés

    À l’inverse, les détracteurs postent spontanément leurs messages. Pourquoi ? Parce qu’ils savent. Car la spontanéité suppose de préalablement savoir. Et les détracteurs savent. Ils savent ce que leur formation et leur environnement professionnel leur ont appris. Fatalement, puisqu’ils savent, c’est que les adeptes qui suivent un autre chemin que le leur, ne savent pas.

    La composition de leurs messages trahit leur spontanéité. Non titrés, courts, réprobateurs, sans empathie, assortis de nombreuses fautes. Leurs messages s’adressent davantage à eux-mêmes et aux autres détracteurs qu’aux adeptes. Ils se rassurent en témoignant de leur bien-pensance.

    Le manque de rigueur dans la composition de leurs messages laisse deviner la qualité de leur programmation. Lorsque l’on est rigoureux, on ne l’est pas que dans un seul domaine. Condamnant la prétendue absence de commentaires des adeptes, on imagine la qualité rédactionnelle des leurs.

    Si les détracteurs veulent vraiment comprendre le sens de la programmation spontanée, il leur suffit d’analyser leurs propres réactions spontanées vis-à-vis de cette expression. Le problème, c’est qu’ils ne lisent pas ce qu’expliquent les adeptes avec l’intention de comprendre leur point de vue mais avec l’intention de condamner leur démarche, quitte à ergoter sur l'adjectif spontané.

  5. Traitements (Mode plan) VS Conditions (Mode street)

    En y réfléchissant, il me vient à l’esprit que les adeptes de la Programmation spontanée doivent comme moi, penser leurs problématiques en termes de traitements et non en termes de conditions.

    Traitements (Mode plan)

    En adoptant une démarche par traitements, on impose le tempo, on domine la problématique et on sait ce que l’on doit faire. On structure mentalement le programme sans même s’en rendre compte et la programmation s’impose à l’évidence.

    Doloop :

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

    Penser en termes de traitements, c’est voir le bas d’en haut, c’est mettre son cerveau en mode plan « Google Maps » (ou mode satellite) et se donner la possibilité de zoomer/dézoomer.

    Ces capacités à se situer dans l’espace et même dans l’espace-temps, s’acquièrent beaucoup par la pratique sportive. En athlétisme par exemple, que j’ai pratiqué au plus haut niveau (3.000 steeple), la compétition apprend à gérer mentalement la distance, le chronomètre, l’adversaire, les obstacles, la stratégie, l’opportunité, l’effort.

    Dans son blog, autran a publié un billet sur le sujet : Judo et développement même combat ?

    Pour ma part, le sujet m’a inspiré ce billet : II-2.4. PRINCIPES PSYCHOLOGIQUES : Principes de la Running attitude

    Conditions (Mode street)

    À l’inverse, une démarche par conditions situe la problématique en position dominante et cela explique cette peur de l’inconnu, ce recours à des béquilles, cette inquiétude d’avancer en terrain miné.

    Penser en termes de conditions, c’est mettre son cerveau en mode street et avancer à vue.

    Anecdote :

    1972-73 : Adhérent à l’ADELI, je reçois une invitation à une conférence qui prévoit une intervention concernant une méthode dite « la méthode du poisson ».

    L’intervenant nous explique que sur la route des vacances il a subitement assimilé son itinéraire à un ordinogramme (on disait comme ça à l’époque). En approfondissant le concept, il en est venu à tracer sur le papier une route en forme de poisson. La queue du poisson correspondait d’un côté aux initialisations et de l'autre aux statistiques. La bouche du poisson correspondait au traitement de tous les items. Le corps du poisson était constitué de lignes et de boucles. Les espaces entre chaque intersection correspondaient aux traitements.

    Pendant son discours j’ai transcrit tout son exposé en LCP. À la fin de son intervention, invitant l’auditoire à poser des questions, je me suis manifesté. Je suis allé à côté du paperboard où était dessiné son poisson. J’ai mimé le geste de prendre les deux côtés de la queue du poisson, j’ai écarté verticalement mes mains et coller le résultat imaginaire sur le paperboard.

    J’ai affiché une feuille vierge sur le paperboard et en deux minutes j’y ai dessiné mon algorigramme LCP correspondant à son poisson, les deux parties de la queue de son poisson sont devenues les D-PROG et F-PROG de mon algorigramme LCP. Ses « arrêtes » sont devenues des structures itératives ou alternatives. J’ai terminé mon intervention en disant que ça s’appelait la méthode LCP, que ça existait depuis 1970 et que nous devons cette méthode à l’ingénieur de la Bull Jean-Dominique Warnier.

    Je n’ai plus jamais entendu parler de la méthode du poisson.

    C’était juste un aparté à propos du Mode Street que j’ai évoqué, histoire de vous amuser un peu.

    10 ans plus tard, j’ai vécu le même genre d’anecdote avec un professionnel qui nous enseignait la « Programmation Structurée ». À la fin de son cours, en moins de cinq minutes, je lui ai transformé en algorigramme LCP son « arbre programmatique » qu’il avait mis une heure à construire. Il n’a rien compris. Toujours dans sa démarche par conditions, il a juste bredouillé « oui mais si… ».
  6. Mise en page VS Commentaires

    Citation Envoyé par Doloop Voir le message
    Le programmeur qui se perd dans son propre programme, c'est qu'il n'a pas assez programmé ou alors qu’il s'est trompé d'orientation.

    Se passer de commentaires 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. Les commentaires, ça peut toujours se rajouter ultérieurement une fois le programme achevé.

    Un programme qui emploie des noms de variables, de sous-programmes et de fonctions significatifs contient plus d'informations que nécessaire, c'est comme pour le Port-Salut, c'est marqué dessus.
    Discussion : Une mise à jour 0,1 pour 0,n (Forum COBOL)

    Les 26 et 27/11/2019, Obelix84, coboliste de 1968 à 1998, postait deux programmes COBOL avec cette question :

    • « Dites-moi ce que vous pensez de mon code et si mes techniques vieilles de 30 ans sont encore d'actualité et ce qu'il me faudrait améliorer pour être crédible de nos jours comme développeur. »

    Je revisite dans cette discussion les deux programmes COBOL proposés par Obelix84.

    Nos deux versions mettent en évidence la différence entre deux démarches de programmation, l’originale d’Obelix84 privilégiant le fond (commentaires sans mise en page) et ma version privilégiant la forme (mise en page sans commentaires). Le langage COBOL importe peu, il suffit de parcourir les deux versions pour comprendre le message.

    On dit que le COBOL est verbeux et dans ses programmes, il y a presqu’autant de commentaires que de COBOL. Le COBOL est lui-même du commentaire. En surajoutant des commentaires, on ne voit plus le COBOL. Tels qu’ils sont, je ne peux pas lire ses programmes. Ils sont certes conçus pour tourner mais pas pour être lus, donc pas pour être maintenus. Enfin, c'est mon ressenti. Cette programmation à tiroirs PERFORM imbriqués est franchement dissuasive. J’ai l’impression d’entendre sans arrêt mon GPS me dire : « Faites demi-tour ». On devrait pouvoir lire un programme sans avoir besoin d’un GPS, non ? L’intention est claire : ne pas recourir au GO TO, soit disant responsable de tous les maux. Mais un PERFORM, c’est deux GO TO. On perd finalement en lisibilité ce que l’on croit gagner en sécurité. Son programme APP01P0 prévoit un trace ; cela révèle donc le besoin de parer une certaine difficulté à maitriser sa complexité.

    Pour comprendre et réécrire ses programmes, j’ai commencé par supprimer tous les commentaires, tous les numéros de ligne, puis j’ai remplacé certains PERFORM par leur contenu. Ouf ! On y voit plus clair.

    J’aime bien lire un programme directement via son langage source, sans être pollué par des commentaires envahissants. Je préfère consacrer du temps à de la mise en page plutôt qu’à rédiger des commentaires.

    PS : Réhabiliter l’instruction GO TO, ne signifie pas pour autant, bannir l’instruction PERFORM. Je vois au moins trois cas intéressants de son utilisation :

    1. Limiter le nombre de lectures/écritures. Une instruction WRITE générait un nombre d’instructions assembleur très important. Dans les années 70, cela avait une importance énorme et il était plus intéressant de faire appel à un PERFORM de WRITE que d’utiliser plusieurs fois l’instruction WRITE.

    2. Programmer des traitements itératifs.

      Ayant utilisé un langage à base de SQL ne proposant pas d’équivalent de l’instruction PERFORM, cela m’a obligé à trouver une parade à base de boucle FOR agrémentée d’un aiguillage. Concrètement, j’ai dû programmer l’impression d’un document administratif comptable, genre feuille de paie, qui devait renseigner des montants Hors Taxes et/ou TTC en chiffres et en libellés. On n’imagine pas la complexité, entre-autre orthographique, de traduire des sommes chiffrées en libellés. Limité en nombre d’instructions par le compilateur (environ 3.000), il m’a fallu faire preuve d’ingéniosité. C’est à cette occasion que j’ai miraculeusement découvert l’instruction PRINT FILE. Ha, mes amis, quel bonheur que cette instruction ! Une seule petite instruction permet d’imprimer les données fixes d’un état sous la forme d’un formulaire et il ne reste plus qu’à imprimer les données variables par-dessus. Fabuleux !

      Discussion [ISQL-ace] De l’instruction « PRINT FILE » et de l’impression de formulaire en fond de page recto et/ou verso.

    3. Toujours dans les seventies, les programmes trop conséquents devaient être segmentés pour pouvoir s’exécuter. Chaque segment était appelé par un PERFORM. Mon premier programme COBOL dit à l’époque « conversationnel » faisait plus de 8.000 lignes. Les ingénieurs système nous avaient concocté des méta-instructions spécifiques pour utiliser les TTY ayant fait leur apparition, bientôt remplacées par les premiers écrans. Mon programme était à lui seul un SGBD, il sauvegardait les transactions dans un journal Before et un journal After. C’était les ingénieurs de la Bull qui m’avait initié à cette façon de procéder. Ma Base de Données se limitait à un seul fichier séquentiel indexé mais à l’époque, le concept de BDD n’existait pas encore.

      L’AFPA préconisait une méthodologie de programmation pour ce genre de programme transactionnel. Les transactions se géraient à l’aide d’une matrice pilotée par une ou deux centaines d’instructions. Chaque transaction constituait un sous-programme défini en segment.

    Mise en page

    37 ans de développement de 1971 à 2007. De 1991 à 2007 : 2 Bases de Données, 2.157 programmes (états + écrans), 2.133.636 lignes de codes sans une seule ligne de commentaire.

    Ce sont les détracteurs reprochant aux adeptes de ne pas commenter leur code qui m’ont interpellé sur le sujet. À dire vrai, commenter mon code ne m’a même jamais effleuré l’esprit. Cependant, je lis mon code aussi facilement que je lis un livre ou un journal, indépendamment de la date à laquelle je l’ai écrit. Et n’importe quel autre développeur découvrant mes développements est capable de les lire, de les comprendre et d’intervenir si nécessaire.

    Alors, comment est-ce possible ? Quatre composants du programme sont à considérer :

    • Le nommage

      Billet APL-AML I-2.2.1. Règles de nommage

      Il doit être simple et explicite. Tous les nommages sont concernés, les tables, les attributs, les variables, etc.

    • La mise en page

      Billet APL-AML I-2.2.2. Règles de développement

      Mettre en page ses programmes, c’est faciliter la compréhension du code, c’est donner au lecteur l’envie et les moyens de comprendre de lui-même. Il s'agit donc de s'investir sur la forme, l'esthétique, la présentation, la lisibilité, plutôt que sur le fond, les astuces de programmation.

      Tous les programmes étant construits d'après la même architecture, il suffit à une tierce personne de saisir le fil conducteur, de comprendre la logique qui régit l'un des programmes de l'application pour qu'elle « décode » tous les autres sans difficulté. C’est la valeur ajoutée d’un fil d’Ariane (ergonomie).

    • Le codage

      Codage simple, indenté, une instruction par ligne, en privilégiant la lisibilité de façon à éviter tout commentaire. Selon le langage utilisé, certaines clauses obligatoires peuvent servir de pseudo-commentaires, d’éléments de mise en page.

      La structure du programme respecte la démarche LCP : « Penser hiérarchiquement par traitements, autrement dit : raisonner du plus global vers le plus détaillé, par décompositions hiérarchiques successives sur la base des actions et non sur celle des conditions ».

      Billet APL-AML I-2.2.3. Méthodologie de programmation LCP

    • La documentation

      Par documentation, il faut comprendre tout ce qui est utile à la compréhension du programme en tant que fonctionnalité : son objet, ses spécificités, son utilisation informatique et administrative. L'objectif est de rendre le programme aussi lisible qu'un document écrit afin d'éviter le recours à tout dossier d’analyse ou de programmation, notamment à un logigramme. Cela suppose d’avoir des capacités de synthèse et des qualités rédactionnelles.

      Le programme est un tout qui doit se suffire à lui-même pour être compris, maintenu et être réinventé si nécessaire. Le code source doit permettre de recréer éventuellement le logigramme.

    Les lecteurs peuvent parcourir cette discussion à laquelle j’ai participé (Invité) et qui abordent le sujet :

    • Documentation sur la documentation (Forum ALM)

      Extrait :

      • Bonnes pratique de programmation
      • Règles de mise en page des programmes

      Rien n'est plus décevant, angoissant, déprimant que d'intervenir dans un programme sans personnalité, sans repères, sans la moindre trame décelable, susceptible d'en guider la lecture. Certains artifices de forme ne sont pas à négliger. WINDEV, Delphi, les éditeurs utilisent la couleur pour distinguer instructions, données et variables. Dans le même esprit, sous UNIX, le seul fait d'utiliser des majuscules pour les instructions et des minuscules pour les données ou variables améliore considérablement la lecture des programmes (le compilateur Informix traite indifféremment les majuscules et les minuscules). En rendant les instructions suffisamment compréhensibles, les traitements se passent de commentaires. En résumé, un programme est un tout, pas seulement un cocktail de codes commentés, mais un véritable document lisible, digeste qui se suffit à lui-même.

    Commentaires

    Billet blog Petite étude du commentaire

    Ajouter, voire surajouter des commentaires, c’est bisser le code par du pseudocode, c’est admettre implicitement que sa programmation n’est pas nativement compréhensible, pour soi-même et pour les autres.

    Le code doit se suffire à lui-même pour être compris. Le commenter, c’est du texte à concevoir et à gérer ; c’est imposer une charge mentale de traduction, d’interprétation.

    ErwanVDF :

    • « En ce qui concerne les commentaires, j'ai appris à m'en passer au fur et à mesure que mon "style d'écriture" devenait plus limpide. Un code bien écrit me parait parler de lui-même, et est en tout cas bien plus lisible que les torchons bourrés de commentaires que j'ai l'habitude de voir... »

    Doloop :

    • « Le nommage sous toutes ses formes (tables, attributs, programmes, shells, etc.) constitue déjà du commentaire. »

    J’invite les lecteurs à parcourir ces discussions auxquelles j’ai participé (Invité) et qui abordent le nommage :

    • Choisir de créer ou de ne pas créer une table de références (Forum ALM)

      Citation Envoyé par martinbrait Voir le message
      Prenons la table t_pers_prs, d'état civil suivante :

      kn_prs(pk),
      t_matricule(ak),
      t_nom,t_prenom,
      t_sexe,
      d_datenaiss,
      t_villnaiss

      …/…
      Citation Envoyé par Invité Voir le message
      Quelques bonnes pratiques personnelles

      Pour commencer, je trouve tes noms de table et de données pas simples.

      Nom de table :

      Il devrait être court (2-5 caractères), simple, pertinent alors qu’il est composé de trois arguments "t", "_pers" et "_prs". La norme SQL est de préfixer les noms de données du nom de leur table. Donc, autant faire court car on va les utiliser dans toute l’application (requêtes SQL). Cela se faisait déjà en COBOL dans les années 70, les fichiers étaient identifiés dans le programme et dans le shell par une étiquette logique et les données étaient préfixées de leur étiquette logique.

      …/…

      Noms de données :

      Dans ta table, il ne devrait y avoir que des noms de données pertinents.

      kn_prs(pk) : je ne comprends pas le préfixe « kn_ », ni le nom « prs », ni la parenthèse « (pk) ». Il s’agit sans doute d’un code pivot « n_prs », identifiant d’une autre table « pk ».

      t_villnaiss : Pourquoi « vill » et non ville ? Pour gagner un caractère ?

      En fait, il y a plusieurs informations concernant la naissance. Il serait pertinent de les suffixer par « _naiss ».

      Tous tes noms de données préfixés « t_ » n’ont pas à être préfixés.

      À l'exception des quatre lettres "C" pour Code, "T" pour Type, "N" pour Numéro et "L" pour Libellé, on évite les abréviations.

      …/…
    • Modélisation des tables et des vues : monde physique vs monde logique (Forum ALM)

      Je revisite dans cette discussion une requête SQL postée qui montre l’importance des nommages.

      Extrait :

      Ces petites statistiques (Word) révèlent que ma façon de travailler réduit de presque la moitié le nombre de caractères saisis. Mais le plus important - difficilement quantifiable - c’est l’absence de charge mentale liée à ma méthode de nommage.

      Saisie deux fois plus importante, préfixes, trigramme, suffixes, alias, renommage de noms concaténés mais avec initiales majuscules pour réduire le nombre de caractères :

      • cd.cdt_id_diplome_ensfea renommé cdtIdDiplomeEnsfea

        et parfois différents de l’original

      • d.dpl_code renommé cdtCodeDiplomeEnsfea

      … sont autant de sollicitations insidieuses qui se traduisent par une charge mentale réductrice de performance.

Spécificités

Utilisé à propos d’un programme, on peut penser que la compréhension du mot commentaire ne peut pas être ambigüe, et bien si ! Il peut signifier une information décryptant une séquence de code, comme il peut signifier une information caractérisant le programme lui-même. Dans ce dernier cas, on parle plutôt de spécificités.

Privilégier une mise en page à du commentaire, n’exclue pas, selon le contexte, de commenter son code si nécessaire. Rédiger les spécificités du programme dans le programme lui-même va dans le sens du principe RAD qui dit :

« Il faut faire disparaître la notion de dossier de programmation, tout en améliorant réellement les conditions de maintenance. »



■ Conclusion

Ces quelques termes et expressions étant clarifiés, il n’est pas certain que pour tous les adeptes, l’expression « programmation spontanée » recouvre la même réalité. Quant-aux détracteurs, il n’est pas sûr que la distinction entre « programmation spontanée » et « programmation improvisée » fasse évoluer leurs réactions. Depuis 17 ans que la discussion est active, aucun ne s’est interrogé, aucun n’a jamais esquissé la moindre curiosité susceptible de dynamiser positivement le débat. Prisonniers de leurs dogmes éducatifs, les détracteurs ne savent qu’incriminer l’idée fausse qu’ils se sont faite de la programmation spontanée. Les adeptes avaient déjà parfaitement analysé le concept mais ils se sont heurtés à un manque d’ouverture d’esprit évident de leur part.

« Esprit d'ouverture, partage et transmission des savoir-faire », ces valeurs de tradition compagnonnique, sont les mêmes que celles de DVP.

Les rapports humains des Compagnons entre eux sont basés sur l'égalité (le tutoiement est utilisé pour se parler, quel que soit le rang), le respect, l'entraide et l'échange de connaissances. Entre informaticiens, sans que cela soit une règle, c’est vrai que l’on se tutoie plutôt facilement, naturellement même, pourrait-on dire. Pour l’esprit d’ouverture, par contre, cette discussion n’est pas vraiment probante.

En nous interpellant, Doloop nous faisait part de son expérience et pensait pouvoir échanger sur cette expérience.

L'expérience est la connaissance acquise à travers l'interaction avec l'environnement. C’est un enchaînement d'événements dont on peut tirer une leçon. C’est l'ensemble des savoirs que l’on acquiert par la pratique et non seulement par un enseignement formel. La connaissance issue de l'expérience s'oppose à celle qui relève d'une élaboration théorique.

On enrichit son expérience en pillant le meilleur de ce que font les autres, en s’interrogeant, en réfléchissant, en pensant par soi-même, en cherchant à comprendre, en trouvant des réponses à son questionnement, en exploitant ses acquis, en s’améliorant continuellement, en créant de la valeur ajoutée. Notre expérience façonne notre démarche de développement. Elle rend notre programmation inspirante, limpide, intéressante.

Merci aux intervenants auxquels j’ai emprunté certaines argumentations : Doloop, ErwanVDF, etc.

Veuillez m’excuser de vous avoir imposé tout ce baratin anticonformiste. Je m’étais pourtant juré de ne plus intervenir dans ces discussions où la bien-pensance veille à ce que chacun traverse respectueusement dans les clous.

Je pensais avoir épuisé le sujet mais j’arrive encore à trouver quelque chose à raconter. Bon ! Il y a nécessairement quelques redites mais le sujet méritait bien une petite réflexion… qui donnera bien sûr du grain à moudre à certains, à n’en pas douter.

Cela dit, avant de poster vos réactions, vous avez le droit de faire comme moi :

  • travailler vos textes d’abord sous Word pour la mise en forme et l’orthographe,
  • éditer votre version Word dans un billet de blog que vous conservez à l’état de publication « Ébauche »,
  • copier/coller la version éditée du billet dans une réponse à la discussion,
  • et titrer votre réponse.

Du travail de professionnel, quoi !

Bien à vous !
1. APL-AML

I-0.1. SYNOPSIS
I-0.2. SOMMAIRE

2. FORUMS

I-0.0. SOMMAIRE de la FAQ
I-0.1. SOMMAIRE « Contributions aux forums »
I-0.2. SOMMAIRE « Synthèses de discussions »



Discussion : Qui pratique la programmation spontanée ?

▲ I-1.1.1. Doloop
► I-1.1.2. Adeptes VS Détracteurs
▼ I-1.1.3. Adeptes

Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Viadeo Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Twitter Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Google Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Facebook Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Digg Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Delicious Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog MySpace Envoyer le billet « I-1.1.2. Adeptes VS Détracteurs » dans le blog Yahoo

Mis à jour 14/04/2021 à 09h52 par APL-AML

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

Commentaires