Programmer comme formation d’une théorie (1985)

• « Programming as Theory Building » de Peter Naur considère la programmation non comme une activité de production de texte de programme, mais comme une activité par laquelle le programmeur forme une théorie du problème et de sa solution.
• Ici, la « théorie » n’est ni une simple proposition abstraite ni une explication de conception documentée.
  • C’est la capacité de comprendre le sens d’un problème du monde réel,
  • d’expliquer comment la structure du programme correspond à cette réalité,
  • de justifier pourquoi il a été conçu ainsi,
  • et de juger comment intégrer de nouvelles exigences dans la structure existante.
• Ainsi, le savoir essentiel d’un programme n’est pas entièrement contenu dans le code ou la documentation, mais dans la tête des programmeurs qui comprennent ce programme.

Programmation et connaissance

• Naur voit la programmation comme l’activité consistant à faire correspondre des activités du monde réel à des manipulations formelles de symboles qu’un ordinateur peut exécuter.
• Dans cette perspective, la modification d’un programme fait aussi partie de la programmation.
  • Parce que lorsque les activités du monde réel changent, le programme doit changer lui aussi.
• L’essence de la programmation n’est pas le document ou le code produit, mais un certain savoir accumulé par les programmeurs.
• La documentation est importante, mais secondaire.
  • Elle ne peut pas remplacer complètement la théorie.
  • Elle est plutôt un outil qui aide à former cette théorie.

Cas 1 : transfert d’un compilateur et échec

• Le groupe A a créé un compilateur pour le langage L.
• Le groupe B a reçu le code du compilateur de A, sa documentation et ses conseils afin de créer un compilateur pour le langage étendu L + M.
• Bien que le code et la documentation aient été suffisamment fournis, B n’a pas su exploiter la force de la structure existante dans certaines décisions de conception et a proposé des solutions de type patch.
• A a immédiatement identifié le problème et a proposé, dans le cadre de la structure existante, une solution plus simple et plus naturelle.
• Le point essentiel de ce cas :
  • Le texte du programme et la documentation ne suffisent pas à transmettre la théorie profonde de la conception.
  • Le « pourquoi » de la conception existante et la manière de l’étendre ne se transmettent pas suffisamment par la seule documentation.
• Par la suite, lorsque d’autres programmeurs, sans l’accompagnement de A, ont modifié le compilateur, la structure forte d’origine a progressivement été affaiblie par des ajouts informes.
• Cela montre les limites du texte du programme et de la documentation pour préserver la théorie centrale de conception.

Cas 2 : système temps réel à grande échelle

• Un cas portant sur un système temps réel industriel d’environ 200 000 lignes est présenté.
• Les programmeurs chargés de l’installation et du diagnostic des défauts étaient étroitement liés au système depuis le début de sa conception et depuis longtemps.
• Pour diagnostiquer les défauts, ils s’appuyaient principalement sur leur compréhension immédiate du système et sur le code annoté.
• En revanche, les programmeurs d’exploitation externes, pourtant formés et munis de documentation, rencontraient régulièrement des difficultés.
• Les programmeurs expérimentés du constructeur résolvaient facilement ces problèmes.
• Conclusion :
  • La maintenance et la modification des grands programmes dépendent essentiellement du savoir détenu par les personnes qui sont restées longtemps liées au programme.
  • Les explications documentées ne peuvent pas remplacer complètement ce savoir.

Le concept de « théorie » chez Ryle

• Naur reprend le concept de théorie chez Gilbert Ryle.
• Avoir une théorie ne signifie pas simplement connaître des propositions.
  • C’est savoir faire quelque chose,
  • pouvoir l’expliquer,
  • répondre à des questions,
  • et justifier son propre jugement.
• Une activité intelligente ne se réduit pas nécessairement à l’application de règles.
  • Parce que le fait même de suivre des règles doit lui aussi être accompli intelligemment.
  • Et si l’on exige encore une autre règle pour expliquer comment suivre une règle, on tombe dans une régression à l’infini.
• Par conséquent, l’activité intellectuelle n’est pas une simple exécution de règles ; elle inclut la capacité à percevoir des similitudes entre situations et à y répondre de manière appropriée.

Une théorie ne peut pas être entièrement exprimée sous forme de règles

• Une personne qui possède une théorie reconnaît des similitudes significatives entre diverses situations du monde réel.
• Mais ces similitudes sont difficiles à exprimer complètement à l’aide de critères ou de règles clairs.
• Exemples :
  • la ressemblance entre des visages
  • la similarité d’une mélodie
  • la similarité du goût d’un vin
• De même, en programmation, il est difficile de réduire à de simples règles la manière dont une nouvelle exigence ressemble à une structure existante et l’endroit où elle doit être intégrée.
• C’est là le cœur du savoir tacite.

La théorie qu’un programmeur doit posséder

• Un programmeur qui possède la théorie d’un programme doit pouvoir faire les choses suivantes.

1. Être capable d’expliquer la correspondance entre le monde réel et le programme

• Il doit pouvoir expliquer à quelles activités ou à quels concepts du monde réel correspond chaque partie du programme.
• Inversement, il doit aussi pouvoir expliquer comment une activité du monde réel est représentée dans le programme.
• Pour juger de ce qui est pertinent ou non, une compréhension de l’ensemble du monde réel est nécessaire.

2. Être capable de justifier pourquoi le programme est ainsi

• Il doit pouvoir expliquer pourquoi la structure du programme et les détails de son implémentation ont été conçus de cette manière.
• Cette justification peut mobiliser des règles, des raisonnements, des principes de conception ou des estimations quantitatives.
• Mais, en dernière analyse, le choix du principe à appliquer dépend de l’intuition directe du programmeur.

3. Être capable de répondre de manière constructive à de nouvelles demandes de modification

• Il doit pouvoir reconnaître à quelles fonctions ou structures du programme existant ressemblent de nouvelles exigences.
• À partir de cette similarité, il doit pouvoir concevoir la modification de sorte qu’elle s’intègre naturellement à la théorie existante.
• Cette capacité est difficile à remplacer par de simples procédures documentées.

Modification des programmes et coût

• Le logiciel est inévitablement modifié.
  • Parce que de nouvelles exigences apparaissent au fil de l’usage,
  • et parce que les conditions du monde réel changent elles aussi.
• On pense souvent qu’il est moins coûteux de modifier un programme existant que d’en créer un nouveau.
• Mais du point de vue de Naur, cette attente n’est pas toujours fondée.
• Le coût d’une modification de programme n’est pas le coût de l’édition du texte.
  • Le coût principal réside dans la compréhension de la théorie du programme existant
  • et dans l’intégration des nouvelles exigences à l’intérieur de cette théorie.
• Par conséquent, le simple fait que le code soit un texte facile à éditer ne permet pas d’affirmer que sa modification est facile.

Les limites de la flexibilité

• L’idée qu’il faudrait intégrer à l’avance de la flexibilité dans un programme pour faire face aux changements futurs n’est valable que partiellement.
• La flexibilité n’est pas gratuite.
  • Il faut décider à quelles situations futures se préparer,
  • concevoir les paramètres et les structures,
  • et supporter les coûts d’implémentation, de test et d’explication.
• Son utilité dépend d’événements futurs incertains.
• La flexibilité ne peut donc pas constituer une solution générale au changement.
• L’important n’est pas d’inscrire à l’avance une structure adaptée à tous les changements possibles, mais d’avoir la capacité de juger correctement, à partir de la théorie du programme, lorsque le changement survient.

Bonnes et mauvaises modifications

• Une même modification satisfaisant le même comportement externe peut être implémentée de plusieurs façons.
• En apparence, elles peuvent toutes sembler correctes.
• Mais du point de vue de la théorie du programme, la différence est considérable.
  • Certaines modifications prolongent naturellement la théorie existante.
  • D’autres fonctionnent comme des rustines ajoutées sur la structure existante.
• Si ce second type de modification se répète, le programme finit peu à peu en patchwork.
• La viabilité à long terme d’un programme dépend de la profondeur avec laquelle chaque modification s’enracine dans la théorie existante.

Vie, mort et résurrection d’un programme

Vie d’un programme

• Un programme est vivant lorsque les programmeurs qui possèdent sa théorie en gardent encore activement le contrôle.
• Ils peuvent répondre intelligemment aux demandes de modification.

Mort d’un programme

• Lorsqu’une équipe qui possède la théorie d’un programme se dissout, le programme meurt.
• Un programme mort peut encore s’exécuter et produire des résultats utiles.
• Mais sa mort se révèle lorsqu’il devient incapable de répondre correctement aux demandes de modification.

Résurrection d’un programme

• Il s’agit de la tentative d’une nouvelle équipe de reconstruire la théorie du programme existant.
• Naur estime que cela est impossible au sens strict.
• Parce qu’avec la seule documentation et le seul code, on ne peut pas restaurer intégralement la théorie qu’avait l’équipe d’origine.
• Même lorsqu’une résurrection est possible, elle est coûteuse et difficile, et il est très probable qu’elle produise une théorie différente de l’originale.
• Dans certains cas, il peut être préférable et moins coûteux pour une nouvelle équipe de résoudre à nouveau le problème plutôt que de sauver le code existant.

Critique des méthodologies

• Naur définit les méthodologies de programmation comme des « ensembles de règles qui déterminent dans quel ordre et quel travail le programmeur doit accomplir ».
• Du point de vue de la formation d’une théorie, une méthodologie au sens strict ne saisit pas l’essence de la programmation.
• Pourquoi :
  • La formation d’une théorie n’a pas d’ordre prédéfini.
  • Une théorie n’est pas, par essence, une combinaison linéaire de parties.
  • Une notation ou un format documentaire peuvent aider à former une théorie, mais ne sont pas la théorie elle-même.
• Naur en conclut qu’il n’existe pas de méthode universellement correcte pour l’activité première de la programmation.

Cela ne signifie pas que les méthodologies sont totalement sans valeur

• Ce que Naur rejette, c’est la méthodologie en tant que procédure garantissant mécaniquement une bonne conception.
• Les méthodologies, techniques de conception, notations et techniques de vérification peuvent avoir une valeur pédagogique.
• Un programmeur familier de bons exemples, de principes de structuration et de techniques de vérification a davantage de chances de former une meilleure théorie.
• Mais la décision de savoir quelle technique appliquer, quand et dans quel ordre, doit être laissée au jugement du programmeur qui comprend le problème réel.

Le statut du programmeur

• Si l’on considère la programmation comme une production industrielle, le programmeur est traité comme une pièce interchangeable.
• C’est la vision selon laquelle, en suivant des procédures et des règles, n’importe qui peut produire le même résultat.
• Naur rejette cette vision.
• Si le produit essentiel d’un programme est la théorie que possède le programmeur, alors celui-ci n’est pas un travailleur facilement remplaçable.
• Le programmeur est plus proche d’un professionnel chargé de développer et d’administrer de manière responsable l’ensemble de l’activité qui inclut l’ordinateur.
• Il faut donc accorder au programmeur un statut durable et des responsabilités.
• La formation doit elle aussi aller au-delà de la simple grammaire, de la notation ou des techniques de traitement de données, et viser à développer la capacité de former des théories.

La métaphore en XP et la formation d’une théorie

• La « métaphore » de XP s’explique bien à travers la perspective de Naur sur la formation d’une théorie.
• Une bonne métaphore aide l’équipe à faire des hypothèses similaires sur la structure du programme.
• Exemples :
  • comprendre le programme comme une « chaîne d’assemblage » ;
  • comprendre le programme comme un « restaurant ».
• Une bonne métaphore n’est pas une simple image.
  • Elle aide les concepteurs à juger quelle structure attendre,
  • où ajouter le nouveau code,
  • et comment l’articuler avec le code écrit par d’autres.
• Plus l’équipe est nombreuse et le travail parallèle important, plus la valeur d’une métaphore partagée augmente.
• Sans théorie commune, chaque programmeur construit sa propre théorie, et le système devient progressivement incohérent et complexe.

Le rôle de la documentation

• La documentation a du mal à suivre complètement l’état actuel d’un programme.
• Cela ne signifie pas pour autant qu’elle soit inutile.
• Son but n’est pas de tout enregistrer, mais d’aider le programmeur suivant à former une théorie adéquate.
• Une bonne documentation stimule la mémoire et l’expérience du lecteur, et ouvre la bonne trajectoire de réflexion.
• Ce type de documentation survit plus longtemps qu’un document se contentant de lister les classes, fonctions et modules existants.

Composition d’un bon document de conception

• Un concepteur expérimenté commence généralement un document par les éléments suivants :
  • la métaphore centrale
  • une explication de l’objectif des composants principaux
  • un schéma des interactions essentielles entre les principaux composants
• Ces trois éléments aident grandement l’équipe suivante à former une théorie de la conception.
• Le code source lui-même est aussi un moyen de transmettre la théorie.
  • un nommage cohérent
  • une structure simple
  • des motifs prévisibles
  • une réduction au minimum des exceptions inutiles
• Une grande partie de ce qu’on appelle le « clean code » est liée à la facilité avec laquelle le lecteur peut former une théorie cohérente du système.