Une affordance trompeuse assez légère, presque anecdotique, mais qui faisait parti de la liste d'origine de cette série.

Parlons refactorisation, ou plutôt parlons de l'abus de l'usage du terme. De nos jours, toute modification de code sans perspective d'évolution fonctionnelle est régulièrement appelée refactorisation, parce qu'il est connu qu'il y a eu une écriture initiale en des temps immémoriaux, et qu'il n'advient subséquemment qu'une suite sans fin de refactorisations pour l'amener vers la fameuse qualité. D'ailleurs Ward Cunningham n'a-t-il pas parlé lui-même de la refactorisation comme outil de remboursement de la dette technique ? Il le fait, a raison, parce que c'est Ward, il en a le droit.

Faisons un petit tour par l'origine du terme factorisation : il nous vient des mathématiques, plus précisément de l'algèbre, et il signifie l'opposé du terme développement. Coïncidence ? Beauté d'un vocabulaire spécifique à un domaine ? Poésie de l'informatique ? Sans rentrer dans les détails de la distributivité, on peut donner quelques exemples accessibles : 35 + 45 = 5 x (7 + 9), le 5 a été mis en facteur ; 18 + 24 = 3 × (6 + 8) = 6 × (3 + 4) = 2 × (9 + 12). Toutes ces formes sont strictement équivalentes, elles représentent le même nombre. Cela fonctionne aussi en l'exprimant sous la forme d'un dérivé de l'algèbre nouvelle : (a + b)² = a² + b² + 2 × a × b, cette forme factorisée à gauche, et développée à droite, est tellement remarquable qu'elle fait partie de la famille des identités remarquables. Remarquable non ? Bref, l'intérêt du principe de factorisation c'est que cela fonctionne, quelles que soient les valeurs auxquelles ont l'applique, car c'est le principe même de mise en facteur qui est rigoureusement prouvé.

Les anglophones sont donc partis sur cette thématique d'effectuer une nouvelle mise en facteur du code, d'abord afin de le compacifier et d'éviter les doublons, puis pour désigner toute opération de restructuration que l'on n'a pas vraiment besoin de tester pour savoir qu'elle ne changera pas le comportement du logiciel. Et il leur ont donné le nom de refactoring, non pas en référence à l'usine factory, encore moins à la fabrication to manufacture et à l'usinage to machine, mais bien à la mise en facteur to factor. Mais ça, les québecois sont complètement passés à côté en proposant réusinage, sans doute pour se caler sur les français proposant le cache.

Les techniques de refactorisation, qui par nature garantissent l'absence de modification du comportement, ne peuvent donc être que très précisément définies et en nombre relativement restreint. Et pourtant le terme est devenu synoyme avec le temps de n'importe quelle opération de retravail du code. Qui va s'en plaindre me direz-vous, à part quelques puristes sycophantes comme moi-même ? Dans ce cas précis, c'est une personne que nous avons déjà rencontré dans cette série sur les affordances trompeuses, en la personne de Martin Fowler. Le livre Refactoring : improving the design of existing code écrit par celui-ci est sorti en 1999, et a grandement contribué à faire connaître ces techniques, et est considéré par certains comme la bible sur la refactorisation. Oui, le même Martin Fowler qui a détruit toute la valeur de la métaphore de la dette technique, se plaint du mésusage du terme refactoring dans cet article de 2004. On peut y lire :

Je réalise que je suis sans doute en train de mener un combat perdu d'avance, mais je veux préserver la précision de la définition de la refactorisation. Il peut y avoir d'autres bonnes techniques pour restructurer, mais elles sont différentes. J'aimerais que nous soyons tous au clair sur ce que cela signifie quand nous utilisons ce mot.

Ah Martin, si seulement tu savais !

Vous pouvez trouver le reste de la série sous l'article d'introduction.

 Ingénieur informaticien, je suis ingénieur informaticien, j'aime les ordinateurs, Windows 98 

Cette comptine a peut-être bercé vos jeunes années, et construit chez vous cette image de l'informaticien, si proche de la machine qu'il en est à la limite des troubles du spectre autistique. Il est souvent vu comme un codeur ou pire, comme la personne qui sait y faire avec ces choses-là, désignant par cette expression ce nouvel espace ésotérique de la cyberfantasy, qui va vraisemblablement dominer le monde avec ses IA, un monde résolument incompréhensible et qui fait peur... enfin tous les machins avec de l'électricité et des boutons en somme.

L'informaticien ne serait là-dedans qu'un vague initié, gravissant les premières marches le rapprochant sans jamais pouvoir l'atteindre du prochain GADLU ? Comme nous l'avions vu dans LA DATA, normalement non, il n'y a pas de magie dans l'informatique, mais tentons un autre prisme que cette définition institutionnelle. Prenons par exemple l'excellent Que sais-je sobrement intitulé  L'informatique  par Pierre Mathelot de 1969. Année éro... intéressante dans le sens où elle nous a laissé le temps de nous éloigner de la mécanographie pour vraiment entrer dans l'ère de l'ordinateur. Que nous dit Pierre ?

L'informatique peut être définie comme la science du traitement logique et automatique du support des connaissances et des communications humaines, à savoir : l'information. Ce qui veut dire que l'informatique comprend tout à la fois et de manière indissociable, les moyens du traitement et leur fonctionnement, les méthodes de traitement, et l'étude des domaines d'application.

Puis plus loin.

Les machines ont conduit à la création de nouvelles catégories de professionels. On peut distinguer cinq catégories : 

• les perforateurs et les opérateurs (niveaux voisins de celui de l'ouvrier spécialisé) qui assurent la perforation des cartes et des bandes et le fonctionnement des divers organes de la machine ;
• les programmeurs (niveau voisin de celui de l'étudiant en propédeutique) qui, comme leur nom l'indique, écrivent les programmes ;
• les analystes et les chercheurs (niveaux voisins de celui des étudiants diplômés des universités et des grandes écoles) qui pour mission de concevoir les organigrammes et d'élaborer et maintenir les outils de base que sont les systèmes et les langages.

A la vérité, le métier d'informaticien (pour utiliser une dénomination plus générale) s'introduit de façon complémentaire dans tous les domaines où des hommes, aujourd'hui, doivent penser leurs problèmes, en les confrontant aux méthodes et aux moyens nouveaux qui leur sont offerts, et dont nous avons parlé au chapitre précédent.

Si le mot  information  n'apparaît pas en tant que tel dans  analystes et chercheurs , la trame sous-jacente est bien là, tellement évidente qu'elle n'est pas rappelée : l'informaticien travaille sur tout le spectre de l'information qui va de la conception jusqu'au matériel ; l'information support de la connaissance et des communications. Ce point étant éclairci, il reste comme d'habitude des problèmes aux interfaces, aux frontières : le DATA ANALYST est-il avant l'information, et ne serait donc pas un informaticien ? Ou ne pourrait-on pas considérer que le DATA ANALYST d'aujourd'hui ne travaille déjà plus sur des données mais directement sur de l'information ?

Vous pouvez trouver le reste de la série sous l'article d'introduction.

Dans certains domaines, et en particulier celui du logiciel (on ne parle pas ici d'informatique, cf. LA DATA), l'impérialisme anglais a fait son chemin. La croyance répandue est qu'en écrivant le code et les commentaires intégralement en anglais, non seulement ceux-ci deviendraient universellement compréhensibles par tous les codeurs, mais le résultat obtenu serait intrinsèquement meilleur, car non pollué par les affres de sa langue maternelle qui est plus éloignée des langages de programmation.

Cette foi en l'anglais comme seule langue de communication est une partie du credo de ceux qui ont élevé le codage à un niveau religieux, et, forcément, qui rentrent dans l'évangélisation. Ceci n'est pas un problème en tant que tel, le monde du logiciel (et encore plus côté matériel) est peuplé de fanatiques qui s'entrecroisent et s'invectivent au nom d'une rationalité qui a été foulée des doigts boudinés depuis bien longtemps, et remplacée le plus souvent par du FUD (qui n'est malheureusement pas une affordance trompeuse). Revenons au sujet.

Un programme informatique est une œuvre littéraire triple : elle parle d'un sujet dit "métier" à une double audience, d'un côté des programmeurs et de l'autre des interpréteurs de code (qu'ils soient compilateurs ou machines virtuelles)(et, ce, sans aller jusqu'à la programmation lettrée au sens de Knuth). On peut sortir de la réflexion les interpréteurs de code : ils ont leur propre langage (C, BASIC, Logo, Java, JavaScript, Brainfuck, Ladder, SCXML... : à chaque jour son langage), qui n'est pas l'anglais.

Rentrons dans le sujet par le "métier". Imaginons l'écriture d'un programme pour l'assistance à l'arbitrage de l'escrime : le français est la langue officielle au niveau international, et au niveau national, on utilise une langue locale. Prenons le judo : le japonais est la langue officielle au niveau international et très souvent au niveau national, en utilisant une transcription romane pour l'écrit. Prenons une autre discipline sportive : le droit. En France, le droit n'est ni de type romano-germanique ni de type common law. Dans ce petit éventail d'exemples, il n'y a rien de naturel, rien d'évident à imposer une traduction vers l'anglais. Celle-ci pénalise deux publics : ceux qui connaissent le "métier" n'auront de cesse de chercher le terme d'origine, et ceux le connaissant peu se verront freinés dans leur acquisition de connaissance par cet intermédiaire qui les coupe des références. On peut d'ailleurs considérer que ces traductions du "métier" sont un facteur primaire de dette technique.

Venons-en à la communication entre programmeurs : on se plait volontiers à penser un ensemble homogène de coders / doers / makers où tout le monde va se comprendre intuitivement parce que c'est de l'informatique ma bonne dame. Comment imaginer une homogénéité dans une population qui ne cesse de rejeter l'informatique au profit du codage et des guerres de clocher (cf. supra) ? Une population qui refuse de conceptualiser et ne veut voir que des outils ?

En supposant que l'on souhaite réellement transmettre de la connaissance à ses collègues codeurs, et pas juste les laisser avec du code destiné aux machines, que fait-on quand on n'a pas la certitude que l'autre est sur la même longueur d'onde ? Va-t-on chercher à être plus explicite, ou au contraire, va-t-on rajouter une surcouche sur le message que l'on souhaite passer ? Dans une langue que l'on va moins maîtriser ? Dans les faits, c'est le deuxième cas qui se produit le plus souvent. Dans combien de programmes dont aucun non-francophone ne lira jamais le code, ces écrits ne sont compréhensibles que par une traduction mot à mot ? Et quand bien même, quand les codeurs ne font pas la différence entre une stack et un heap, entre une layer et un module, entre un service et une API, quand les mots sont vidés de leur sens pour ne plus être que les étiquettes composant la folksonomie d'une chapelle, alors cet anglais forcé n'est plus que le clou fermant le cercueil de la transmission de connaissance.

Vous pouvez trouver le reste de la série sous l'article d'introduction.

Depuis quelques années, le vocable "dette technique" est à la mode. Dans le langage commun du développeur, ce terme est synonyme de tout ce qui ne lui plaît pas dans le code, et que le méchant management ne lui laisse pas changer. Les causes d'insatisfactions sont nombreuses, ceci allant du non-respect des "bonnes pratiques" jusqu'au #cépamoderne en passant par la volonté de faire de la compta en virgule flottante. Pourquoi ce nom de dette technique ? On se verra répondre que si on ne le fait pas (sous-entendu, le bien), alors on le paiera plus tard. Soit. Mais selon quelles modalités ? Est-ce grave de payer plus tard si cela est sans frais ? La modernité dans la tech ayant une durée de vie de six mois, est-ce qu'il ne vaudrait pas mieux attendre ? Devant une telle définition de la dette technique, on est effectivement tenté de répondre avec une locution à peu près aussi définie : un tiens vaut mieux que deux tu l'auras.

On peut se demander si cette expression est arrivée à être diffusée uniquement sur sa proposition de "boîte à contrariétés". La réponse est évidemment non, sinon on ne serait pas dans la série des affordances trompeuses. Presque vingt ans après avoir créé cette métaphore, Ward Cunningham l'explique très bien dans cette courte vidéo. Celle-ci n'ayant pas de sous-titres français, et devant l'absurdité de regarder une image mouvante pour ce qui tient en quelques lignes, je vous en propose ici une transcription traduite.

J'ai commencé à m'intéresser à la façon dont les métaphores influencent notre façon de penser après la lecture de "Metaphors We Live By" de George Lakoff et Mark Johnson. Une idée importante est que nous raisonnons par analogie avec les métaphores qui sont entrées dans notre langage.

 

J'ai inventé la métaphore de la dette pour expliquer la refactorisation que nous faisions sur le produit WyCash. C'était un produit développé en Digitalk Smalltalk et il était important pour moi que nous reflétions les connaissances acquises à propos de l'application au cours du temps, en modifiant le programme pour qu'il ait l'air d'avoir été écrit comme si nous avions eu cette connaissance depuis le début, et comme si c'était la façon naturelle de le faire en Smalltalk.

 

L'explication que j'ai donné à mon chef, et on parle de logiciel dans le domaine de la finance, était une analogie financière que j'ai appelée la métaphore de la dette, qui dit que si l'on échoue à aligner notre programme avec ce que l'on a compris de la bonne façon de penser nos objets financiers, alors nous allions continuellement buter sur cette divergence, et que cela nous ralentirait de la même manière que de payer les intérêts d'un emprunt.

 

En empruntant de l'argent vous pouvez faire des choses plus vite que sans, mais jusqu'au remboursement complet, vous payez des intérêts. Je pensais qu'emprunter de l'argent était une bonne idée. Je pensais que se dépêcher de sortir le logiciel pour avoir de l'expérience avec était une bonne idée mais, évidemment, vous devez finalement revenir en arrière et, à mesure que vous apprenez des choses sur ce logiciel, vous allez rembourser cette dette en refactorisant le programme pour refléter cette expérience acquise.

 

Je pense que dans de nombreux cas les gens se dépêchent de sortir le logiciel et n'y réintègrent pas cet apprentissage, et par analogie, ont emprunté de l'argent sans avoir l'intention de le rembourser. Il va sans dire que si vous faites ça avec votre carte de crédit, à la fin toutes vos rentrées d'argent partent dans les intérêts, et votre pouvoir d'achat est nul.

 

Dans le même ordre d'idées, si vous développez un programme pendant longtemps en ne faisant qu'ajouter des fonctionnalités, et que jamais vous ne le réorganisez pour refléter votre compréhension de ces fonctionnalités, alors il arrivera un moment où il n'y aura plus de cohésion dans le programme, les efforts pour travailler dessus prendront de plus en plus de temps. En d'autres termes, les intérêts occuperont toutes vos rentrées et vous ne progresserez plus.

 

Beaucoup de personnes, tout du moins de bloggueurs, ont expliqué la métaphore de la dette en, je pense, la confondant avec l'idée que l'on peut écrire vite-fait du code avec l'intention de faire mieux plus tard, et que ceci était la première cause d'endettement. Je ne suis jamais pour écrire du code vite-fait, je suis pour écrire du code qui reflète votre compréhension présente d'un problème, même si cette compréhension est incomplète.

 

Si vous souhaitez vous endetter en développant un logiciel que vous ne comprenez pas complètement, alors il est sage de faire un logiciel qui reflète au mieux votre compréhension. Quand le temps de la refactorisation arrive, cela permet de voir clairement ce que vous pensiez alors et ainsi de rendre plus facile la transformation en ce que vous pensez désormais.

 

En d'autres termes, cette métaphore de la dette, ou de la capacité à rembourser la dette, pour qu'elle puisse fonctionner pour vous, dépend de votre capacité à écrire du code suffisamment propre pour pouvoir être refactorisé une fois que vous aurez compris le problème.

 

Je pense que c'est une bonne méthodologie qui est au cœur de l'eXtreme Programming. La métaphore de la dette est une des nombreuses explications au fait que l'eXtreme Programming fonctionne.

La dette technique actuelle est donc une version allégée, fade et sans réel intérêt, de la métaphore de la dette de Cunningham, qui est, elle, une justification de l'amélioration continue appliquée au développement logiciel, en partant du principe que si l'on n'a pas la compréhension nécessaire pour finir la conception, on peut quand même développer le logiciel (en s'endettant), à condition de revenir sur cette conception une fois que cette compréhension est acquise (remboursement de la dette). La métaphore de la dette est une question de gestion de la connaissance.

Vous pouvez trouver le reste de la série sous l'article d'introduction.

Après quelques aller-retours ces 40 ou 50 dernières années, le data center est à nouveau à la mode, en particulier parce qu'il se doit d'être vert. Le data center est en effet aujourd'hui le lieu où se matérialise le cloud computing. Data ? Computing ? Cela vous rappelle évidemment l'affordance trompeuse LA DATA ! Autant LA DATA est trompeur en français, autant data center l'est dans sa langue d'origine, et on peut légitimement se demander si cela a toujours été le cas. Le Web est (comme souvent) assez pauvre sur l'origine des termes informatiques, mais en cherchant un peu, on arrive relativement vite sur le cas des World Data Center créés en 1957. L'histoire de leur établissement peut être découverte dans The Origins and Principles of the World Data Center System, dont provient l'extrait ci-dessous :

At its decisive meeting in Brussels in 1955, when the Soviet Union officially unveiled its IGY programs, CSAGI set up a special Committee on the Availability of Data. This Committee recommended that data centers be set up in different countries as depositories and dissemination points for IGY data. The data would be collected and made available to any scientists without condition except for the cost of reproduction and mailing. The Committee recommended that CSAGI publish guides to the depositories and the types of data available from each. These World Data Centers would be more than passive depositories. They would actively supply data and provide the necessary facilities for data analysis.

Lors de sa réunion décisive à Bruxelles en 1955, lorsque l'Union soviétique dévoila officiellement ses programmes pour l'Année Géophysique Internationale (IGY), le Comité Spécial de l’Année Géophysique Internationale (CSAGI) a mis en place un comité spécial sur la disponibilité des données. Ce comité a recommandé que des centres de données soient créés dans différents pays en tant que dépositaires et points de diffusion des données de l'IGY. Les données seraient collectées et mises à la disposition de tous les scientifiques sans condition, à l'exception des frais de reproduction et d'envoi. Le comité a recommandé que le CSAGI publie des guides sur les dépositaires et les types de données disponibles pour chacun. Ces centres mondiaux de données seraient plus que des dépositaires passifs. Ils fourniraient activement des données et fourniraient les installations nécessaires pour l'analyse des données.

Ne nous méprenons pas, on parle déjà à l'époque d'automatisation du traitement des données, et de données numériques (sur cartes perforées), voire des premiers computer facilities : nous étions toujours en plein dans l'ère de la mécanographie. Le terme de data center est très probablement arrivé avant, mais à la fin des années 50, il paraît assez clair que quand on parle de ces data center, c'est pour désigner une stratégie proactive de centralisation des données dans un dépôt défini et géré par des sachant, afin de pouvoir les mettre en valeur. Le premier sujet tourne autour de la non-perte des données et de leur partage, un but proéminent après le succès relatif de la deuxième Année Polaire Internationale (API).

Rien de cela dans le data center d'aujourd'hui, qui n'est plus qu'un bâtiment connecté à Internet, bien refroidi, et rempli de serveurs, quelles que soient leurs utilisations.

Vous pouvez trouver le reste de la série sous l'article d'introduction.

Dans la lignée de la revalorisation du travail des opérateurs est née la mouvance GitOps, à savoir les relations particulières entre les opérateurs et les connards (traduction littérale de git). En fait pas vraiment, comme le disent les créateurs de GitOps (Weaveworks) dans leur article de 2017, GitOps consiste en la mise en œuvre d'une approche déclarative pour décrire ce que l'on souhaite dans son système, puis de détecter les changements, et d'agir en conséquence en fonction des changements demandés. Vous aurez bien évidemment reconnu l'approche CFEngine de 1993, en un peu moins puissant, dans le sens où en GitOps les différences sont évaluées cible par cible, et pas de manière systémique ; ici on parle de cible d'outillage de déploiement et pas cible finale.

Est-ce que Git est important là-dedans ? L'article nous dit que oui, dans le sens où Git permet d'avoir gratuitement la revue de code, les commentaires dans les fichiers de configuration, de lier les engagements (commit) aux tickets et de gérer les demandes de récupérations d'engagements (pull request). La réponse est donc non, dans le sens où aucune de ces choses n'est spécifique à Git en particulier, les quatre premiers points étant standards à tous les gestionnaires de versions, et le cinquième étant indépendant du gestionnaire de version mais facile à mettre en œuvre dans les gestionnaires distribués de versions.

Ce qui compte donc dans GitOps n'est donc pas Git, mais l'approche déclarative et versionnée, celle qu'on tente de mettre en œuvre depuis plus de vingt ans, et qui est cassée à chaque fois qu'un produit devient à la mode et qui ne sait être configuré qu'en mode impératif (ou pour parler en termes d'affordances trompeuses, par API). Il se trouve que les créateurs sont partis du gestionnaire de source du moment, sans chercher à utiliser ses spécificités, on prend celui utilisé par les développeurs. Et pour Ops… les opérateurs sont des anonymes, tout va bien de ce côté, on peut le rajouter dans n'importe terme :-)

Certains rétorqueront que l'article séminal a été mis à jour, et que si, Git est bien indispensable. Mais ce que cette mise à jour fait vraiment est de montrer en quoi le modèle actuel du Continuous Deployment (ou CD, pas le disque optique) basé sur un enchaînement de scripts impératifs n'est pas réconciliable avec l'approche déclarative, qui elle travaille à deux niveaux : l'expression du changement dans l'exigence, et la mesure de l'écart entre l'exigence et ce qui est en place. L'approche CD traditionnelle (dite du pipeline, ou en Français de la Tech, du pipeline) s'arrête au moment où l'on propage le changement demandé, et ne comporte pas la boucle de rétroaction qui vient après la mesure de l'écart (qui n'est d'ailleurs pas systématiquement faite). On reste donc bien sur les principes de CFEngine, et Git dans l'affaire n'est qu'un accessoire à ces principes, même s'il se trouve techniquement au milieu de cette mise en œuvre particulière.

Vous pouvez trouver le reste de la série sous l'article d'introduction.

Les noms REST API et RESTful invitent au voyage dans le monde des architectures post-Web. Roy Fielding, le seul créateur de REST le dit d'ailleurs explicitement : REST est un style d'architecture qui n'a de sens que dans un système hypermédia distribué. Sans ressources capables de référencer d'autres ressource (hypermédia), sans système qui implique d'avoir de multiples unités de calculs distinctes (distribué), l'architecture retenue pour construire une application ne peut pas suivre un style qui correspond à REST. Et dans ces deux aspects, hypermédia et distribué, étant donné que l'aspect distribué a été traité ad nauseam pendant un demi-siècle, le facteur discriminant est en conséquence l'hypermédia.

L'approche RESTful se concentre sur la mise en place des REST API, et considère que la prise en compte de l'hypermédia est quelque chose d'optionnel, car difficile à mettre en œuvre pour le besoin réel. Comme REST impose l'hypermédia en tant que sujet primaire de réflexion, justement parce que c'est le sujet difficile qui permet de répondre à des besoins auxquels les autres styles d'architecture ne répondent pas, alors on peut en déduire que les termes REST API et RESTful sont représentatifs d'une mouvance NoREST. On trouve un marqueur fort chez les partisans du NoREST : la mise en avant d'un seul format d'échange de données, format qui n'est pas hypermédia, le JSON.

Vous pouvez trouver le reste de la série sous l'article d'introduction.

À la fin des années 70, Trygve Reenskaug fait face au problème de la gestion d'un nombre important de données dans une application, et cherche un modèle de programmation qui rende l'application maintenable. On parlera de la maintenabilité dans un autre article, c'est une autre affordance trompeuse. Il arrive après plusieurs itérations et en collaboration au Model View Controller. Rétrospectivement il regrette ce nom de Controller qui n'est pas assez expressif pour le rôle joué.

Le MVC est organisé en une hiérarchie de couples Vue (ce que voit l'utilisateur) - Contrôleur (ce qui reçoit les entrées de l'utilisateur), avec des Modèles sous-jacent (le monde manipulé), la communication entre les Modèles et les Vues se fait dans une approche Observateur / Observé. Si vous enlevez un de ces éléments, vous n'avez plus de MVC. Et pourtant, un article paru sur InfoWorld en 1999 a réussi à populariser le fait que le Model 2 de Sun Microsystems pour Java EE (à l'époque J2EE) était une approche MVC pour le Web : pas de couples Vue - Contrôleur, pas d'organisation hiérarchique ni des Vues ni des Contrôleurs, pas communication Observateur / Observé, pas de support de l'hypermédia, le Model 2 n'était en fait ni MVC ni vraiment Web.

Le MVC se retrouvait réduit à l'état d'une triade vidée de sa substance, un vague Separation of Concerns sans objectif ni raison d'être, et c'est cette vision qui a perduré et a été reprise par la suite dans les frameworks dits Web (Struts, Spring MVC, Django, Symfony, etc…). Cette affordance trompeuse nous suit depuis bien longtemps, voir cet article de 2006 sur la partie dite Web, ou cet article de 2004 où comment cette fausse interprétation du MVC vient polluer la compréhension des vrais frameworks MVC.

Vous pouvez trouver le reste de la série sous l'article d'introduction.

JSON est un format de texte bien connu, et format privilégié des amateurs de l'approche NoREST. Ce format, très simple, est défini dans la RFC 8259 de l'IETF ou encore ECMA-404 de l'ECMA, qui spécifie que l'acronyme signifie "JavaScript Object Notation". On pourrait donc s'attendre à ce qu'on puisse décrire en JSON un objet au sens JavaScript, à savoir quelque chose avec un état et un comportement, des propriétés et des méthodes. Juste après, la spécification précise que JSON est un format d'échange de données, on comprend donc que la partie "comportement" ne fera pas partie de JSON. On pourrait du coup s'attendre à ce que les types de données scalaires JavaScript standards soient supportés dans JSON. Ce n'est pourtant pas le cas, seuls les nombres et les chaînes de caractères sont décrits et, par le tour de passe-passe d'utilisation de mots-clefs, on ajoute les booléens. Au final, le JavaScript dans JSON est l'équivalent de Git dans GitOps : un tube néon qui va mettre en valeur le nom.

Vous pouvez trouver le reste de la série sous l'article d'introduction.