You may implement this later: Cofunctors as partial implementations

Dans le monde du génie logiciel, la construction d'un système ressemble souvent à l'assemblage d'une machine complexe où chaque engrenage doit être choisi avant que le premier boulon ne soit serré. Les ingénieurs sont fréquemment confrontés à un dilemme : ils doivent concevoir la structure globale d'un programme, comme une base de données ou un service réseau, mais ne peuvent pas encore décider des détails spécifiques, comme le moteur de stockage à utiliser ou la manière de gérer la réplication des données. Les méthodes traditionnelles pour gérer cette incertitude consistent généralement à verrouiller un ensemble unique de choix pour l'ensemble du système dès le début, ou à attendre la toute fin pour combler les lacunes. Cela crée un processus rigide où la voie à suivre est fixée bien avant que la destination ne soit pleinement claire. Le défi consiste à trouver un moyen de construire des systèmes qui puissent évoluer, où les décisions prises tôt peuvent naturellement façonner les options disponibles plus tard, sans contraindre le programmeur à s'engager prématurément dans une solution finale.

Un chercheur de l'Université d'Oxford a proposé une nouvelle façon d'aborder ce problème, en utilisant un concept mathématique appelé cofoncteur pour décrire comment un logiciel peut être construit par étapes. L'idée centrale est de traiter un système logiciel non pas comme un produit fini, mais comme une collection d'obligations et de choix qui changent à mesure que le système croît. Imaginez le plan d'une maison qui commence par un contour basique. À mesure que l'architecte ajoute une nouvelle pièce, le plan ne se contente pas de s'agrandir ; il met également à jour la liste des matériaux nécessaires. Si l'architecte décide d'ajouter un étage, le plan pourrait désormais nécessiter des fondations plus solides, un choix qui n'était pas pertinent quand la maison n'était qu'un simple rez-de-chaussée. Cette nouvelle approche permet aux ingénieurs de porter ces listes évolutives d'exigences tout au long du processus de conception, garantissant que chaque nouvelle décision est compatible avec celles qui l'ont précédée, tout en laissant les détails finaux ouverts pour plus tard.

L'article soutient que les outils existants pour la gestion des configurations logicielles sont souvent trop rigides. Ils exigent généralement qu'un ensemble global de paramètres soit défini dès le tout début, ce qui signifie que le système ne peut pas facilement s'adapter si une nouvelle exigence émerge en cours de développement. Par exemple, choisir de stocker des données d'une certaine manière pourrait plus tard imposer une décision sur la façon de répliquer ces données à travers différents serveurs, mais les méthodes standards peinent à lier ces deux décisions de manière dynamique. L'auteur suggère qu'en considérant un système logiciel comme une « implémentation partielle », où l'état actuel du système dicte les choix disponibles ensuite, nous pouvons créer un processus d'ingénierie plus flexible. Il ne s'agit pas seulement de retarder les décisions ; il s'agit de structurer le système de sorte que l'acte de prendre une décision mette naturellement à jour le menu des options pour la suivante.

Pour démontrer cela, l'auteur utilise l'exemple d'un système de stockage de données. Initialement, le système peut être défini simplement comme un lieu pour conserver des données. À ce stade, l'ingénieur n'a pas encore décidé s'il utilisera une base de données locale, un service distant ou un format de fichier spécifique. À mesure que la conception progresse, l'ingénieur peut ajouter une exigence de persistance des données, signifiant qu'elles doivent survivre à des coupures de courant. Cette nouvelle exigence met à jour l'état du système, introduisant un nouvel ensemble de choix concernant la durabilité. Plus tard, si l'ingénieur décide de répliquer les données dans plusieurs emplacements pour plus de sécurité, le système se met à jour à nouveau. Ce second changement peut introduire une exigence de protocole de transaction, un détail qui n'existait pas lorsque le système n'était qu'un simple magasin de données. La beauté de cette approche est que le système vérifie automatiquement les conflits. Si l'ingénieur avait choisi un format de fichier simple incapable de gérer les transactions, le système signalerait ce conflit immédiatement lors de l'ajout de l'exigence de réplication, plutôt que d'attendre que le code soit écrit et qu'il échoue plus tard.

Le chercheur montre que cette méthode permet la création de plans de migration exécutables. Au lieu de simplement rédiger une liste d'exigences, le système peut générer un plan étape par étape pour transformer un magasin de base en un système complexe et répliqué. Ce plan peut être construit par étapes, chaque étape étant vérifiée par rapport à l'état actuel du système. Si une étape est sautée ou effectuée dans le mauvais ordre, le système peut détecter l'erreur. Par exemple, un plan qui tenterait de répliquer des données avant de créer un magasin durable serait rejeté car la fondation nécessaire n'existe pas encore. Cela garantit que le système final est construit sur un chemin logique solide, où chaque changement est cohérent avec l'historique des changements précédents.

L'une des conclusions clés est que cette approche ne nécessite pas que l'ingénieur énumère à l'avance tous les états futurs possibles du système. Dans de nombreuses méthodes traditionnelles, il faut définir toutes les configurations possibles en amont, ce qui peut être accablant et conduit souvent à une explosion combinatoire d'options. Ici, le système ne suit que les obligations qui sont actuellement actives. À mesure que de nouvelles exigences sont ajoutées, de nouveaux choix apparaissent, et à mesure que les anciennes exigences sont satisfaites, elles disparaissent. Cela permet de maintenir la complexité sous contrôle. L'auteur note que, bien que le cadre mathématique derrière cette idée soit sophistiqué, son application pratique est directe : elle fournit simplement un moyen de gérer le flux de décisions d'une manière qui respecte les dépendances entre elles.

L'article aborde également la raison pour laquelle cette idée n'a pas été largement adoptée auparavant dans la programmation. Le terme « cofoncteur » a historiquement été confondu avec d'autres concepts, entraînant un manque de clarté sur son utilité spécifique. De plus, les tentatives précédentes pour résoudre des problèmes similaires, comme celles impliquant des mises à jour de bases de données ou la programmation modulaire, se sont souvent concentrées sur d'autres aspects, comme le maintien de la cohérence des données ou la fusion de modules de code, plutôt que sur l'évolution dynamique des choix d'implémentation. L'auteur suggère qu'en recadrant les cofoncteurs comme un outil d'implémentation partielle, le concept devient beaucoup plus accessible et directement applicable au travail quotidien des ingénieurs logiciels.

En fin de compte, ce travail offre une nouvelle perspective sur la manière dont nous construisons des systèmes complexes. Il suggère que la meilleure façon de gérer l'incertitude n'est pas de figer la conception ou de la laisser totalement ouverte, mais de créer une structure où la conception évolue naturellement. En traitant le logiciel comme un document vivant de choix et d'obligations, les ingénieurs peuvent construire des systèmes qui sont robustes, adaptables et plus faciles à raisonner. Le résultat est une méthode qui permet l'assemblage de systèmes complexes tout en laissant les détails concrets et finaux pour le moment où ils sont réellement nécessaires, garantissant que le chemin emprunté est toujours logique et cohérent.