La programmation en tant que construction de la théorie, par Peter Naur

Pourquoi il n'est pas possible d'échanger les programmeurs : la programmation en tant que construction de la théorie, par Peter Naur

Pourquoi les programmeurs ne sont pas interchangeables ? Voici l'essentiel d'un magnifique article de 1985 de Peter Naur qui fournit un argument convaincant sur les raisons pour lesquelles les programmeurs ne sont pas fongibles. On ne peut pas échanger les programmeurs comme les rouages d'une machine, parce que les programmeurs ne sont pas des producteurs de gadgets. Ils apportent une valeur ajoutée principalement grâce à leur compréhension des systèmes complexes, compréhension qu'il est difficile d'acquérir avec une documentation, aussi complète soit-elle.

Citation:

Dans son essai classique de 1985 intitulé "Programming as Theory Building" (la programmation en tant que construction de la théorie), Peter Naur affirme qu'un programme n'est pas son code source. Un programme est une construction mentale partagée (il utilise le mot théorie) qui vit dans l'esprit des personnes qui y travaillent. Si vous perdez les personnes, vous perdez le programme. Le code n'est qu'une représentation écrite du programme, et il y a des pertes, de sorte qu'il est impossible de reconstruire un programme à partir de son code.

Introduction

La présente discussion est une contribution à la compréhension de ce qu'est la programmation. Elle suggère que la programmation proprement dite devrait être considérée comme une activité par laquelle les programmeurs forment ou atteignent un certain type de compréhension, une théorie, des questions en jeu. Cette suggestion s'oppose à ce qui semble être une notion plus courante, à savoir que la programmation devrait être considérée comme la production d'un programme et de certains autres textes.

Les points de vue présentés ici trouvent en partie leur origine dans certaines observations de ce qui arrive réellement aux programmes et aux équipes de programmeurs qui s'en occupent, en particulier dans les situations résultant d'exécutions ou de réactions inattendues et peut-être erronées des programmes, ainsi qu'à l'occasion de modifications des programmes. La difficulté d'intégrer de telles observations dans une vision de la programmation axée sur la production suggère que cette vision est trompeuse. Le point de vue de la construction de la théorie est présenté comme une alternative.

Le contexte plus général de la présentation est la conviction qu'il est important d'avoir une bonne compréhension de ce qu'est la programmation. Si notre compréhension est inappropriée, nous ne comprendrons pas les difficultés qui surgissent dans l'activité et nos tentatives pour les surmonter donneront lieu à des conflits et à des frustrations.

Dans la présente discussion, nous commencerons par exposer certaines expériences de base essentielles. Elle sera suivie d'une explication de la théorie de la programmation, appelée "Theory Building View" (point de vue de la construction de la théorie). Les sections suivantes abordent certaines des conséquences du point de vue de la construction de la théorie.

La programmation et les connaissances des programmeurs

J'utiliserai le mot "programmation" pour désigner l'ensemble de l'activité de conception et de mise en œuvre de solutions programmées. Ce qui m'intéresse, c'est de faire correspondre une partie ou un aspect important d'une activité dans le monde réel à la manipulation formelle de symboles qui peut être effectuée par un programme fonctionnant sur un ordinateur. Avec une telle notion, il s'ensuit directement que l'activité de programmation dont je parle doit inclure le développement dans le temps correspondant aux changements qui se produisent dans l'activité du monde réel à laquelle correspond l'exécution du programme, en d'autres termes, les modifications du programme.

Une façon d'exprimer le point principal que je veux faire est que la programmation, dans ce sens, doit principalement être la construction par les programmeurs de connaissances d'un certain type, connaissances considérées comme étant fondamentalement la possession immédiate des programmeurs, toute documentation étant un produit auxiliaire, secondaire.

En toile de fond de l'élaboration plus poussée de ce point de vue dans les sections suivantes, le reste de la présente section décrira une expérience réelle de traitement de grands programmes qui m'a semblé de plus en plus significative au fur et à mesure que je réfléchissais aux problèmes. Dans les deux cas, l'expérience est la mienne ou m'a été communiquée par des personnes ayant un contact direct avec l'activité en question.

Le cas 1 concerne un compilateur. Il a été développé par un groupe A pour un langage L et a très bien fonctionné sur l'ordinateur X. Un autre groupe B a maintenant pour tâche d'écrire un compilateur pour un langage L + M, une modeste extension de L, pour l'ordinateur Y. Le groupe B décide que le compilateur pour L développé par le groupe A sera un bon point de départ pour sa conception, et passe un contrat avec le groupe A selon lequel il bénéficiera d'un soutien sous la forme d'une documentation complète, y compris des textes de programmes annotés et de nombreuses discussions écrites supplémentaires sur la conception, ainsi que de conseils personnels. L'arrangement a été efficace et le groupe B a réussi à développer le compilateur qu'il souhaitait. Dans le présent contexte, la question importante est celle de l'importance des conseils personnels du groupe A sur les questions relatives à la mise en œuvre des extensions M du langage. Pendant la phase de conception, le groupe B a fait des suggestions sur la manière dont les extensions devaient être prises en compte et les a soumises au groupe A pour examen. Dans plusieurs cas importants, il s'est avéré que les solutions suggérées par le groupe B ont été jugées par le groupe A comme n'utilisant pas les facilités qui étaient non seulement inhérentes à la structure du compilateur existant mais qui étaient longuement discutées dans sa documentation, et comme étant plutôt basées sur des ajouts à cette structure sous la forme de correctifs qui détruisaient effectivement sa puissance et sa simplicité. Les membres du groupe A ont été capables de repérer ces cas instantanément et de proposer des solutions simples et efficaces, entièrement encadrées par la structure existante. C'est un exemple qui montre que le texte complet du programme et la documentation supplémentaire ne suffisent pas à transmettre, même au groupe B très motivé, la vision plus profonde de la conception, cette théorie qui est immédiatement présente pour les membres du groupe A.

Dans les années qui ont suivi ces événements, le compilateur développé par le groupe B a été repris par d'autres programmeurs de la même organisation, sans l'aide du groupe A. Les informations obtenues par un membre du groupe A sur le compilateur à la suite de modifications ultérieures après une dizaine d'années ont montré clairement qu'à ce stade ultérieur, la puissante structure d'origine était toujours visible, mais rendue totalement inefficace par des ajouts amorphes de différentes natures. Ainsi, une fois de plus, le texte du programme et sa documentation se sont révélés insuffisants pour véhiculer certaines des idées de conception les plus importantes.

Le cas 2 concerne l'installation et le diagnostic de défaillance d'un grand système en temps réel destiné à surveiller les activités de production industrielle. Le système est commercialisé par son producteur, chaque livraison du système étant adaptée individuellement à son environnement spécifique de capteurs et de dispositifs d'affichage. La taille du programme livré dans chaque installation est de l'ordre de 200 000 lignes. L'expérience pertinente tirée de la manière dont ce type de système est géré concerne le rôle et le mode de travail du groupe de programmeurs chargés de l'installation et de la recherche de pannes. Tout d'abord, ces programmeurs se sont intéressés de près au système à plein temps pendant plusieurs années, depuis la conception du système. Deuxièmement, lorsqu'ils diagnostiquent une erreur, ces programmeurs s'appuient presque exclusivement sur leur connaissance du système et sur le texte annoté du programme, et sont incapables de concevoir une quelconque documentation supplémentaire qui leur serait utile. Troisièmement, d'autres groupes de programmeurs qui sont responsables de l'exploitation d'installations particulières du système et qui reçoivent donc une documentation sur le système et des conseils complets sur son utilisation de la part du personnel du producteur, rencontrent régulièrement des difficultés qui, après consultation du programmeur d'installation et de recherche de pannes du producteur, sont dues à une mauvaise compréhension de la documentation existante, mais qui peuvent être facilement résolues par les programmeurs d'installation et de recherche de pannes.

La conclusion semble inéluctable qu'au moins pour certains types de grands programmes, l'adaptation, la modification et la correction continues des erreurs qu'ils contiennent dépendent essentiellement d'un certain type de connaissances possédées par un groupe de programmeurs qui sont étroitement et continuellement en contact avec eux.

La notion de théorie selon Ryle

Si l'on admet que la programmation doit impliquer, en tant qu'élément essentiel, une accumulation de connaissances de la part des programmeurs, la question suivante est de caractériser plus précisément ces connaissances. Nous examinerons ici la suggestion selon laquelle les connaissances des programmeurs devraient être considérées comme une théorie, au sens de Ryle [1949]. Très brièvement, une personne qui a ou possède une théorie dans ce sens sait comment faire certaines choses et peut en outre soutenir l'action réelle par des explications, des justifications et des réponses à des questions concernant l'activité en question. On peut noter que la notion de théorie de Ryle apparaît comme un exemple de ce que K. Popper [Popper et Eccles, 1977] appelle des objets non incarnés du monde 3 et qu'elle a donc un statut philosophique défendable. Dans la présente section, nous décrirons plus en détail la notion de théorie de Ryle.

Ryle [1949] développe sa notion de théorie dans le cadre de son analyse de la nature de l'activité intellectuelle, en particulier de la manière dont l'activité intellectuelle diffère de l'activité simplement intelligente et la dépasse. Dans un comportement intelligent, la personne fait preuve, non pas d'une connaissance particulière des faits, mais de la capacité de faire certaines choses, telles que faire et apprécier des blagues, parler grammaticalement ou pêcher. Plus particulièrement, la performance intelligente se caractérise en partie par le fait que la personne fait bien les choses, selon certains critères, mais aussi par sa capacité à appliquer les critères de manière à détecter et à corriger les lacunes, à apprendre des exemples des autres, etc. Il convient de noter que cette notion d'intelligence ne repose pas sur l'idée que le comportement intelligent dépend du fait que la personne suit ou adhère à des règles, des prescriptions ou des méthodes. Au contraire, l'acte même d'adhérer à des règles peut être fait plus ou moins intelligemment ; si l'exercice de l'intelligence dépendait de l'adhésion à des règles, il faudrait des règles sur la façon de suivre les règles, et sur la façon de suivre les règles sur l'adhésion aux règles, etc. dans une régression infinie, ce qui est absurde.

Ce qui caractérise l'activité intellectuelle, au-delà de l'activité simplement intelligente, c'est la construction et la possession d'une théorie, la théorie étant entendue comme la connaissance qu'une personne doit posséder non seulement pour faire certaines choses intelligemment, mais aussi pour les expliquer, répondre à des questions à leur sujet, argumenter à leur sujet, etc. Une personne qui a une théorie est prête à s'engager dans de telles activités ; en construisant la théorie, la personne essaie de l'obtenir.

La notion de théorie au sens où nous l'entendons ici s'applique non seulement aux constructions élaborées de domaines de recherche spécialisés, mais également aux activités auxquelles toute personne ayant reçu une éducation participera à certaines occasions. Même des activités peu ambitieuses de la vie quotidienne peuvent donner lieu à une théorisation, par exemple lorsqu'il s'agit de planifier l'emplacement d'un meuble ou la manière de se rendre à un endroit donné en utilisant certains moyens de transport.

La notion de théorie employée ici n'est explicitement pas limitée à ce que l'on peut appeler la partie la plus générale ou la plus abstraite de l'intuition. Par exemple, pour comprendre la théorie de la mécanique de Newton telle qu'elle est comprise ici, il ne suffit pas de comprendre les lois centrales, telles que la force égale la masse multipliée par l'accélération. En outre, comme le décrit plus en détail Kuhn [1970, p. 187 et suivantes], la personne qui possède la théorie doit comprendre la manière dont les lois centrales s'appliquent à certains aspects de la réalité, afin de pouvoir reconnaître et appliquer la théorie à d'autres aspects similaires. Une personne possédant la théorie de la mécanique de Newton doit ainsi comprendre comment elle s'applique aux mouvements des pendules et des planètes, et doit être capable de reconnaître des phénomènes similaires dans le monde, afin d'être en mesure d'utiliser correctement les règles mathématiquement exprimées de la théorie.

La dépendance d'une théorie à l'égard de certains types de similitudes entre des situations et des événements du monde réel explique pourquoi la connaissance détenue par un détenteur de la théorie ne pourrait pas, en principe, être exprimée en termes de règles. En effet, les similitudes en question ne sont pas et ne peuvent pas être exprimées en termes de critères, pas plus que ne peuvent l'être les similitudes de nombreux autres types d'objets, tels que les visages humains, les mélodies ou les goûts du vin.

La théorie à construire par le programmeur

Selon la notion de théorie de Ryle, ce qui doit être construit par le programmeur est une théorie sur la façon dont certaines affaires du monde seront traitées ou soutenues par un programme informatique. Dans le cadre de la programmation du point de vue de la construction de la théorie, la théorie élaborée par les programmeurs prime sur d'autres produits tels que les textes des programmes, la documentation destinée à l'utilisateur et la documentation supplémentaire telle que les spécifications.

En défendant le point de vue de la construction de la théorie, la question fondamentale est de montrer comment les connaissances possédées par le programmeur en vertu de sa théorie transcendent nécessairement, et de manière essentielle, celles qui sont consignées dans les produits documentés. La réponse à cette question est que les connaissances du programmeur transcendent celles figurant dans la documentation dans au moins trois domaines essentiels :

Le programmeur qui possède la théorie du programme peut expliquer comment la solution se rapporte aux affaires du monde qu'elle aide à traiter. Cette explication devra porter sur la manière dont les affaires du monde, tant dans leurs caractéristiques générales que dans leurs détails, sont, d'une certaine manière, transposées dans le texte du programme et dans toute documentation supplémentaire. Le programmeur doit donc être en mesure d'expliquer, pour chaque partie du texte du programme et pour chacune de ses caractéristiques structurelles globales, à quel aspect ou activité du monde il correspond. Inversement, pour tout aspect ou activité du monde, le programmeur est en mesure d'indiquer la manière dont il s'inscrit dans le texte du programme. La plus grande partie des aspects et activités du monde se situera bien sûr en dehors du champ d'application du texte du programme, car elle n'est pas pertinente dans le contexte. Cependant, la décision de considérer une partie du monde comme pertinente ne peut être prise que par quelqu'un qui comprend le monde dans son ensemble. Cette compréhension doit être apportée par le programmeur.

Le programmeur qui possède la théorie du programme peut expliquer pourquoi chaque partie du programme est ce qu'elle est, en d'autres termes, il est capable d'étayer le texte du programme par une sorte de justification. La base finale de la justification est et doit toujours rester la connaissance ou l'estimation directe et intuitive du programmeur. Il en va de même lorsque la justification fait appel au raisonnement, éventuellement à l'application de règles de conception, à des estimations quantitatives, à des comparaisons avec d'autres solutions, etc., l'important étant que le choix des principes et des règles, et la décision qu'ils sont pertinents pour la situation en question, doivent en dernière analyse rester une question de connaissance directe du programmeur.

Le programmeur qui possède la théorie du programme est en mesure de répondre de manière constructive à toute demande de modification du programme afin de soutenir les affaires du monde d'une nouvelle manière. La conception de la meilleure façon d'intégrer une modification dans un programme établi dépend de la perception de la similitude de la nouvelle demande avec les facilités opérationnelles déjà intégrées dans le programme. Le type de similitude qui doit être perçu est une similitude entre des aspects du monde. Il n'a de sens que pour l'agent qui connaît le monde, c'est-à-dire pour le programmeur, et ne peut être réduit à un ensemble limité de critères ou de règles, pour des raisons similaires à celles évoquées plus haut pour lesquelles la justification du programme ne peut être ainsi réduite.

Si la discussion de la présente section présente quelques arguments de base en faveur de l'adoption du point de vue de la construction de la théorie, l'évaluation de cette conception doit tenir compte de la mesure dans laquelle elle peut contribuer à une compréhension cohérente de la programmation et de ses problèmes. Ces questions seront abordées dans les sections suivantes.

Problèmes et coûts des modifications de programmes

L'une des principales raisons pour lesquelles nous avons proposé le point de vue de la construction de la théorie dans la programmation est le désir d'établir une vision de la programmation qui permette de bien comprendre les modifications apportées aux programmes. Cette question sera donc la première à être analysée.

Tout le monde semble s'accorder sur un point : les logiciels seront modifiés. Il arrive invariablement qu'un programme, une fois mis en oeuvre, ne soit perçu que comme une partie de la réponse aux problèmes posés. En outre, l'utilisation même du programme inspirera des idées pour d'autres services utiles que le programme devrait fournir. D'où la nécessité de trouver des moyens de gérer les modifications.

La question des modifications de programme est étroitement liée à celle des coûts de programmation. Face à la nécessité de modifier le mode de fonctionnement du programme, on espère réaliser des économies en apportant des modifications à un texte existant plutôt qu'en écrivant un programme entièrement nouveau.

L'idée qu'il devrait être possible de modifier un programme à faible coût mérite d'être analysée de plus près. Il convient tout d'abord de noter qu'une telle attente ne peut être étayée par une analogie avec les modifications d'autres constructions complexes réalisées par l'homme. Lorsque des modifications sont parfois apportées, par exemple dans le cas de bâtiments, il est bien connu qu'elles sont coûteuses et, en fait, la démolition complète du bâtiment existant suivie d'une nouvelle construction s'avère souvent préférable d'un point de vue économique. Deuxièmement, l'attente de la possibilité de modifications peu coûteuses des programmes est étayée par le fait qu'un programme est un texte contenu dans un support permettant une édition aisée. Pour que ce soutien soit valable, il faut clairement supposer que le coût dominant est celui de la manipulation du texte. Cela correspondrait à la notion de programmation en tant que production de texte. Selon le point de vue de la construction de la théorie, l'ensemble de l'argument est faux. Ce point de vue ne permet pas d'affirmer que des modifications de programme à faible coût sont généralement possibles.

Une autre question étroitement liée est celle de la flexibilité du programme. En incluant la flexibilité dans un programme, nous y intégrons certaines facilités opérationnelles qui ne sont pas immédiatement nécessaires, mais qui sont susceptibles de s'avérer utiles. Ainsi, un programme flexible est capable de faire face à certaines catégories de changements de circonstances externes sans être modifié.

Il est souvent dit que les programmes doivent être conçus de manière à être très flexibles, afin de pouvoir s'adapter facilement à des circonstances changeantes. Ce conseil peut être raisonnable dans la mesure où la flexibilité peut être facilement obtenue. Cependant, la flexibilité ne peut en général être obtenue qu'à un coût substantiel. Chaque élément doit être conçu, y compris les circonstances qu'il doit couvrir et le type de paramètres par lesquels il doit être contrôlé. Il faut ensuite le mettre en œuvre, le tester et le décrire. Ce coût est encouru pour obtenir une caractéristique du programme dont l'utilité dépend entièrement d'événements futurs. Il doit être évident que la flexibilité intégrée des programmes ne répond pas à la demande générale d'adaptation des programmes aux circonstances changeantes du monde.

Lors d'une modification de programme, une solution programmée existante doit être changée afin de répondre à un changement dans l'activité du monde réel à laquelle elle doit correspondre. Ce qui est nécessaire dans une modification, c'est tout d'abord une confrontation de la solution existante avec les exigences requises par la modification souhaitée. Cette confrontation doit permettre de déterminer le degré et le type de similitude entre les capacités de la solution existante et les nouvelles exigences. Cette nécessité de déterminer la similitude fait ressortir l'intérêt du point de vue de la construction de la théorie. En effet, c'est précisément en déterminant la similitude que l'on met en évidence les lacunes de toute conception de la programmation qui ne tient pas compte de l'exigence centrale de la participation directe des personnes qui possèdent les connaissances appropriées. Le fait est que le type de similarité qui doit être reconnu est accessible aux êtres humains qui possèdent la théorie du programme, bien qu'il soit entièrement hors de portée de ce qui peut être déterminé par des règles, puisque même les critères permettant de l'évaluer ne peuvent être formulés. A partir de la connaissance de la similitude entre les nouvelles exigences et celles déjà satisfaites par le programme, le programmeur est en mesure de concevoir le changement du texte du programme nécessaire à la mise en oeuvre de la modification.

Dans un certain sens, il ne peut être question d'une modification de la théorie, mais seulement d'une modification du programme. En effet, une personne possédant la théorie doit déjà être préparée à répondre aux types de questions et de demandes qui peuvent donner lieu à des modifications de programme. Cette observation conduit à la conclusion importante que les problèmes de modification des programmes proviennent du fait que l'on part du principe que la programmation consiste en la production de textes de programmes, au lieu de reconnaître la programmation comme une activité de construction construction de la théorie.

Sur la base de la vision de la construction de la théorie, la dégradation d'un texte de programme à la suite de modifications apportées par des programmeurs qui ne maîtrisent pas la théorie sous-jacente devient compréhensible. En fait, si on la considère simplement comme une modification du texte du programme et du comportement externe de l'exécution, une modification souhaitée donnée peut généralement être réalisée de nombreuses manières différentes, toutes correctes. En même temps, si on les considère par rapport à la théorie du programme, ces façons peuvent sembler très différentes, certaines d'entre elles étant conformes à cette théorie ou l'étendant de manière naturelle, tandis que d'autres peuvent être totalement incompatibles avec cette théorie, ayant peut-être le caractère de correctifs non intégrés sur la partie principale du programme. Cette différence de caractère des divers changements n'a de sens que pour le programmeur qui possède la théorie du programme. En même temps, le caractère des modifications apportées au texte d'un programme est vital pour la viabilité à long terme du programme. Pour qu'un programme conserve sa qualité, il est impératif que chaque modification soit fermement ancrée dans sa théorie. En effet, la notion même de qualités telles que la simplicité et une bonne structure ne peut être comprise qu'en termes de théorie du programme, puisqu'elle caractérise le texte du programme actuel par rapport à d'autres textes de programme qui auraient pu être écrits pour obtenir le même comportement d'exécution, mais qui n'existent qu'en tant que possibilités dans l'esprit du programmeur.

La vie, la mort et la renaissance des programmes

L'une des principales affirmations de la construction de la théorie dans la programmation est qu'une partie essentielle de tout programme, sa théorie, est quelque chose qui ne peut être exprimée, mais qui est inextricablement liée aux êtres humains. Il s'ensuit qu'en décrivant l'état du programme, il est important d'indiquer dans quelle mesure les programmeurs ayant sa théorie restent en charge de celle-ci. Pour souligner cette circonstance, on peut étendre la notion de construction du programme par les notions de vie, de mort et de renaissance du programme. La construction du programme est la même que la construction de sa théorie par et dans l'équipe de programmeurs. Pendant la durée de vie du programme, une équipe de programmeurs possédant sa théorie reste en contrôle actif du programme, et en particulier conserve le contrôle de toutes les modifications. La mort d'un programme survient lorsque l'équipe de programmeurs possédant sa théorie est dissoute. Un programme mort peut continuer à être utilisé pour l'exécution dans un ordinateur et à produire des résultats utiles. L'état de mort devient visible lorsque les demandes de modification du programme ne peuvent être satisfaites de manière intelligente. La renaissance d'un programme est la reconstruction de sa théorie par une nouvelle équipe de programmeurs.

La prolongation de la durée de vie d'un programme selon ces notions dépend de la reprise de la théorie du programme par de nouvelles générations de programmeurs. Pour qu'un nouveau programmeur en vienne à posséder une théorie existante du programme, il ne suffit pas qu'il ait l'occasion de se familiariser avec le texte du programme et d'autres documents. Ce qu'il faut, c'est que le nouveau programmeur ait la possibilité de travailler en contact étroit avec les programmeurs qui possèdent déjà la théorie, afin de pouvoir se familiariser avec la place du programme dans le contexte plus large des situations réelles pertinentes et d'acquérir la connaissance du fonctionnement du programme et de la manière dont les réactions et les modifications inhabituelles du programme sont traitées dans le cadre de la théorie du programme. Ce problème de la formation des nouveaux programmeurs à une théorie existante d'un programme est assez similaire au problème éducatif d'autres activités où la connaissance de la manière de faire certaines choses domine sur la connaissance que certaines choses sont le cas, comme l'écriture et la pratique d'un instrument de musique. L'activité éducative la plus importante est que l'élève fasse les choses pertinentes sous une supervision et une orientation appropriées. Dans le cas de la programmation, l'activité devrait inclure des discussions sur la relation entre le programme et les aspects et activités pertinents du monde réel, ainsi que sur les limites fixées aux questions du monde réel traitées par le programme.

Une conséquence très importante du point de vue de la construction de la théorie est que la reprise d'un programme, c'est-à-dire le rétablissement de la théorie d'un programme simplement à partir de la documentation, est strictement impossible. Pour que cette conséquence ne paraisse pas déraisonnable, il convient de noter que le besoin de relancer un programme entièrement mort se fera probablement rarement sentir, puisqu'il est difficilement concevable que la relance soit confiée à de nouveaux programmeurs sans qu'ils aient au moins une certaine connaissance de la théorie dont disposait l'équipe d'origine. Malgré cela, le point de vue de la construction de la théorie suggère fortement que la reprise d'un programme ne devrait être tentée que dans des situations exceptionnelles et en étant pleinement conscient qu'elle est au mieux coûteuse et qu'elle peut conduire à une théorie reprise qui diffère de celle que les auteurs du programme avaient à l'origine et qui peut donc contenir des divergences par rapport au texte du programme.

Selon le point de vue de la construction de la théorie, il est préférable de ne pas reprendre le texte du programme existant et de donner à l'équipe de programmeurs nouvellement formée la possibilité de résoudre le problème à nouveau. Une telle procédure a plus de chances de produire un programme viable qu'une reprise de programme, et ce à un coût qui n'est pas plus élevé, voire même moins élevé. Le fait est que l'élaboration d'une théorie pour s'adapter à un texte de programme existant et le soutenir est une activité difficile, frustrante et qui prend du temps. Le nouveau programmeur est susceptible de se sentir déchiré entre la loyauté envers le texte du programme existant, avec toutes les obscurités et les faiblesses qu'il peut contenir, et la nouvelle théorie qu'il doit élaborer et qui, pour le meilleur ou pour le pire, sera très probablement différente de la théorie originale qui sous-tend le texte du programme.

Des problèmes similaires sont susceptibles de se poser même lorsqu'un programme est maintenu en vie par une équipe de programmeurs en constante évolution, en raison des différences de compétence et d'expérience des programmeurs individuels, en particulier lorsque l'équipe est maintenue opérationnelle par les remplacements inévitables des membres individuels.

Méthode de programmation et construction de la théorie

Les méthodes de programmation ont suscité beaucoup d'intérêt ces dernières années. Dans la présente section, nous ferons quelques commentaires sur la relation entre le point de vue de la construction de la théorie et les notions qui sous-tendent les méthodes de programmation.

Tout d'abord, qu'est-ce qu'une méthode de programmation ? Cela n'est pas toujours clair, même pour les auteurs qui recommandent une méthode particulière. Ici, une méthode de programmation sera considérée comme un ensemble de règles de travail pour les programmeurs, indiquant quel type de choses les programmeurs doivent faire, dans quel ordre, quelles notations ou quels langages utiliser, et quels types de documents produire à différents stades.

Si l'on compare cette notion de méthode avec la construction de la théorie dans la programmation, la question la plus importante est celle des actions ou des opérations et de leur ordre. Une méthode implique l'affirmation que le développement d'un programme peut et doit se dérouler comme une séquence d'actions d'un certain type, chaque action conduisant à un type particulier de résultat documenté. Dans l'élaboration de la théorie, il ne peut y avoir de séquence particulière d'actions, pour la raison qu'une théorie détenue par une personne n'a pas de division inhérente en parties ni d'ordre inhérent. La personne qui possède une théorie pourra plutôt produire des présentations de différentes sortes sur la base de cette théorie, en réponse à des questions ou à des demandes.

Quant à l'utilisation de types particuliers de notation ou de formalisation, il ne s'agit là encore que d'une question secondaire puisque l'élément principal, la théorie, n'est pas et ne peut pas être exprimé, et que la question de la forme de son expression ne se pose donc pas.

Il s'ensuit que, selon le point de vue de la construction de la théorie, il ne peut y avoir de bonne méthode pour l'activité principale de la programmation.

Cette conclusion peut sembler en contradiction avec l'opinion établie, à plusieurs égards, et pourrait donc être considérée comme un argument contre la construction de la théorie. Deux de ces contradictions apparentes seront abordées ici, la première concernant l'importance de la méthode dans la poursuite de la science, la seconde concernant le succès des méthodes telles qu'elles sont effectivement utilisées dans le développement de logiciels.

Le premier argument est que le développement de logiciels devrait être basé sur des méthodes scientifiques et devrait donc utiliser des procédures similaires aux méthodes scientifiques. Le défaut de cet argument est de supposer que la méthode scientifique existe et qu'elle est utile aux scientifiques. Cette question a fait l'objet de nombreux débats ces dernières années, et la conclusion d'auteurs tels que Feyerabend [1978], qui s'inspire de l'histoire de la physique, et Medawar [1982], qui raisonne en tant que biologiste, est que la notion de méthode scientifique en tant qu'ensemble de lignes directrices pour le scientifique en exercice est erronée.

Cette conclusion n'est pas contredite par des travaux tels que ceux de Polya [1954, 1957] sur la résolution de problèmes. Ces travaux s'inspirent du domaine des mathématiques et aboutissent à des conclusions qui sont également très pertinentes pour la programmation. Cependant, il ne prétend pas présenter une méthode sur laquelle s'appuyer. Il s'agit plutôt d'un ensemble de suggestions visant à stimuler l'activité mentale de la personne qui résout les problèmes, en indiquant différents modes de travail qui peuvent être appliqués dans n'importe quel ordre.

Le deuxième argument qui peut sembler contredire le rejet de la méthode de la construction de la théorie est que l'utilisation de méthodes particulières a été couronnée de succès, selon des rapports publiés. On peut répondre à cet argument qu'une étude méthodiquement satisfaisante de l'efficacité des méthodes de programmation ne semble pas avoir été réalisée jusqu'à présent. Une telle étude devrait utiliser la technique bien établie des expériences contrôlées (cf. [Brooks, 1980] ou [Moher et Schneider, 1982]). L'absence de telles études s'explique d'une part par le coût élevé qu'elles entraîneraient sans aucun doute si les résultats devaient être significatifs, et d'autre part par les problèmes que pose l'établissement opérationnel des concepts qui sous-tendent ce que l'on appelle les méthodes dans le domaine de l'élaboration des programmes. La plupart des rapports publiés sur ces méthodes se contentent de décrire et de recommander certaines techniques et procédures, sans en établir systématiquement l'utilité ou l'efficacité. Une étude approfondie de cinq méthodes différentes par C. Floyd et plusieurs collaborateurs [Floyd, 1984] conclut que la notion de méthodes en tant que systèmes de règles qui, dans un contexte arbitraire et mécaniquement, conduisent à de bonnes solutions, est une illusion. Ce qui reste, c'est l'effet des méthodes sur la formation des programmeurs. Cette conclusion est tout à fait compatible avec le point de vue de la construction de la théorie dans la programmation. En effet, selon ce point de vue, la qualité de la théorie construite par le programmeur dépendra dans une large mesure de la familiarité du programmeur avec les solutions modèles de problèmes typiques, avec les techniques de description et de vérification, et avec les principes de structuration de systèmes constitués de nombreuses parties ayant des interactions compliquées. Ainsi, bon nombre des éléments qui intéressent les méthodes sont pertinents pour la construction de la théorie. Là où le point de vue de la construction de la théorie s'écarte de celui des méthodologistes, c'est sur la question de savoir quelles techniques utiliser et dans quel ordre. Selon le point de vue de la construction de la théorie, cette question doit rester entièrement du ressort du programmeur, qui doit prendre en compte le problème réel à résoudre.

Le statut des programmeurs et la construction de la théorie

Les domaines dans lesquels les conséquences de la construction de la théorie contrastent de la manière la plus frappante avec celles des opinions actuelles les plus répandues sont ceux de la contribution personnelle des programmeurs à l'activité et du statut propre des programmeurs.

Le contraste entre le point de vue de la construction de la théorie et le point de vue plus répandu de la contribution personnelle des programmeurs est évident dans la plupart des discussions courantes sur la programmation. Pour ne citer qu'un exemple, prenons l'étude d'Oskarsson [1982] sur la modifiabilité des grands systèmes logiciels. Cette étude fournit des informations détaillées sur un nombre considérable de modifications apportées à une version d'un grand système commercial. La description couvre le contexte, le contenu et la mise en oeuvre de chaque modification, en accordant une attention particulière à la manière dont les changements de programme sont limités à des modules de programme particuliers. Toutefois, il n'est nullement suggéré que la mise en œuvre des modifications pourrait dépendre des antécédents des 500 programmeurs employés sur le projet, comme la durée de leur travail, et il n'y a aucune indication de la manière dont les décisions de conception sont réparties entre les 500 programmeurs. Malgré cela, l'importance d'une théorie sous-jacente est admise indirectement dans des déclarations telles que "les décisions ont été mises en œuvre dans le mauvais bloc" et dans une référence à "une philosophie d'AXE". Toutefois, compte tenu de la manière dont l'étude est menée, ces aveux ne peuvent rester que des indications isolées.

De manière plus générale, la plupart des discussions actuelles sur la programmation semblent partir du principe que la programmation est similaire à la production industrielle, le programmeur étant considéré comme un élément de cette production, un élément qui doit être contrôlé par des règles de procédure et qui peut être facilement remplacé. Un autre point de vue apparenté est que les êtres humains sont plus performants s'ils agissent comme des machines, en suivant des règles, avec un accent conséquent sur les modes d'expression formels, qui permettent de formuler certains arguments en termes de règles de manipulation formelle. Ces points de vue concordent bien avec la notion, apparemment courante chez les personnes travaillant avec des ordinateurs, selon laquelle l'esprit humain fonctionne comme un ordinateur. Au niveau de la gestion industrielle, ces points de vue permettent de traiter les programmeurs comme des travailleurs ayant peu de responsabilités et n'ayant reçu qu'une brève formation.

Selon le point de vue de la construction de la théorie, le principal résultat de l'activité de programmation est la théorie détenue par les programmeurs. Puisque cette théorie, de par sa nature même, fait partie de la possession mentale de chaque programmeur, il s'ensuit que la notion de programmeur en tant qu'élément facilement remplaçable de l'activité de production de programmes doit être abandonnée. Au lieu de cela, le programmeur doit être considéré comme un développeur et un gestionnaire responsable de l'activité dont l'ordinateur fait partie. Pour occuper cette position, il doit bénéficier d'un poste permanent, d'un statut similaire à celui d'autres professionnels, tels que les ingénieurs et les avocats, dont les contributions actives en tant qu'employeurs d'entreprises reposent sur leurs compétences intellectuelles.

L'amélioration du statut des programmeurs suggérée par le point de vue de la construction de la théorie devra s'accompagner d'une réorientation correspondante de la formation des programmeurs. Si les compétences telles que la maîtrise des notations, des représentations de données et des processus de données restent importantes, l'accent devrait être mis sur l'amélioration de la compréhension et du talent pour l'élaboration de théories. La question de savoir dans quelle mesure cet enseignement peut être dispensé reste ouverte. L'approche la plus prometteuse consisterait à faire travailler l'étudiant sur des problèmes concrets, sous sa direction, dans un environnement actif et constructif.

Conclusions

Si l'on admet que les modifications de programme exigées par l'évolution des circonstances extérieures constituent un élément essentiel de la programmation, on peut affirmer que l'objectif premier de la programmation est d'amener les programmeurs à élaborer une théorie sur la manière dont les questions à traiter peuvent être prises en charge par l'exécution d'un programme. Un tel point de vue conduit à une notion de vie du programme qui dépend du soutien continu du programme par les programmeurs disposant de sa théorie. En outre, selon ce point de vue, la notion de méthode de programmation, comprise comme un ensemble de règles de procédure à suivre par le programmeur, est fondée sur des hypothèses non valables et doit donc être rejetée. En conséquence, les programmeurs doivent se voir accorder le statut de développeurs et de gestionnaires responsables et permanents de l'activité dont l'ordinateur fait partie, et leur formation doit mettre l'accent sur la construction de la théorie, parallèlement à l'acquisition de connaissances en matière de traitement des données et de notations.

References

Brooks, R. E. Studying programmer behaviour experimentally. Comm. ACM 23(4): 207–213, 1980.

Feyerabend, P. Against Method. London, Verso Editions, 1978; ISBN: 86091–700–2.

Floyd, C. Eine Untersuchung von Software–Entwicklungs–Methoden. Pp. 248–274 in Programmierumgebungen und Compiler, ed H. Morgenbrod and W. Sammer, Tagung I/1984 des German Chapter of the ACM, Stuttgart, Teubner Verlag, 1984; ISBN: 3–519–02437–3.

Kuhn, T.S. The Structure of Scientific Revolutions, Second Edition. Chicago, University of Chicago Press, 1970; ISBN: 0–226–45803–2.

Medawar, P. Pluto’s Republic. Oxford, University Press, 1982: ISBN: 0–19–217726–5.

Moher, T., and Schneider, G. M. Methodology and experimental research in software engineering, Int. J. Man–Mach. Stud. 16: 65–87, 1. Jan. 1982.

Oskarsson, Ö Mechanisms of modifiability in large software systems Linköping Studies in Science and Technology, Dissertations, no. 77, Linköping, 1982; ISBN: 91–7372–527–7.

Polya, G. How To Solve It . New York, Doubleday Anchor Book, 1957.

Polya, G. Mathematics and Plausible Reasoning. New Jersey, Princeton University Press, 1954.

Popper, K. R., and Eccles, J. C. The Self and Its Brain. London, Routledge and Kegan Paul, 1977.

Ryle, G. The Concept of Mind. Harmondsworth, England, Penguin, 1963, first published 1949. Applying "Theory Building"

Application de la "construction de la théorie"

Considérer la programmation comme une construction de la théorie nous aide à comprendre l'activité de "construction de métaphores" dans la programmation extrême (XP) et les rôles respectifs de la connaissance tacite et de la documentation dans la transmission des connaissances en matière de conception.

La métaphore en tant que théorie

Kent Beck a suggéré qu'il est utile à une équipe de conception de simplifier la conception générale d'un programme pour qu'elle corresponde à une seule métaphore. Voici quelques exemples : "Ce programme ressemble vraiment à une chaîne de montage, avec des éléments ajoutés à un châssis tout au long de la chaîne" ou "Ce programme ressemble vraiment à un restaurant, avec des serveurs et des menus, des cuisiniers et des caissiers".

Si la métaphore est bonne, les nombreuses associations que les concepteurs créent autour de la métaphore s'avèrent appropriées à leur situation de programmation.

C'est exactement l'idée de Naur de transmettre une théorie de la conception.

Si la "chaîne de montage" est une métaphore appropriée, les programmeurs ultérieurs, compte tenu de ce qu'ils savent des chaînes de montage, feront des suppositions sur la structure du logiciel en question et constateront que leurs suppositions sont "proches". Il s'agit là d'un pouvoir extraordinaire pour les deux seuls mots "chaîne de montage".

La valeur d'une bonne métaphore augmente avec le nombre de concepteurs. Plus les suppositions de chacun sont "proches" de celles des autres, plus la cohérence de la conception finale du système est grande.

Imaginez dix programmeurs travaillant aussi vite qu'ils le peuvent, en parallèle, chacun prenant des décisions de conception et ajoutant des classes au fur et à mesure. Chacun développera nécessairement sa propre théorie au fur et à mesure. Au fur et à mesure que chacun ajoute du code, la théorie qui lie leur travail devient de moins en moins cohérente, de plus en plus compliquée. Non seulement la maintenance devient plus difficile, mais leur propre travail devient plus difficile. La conception devient facilement un "kludge". En revanche, s'ils disposent d'une théorie commune, ils ajoutent du code de manière cohérente.

Une métaphore appropriée et partagée permet à une personne de deviner avec précision où un autre membre de l'équipe vient d'ajouter du code et comment intégrer son nouveau morceau.

Connaissance tacite et documentation

La documentation est presque certainement en retard sur l'état actuel du programme, mais les gens savent regarder autour d'eux. Que devriez-vous mettre dans la documentation ?

Ce qui aide le prochain programmeur à construire une théorie adéquate du programme.

Ce point est extrêmement important. L'objectif de la documentation est de rafraîchir la mémoire du lecteur, d'établir des pistes de réflexion pertinentes sur les expériences et les métaphores.

Ce type de documentation est plus stable tout au long de la durée de vie du programme que le simple fait de nommer les éléments du système actuellement en place.

Les concepteurs sont autorisés à utiliser toutes les formes d'expression nécessaires pour mettre en place ces voies pertinentes. Ils peuvent même utiliser plusieurs métaphores s'ils n'en trouvent pas une qui convienne à l'ensemble du programme. Ils peuvent dire qu'une section met en œuvre un algorithme de compression fractale, qu'une autre ressemble à un grand livre de comptes, que l'interface utilisateur suit le modèle de conception modèle-observateur, etc.

Les concepteurs expérimentés commencent souvent leur documentation avec seulement

Les métaphores
un texte décrivant l'objectif de chaque composant majeur
des dessins des principales interactions entre les principaux composants.

À eux seuls, ces trois éléments permettent à l'équipe suivante de construire une théorie utile de la conception.

Le code source lui-même sert à communiquer une théorie au prochain programmeur. Des conventions de dénomination simples et cohérentes aident la personne suivante à construire une théorie cohérente. Lorsque les gens parlent de "code propre", ils se réfèrent en grande partie à la facilité avec laquelle le lecteur peut construire une théorie cohérente du système.

La documentation ne peut pas - et ne doit donc pas - tout dire. Son but est d'aider le prochain programmeur à construire une théorie précise du système.

Source : Peter Naur

Et vous ?

:fleche: Pensez-vous que le point de vue de la programmation en tant que "construction de théorie" est crédible ou pertinent ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: 10 choses que les développeurs logiciels devraient apprendre sur l'apprentissage, un article scientifique de Neil C. C. Brown, Felienne F. J. Hermans et Lauren E. Margulieux

:fleche: 10 vérités difficiles à avaler que l'on ne vous dira pas sur le métier d'ingénieur logiciel, par Mensur Durakovic, ingénieur logiciel

:fleche: Un codeur réfléchit aux derniers jours de son métier, "un mauvais programmeur plus GPT-4" est une chose dangereuse, selon James Somers