3 métaphores du code informatique

Le code est immatériel.

Alors, pour le rendre plus intelligible, on a recours à des métaphores du monde concret. En voici 3 particulièrement utiles à mes yeux :

Le code comme patrimoine immobilier

On le sait, une maison requiert de l'entretien. Périodiquement, il faut ravaler la façade, refaire la toiture, la remettre aux normes (électricité, chauffage…) et à l'intérieur prendre soin des murs, passer un petit coup de plâtre ici ou là. Un patrimoine s'entretient, faute de quoi il dépérit et perd de sa valeur. Vous n'imaginez pas ce que coûte l'entretien d'un manoir 💎

Le code, c'est pareil : périodiquement, il faut mettre à jour les dépendances pour pallier les failles de sécurité, corriger des bugs (parce que même avec la meilleure volonté du monde et la plus grande compétence, il y en aura). Et préventivement, faire des refactorings pour permettre au code d'évoluer plus facilement. Voire même passer sur des technos plus récentes pour rester en adéquation avec les compétences disponibles sur le marché.

Cette métaphore fonctionne assez bien, car elle intègre même les évolutions : on ajoute des fonctionnalités comme on rajoute une véranda ou bien un étage à une maison. On fait un pivot (d'entreprise et donc de produit) comme on change la destination de la bâtisse, passant d'un usage commercial à un usage d'habitation.

Et puis si, de guerre lasse, on relâche l'effort, c'est le début de la fin : cf. la théorie de la vitre brisée (Broken windows theory).

Le code, semblable à un corps humain

Les cellules du corps humain naissent et meurent. Au terme d'une décennie, presque toutes les cellules d'un organisme se seront renouvelées. Et pourtant, notre identité perdure.

Bon, c'est probablement une question philosophique plus profonde : mon numéro de Sécurité Sociale demeure, mais suis-je la même personne qu'il y a 20 ans ? (*) Suis-je un numéro de Sécurité Sociale ? 😱

En tout cas, cela nous éclaire pour comprendre le code : les refactorings, voire les changements de technos, font que le code d'une application peut avoir intégralement changé sans que le service ait jamais été interrompu. Personnellement, je trouve ça très beau.

On ajoute des fonctionnalités comme on développe sa force physique ou acquiert de nouvelles compétences. On corrige un bug comme on panse une plaie. D'ailleurs, ne parle-t-on pas de "cycle de vie des applications" ?

La métaphore fonctionne assez bien : un programme informatique est un ensemble de modules qui collaborent, tout comme le corps humain est fait d'organes qui travaillent ensemble dans une harmonie qui n'a pas fini de nous surprendre.

La codebase… l'équivalent de votre cuisine ?

Moins habituelle, peut-être, cette dernière métaphore est pourtant éclairante à plusieurs titres.

La cuisine comme le développement d'un logiciel relèvent de l'artisanat, si ce n'est de l'art. On parle d'artisanat logiciel pour faire référence à des valeurs : la pratique, l'apprentissage, la transmission, et en filigrane une certaine humilité. L'amour du travail bien fait, on y revient encore et toujours.

Cela passe par des choses en apparence anecdotiques : de même que le cuisinier nettoie son plan de travail et aiguise ses couteaux, le développeur ferme les 38 onglets de son IDE et rajoute une règle ESLint.

Goûteriez-vous le plat d'un cuisinier qui n'a pas fait sa vaisselle depuis 1 mois ? Je vous laisse faire le parallèle pour du dev.

Au-delà, la cuisine est un espace fortement optimisé : les ustensiles et condiments les plus usuels se trouvent à portée de main, tandis que la sorbetière dort au fond d'un placard (enfin, bon, ça dépend de votre spécialité).

Et ça, c'est un principe de base en UX : "make it obvious/simple/possible". Cette hiérarchisation des actions est à la base des applications que l'on aime, parce qu'au-delà de rendre des actions faisables, elles les rendent agréables.

(*) Autrement dit, nous sommes des entités au sens du Domain-driven design.