Comment décrocher le poste de ses rêves grâce à l'algèbre relationnelle

Photo by Kelly Sikkema on Unsplash

Bonjour ! Je m'appelle Felix, je suis développeur et l'une des dernières recrues de l'équipe Klaro. J'aimerais vous raconter comment j'ai trouvé mon chemin jusqu'à travailler avec des gens aussi talentueux, sur un logiciel aussi impressionnant que Klaro.

Il y a cinq ans, j'ai entamé ma lente ascension vers l'état d'esprit anti-ORM : cette idée, partagée par certains programmeurs, selon laquelle la façon dont le monde dialogue avec ses bases de données depuis une vingtaine d'années est une grande erreur, douloureuse et coûteuse. Cela sonne comme une banale subtilité technique ? Peut-être, mais permettez-moi de souligner que l'accès aux données est au fondement même de pratiquement chaque petite application, borne de vente de tickets, jeu en ligne, réseau social et générateur de mèmes de chats qui composent ensemble le tissu de notre existence numérique. Faire les choses correctement n'est pas une mince affaire.

À un moment de mes lectures effrénées et de ma prise de notes sur le sujet, j'ai gardé le lien vers un billet, (Some) ORM haters do get it, écrit par un anti-ORM particulièrement éloquent. Ce lien allait se révéler déterminant pour la suite de mon parcours.

Mais d'abord, laissez-moi expliquer ce qui est en jeu.

Ce qu'on aimerait que ce soit

L'une des choses les plus délicates en programmation, c'est d'avoir un ensemble de morceaux de code qui fonctionnent très bien séparément, mais qu'il est difficile d'assembler. Parfois, les pièces ne fonctionnent que connectées d'une façon très particulière. D'autres fois, quelqu'un a réussi à tout faire tenir ensemble il y a des années, et vous devez aujourd'hui changer un petit détail dans l'une d'elles — mais en commençant à séparer les morceaux, vous découvrez qu'il n'y a aucun moyen de les réarranger sans tout casser. Vous avez par exemple du code qui calcule les frais de port d'un panier, mais aucun moyen simple de calculer les frais de port hypothétiques de ce même panier si le client y ajoutait un produit. Cela paraît fou, et ça l'est, mais ce genre de situation est d'une banalité gênante en programmation.

Ce n'est pas ainsi que les choses étaient censées se passer. Il est très décourageant de passer une journée entière — ce qui n'est pas rare — à chercher comment placer un bouton à l'intérieur d'une boîte plutôt qu'à côté. Savoir assembler des choses d'une certaine manière ne signifie pas qu'on sache les assembler autrement. Les programmeurs ont un exemple favori pour dire ce qu'ils aimeraient que la programmation soit : les briques Lego. « Les pièces s'emboîtent, comme des Lego ! » est une promesse courante des nouveaux langages et des nouveaux outils. C'est ainsi que nous voudrions tous que la programmation se ressente, et c'est ainsi qu'elle pourrait être : des possibilités infinies de combiner et recombiner de petits morceaux de fonctionnalité en programmes beaux et cohérents. Choisissez vos briques, aux bonnes tailles et aux bonnes couleurs, et emboîtez-les pour former des vaisseaux spatiaux, des parcs et des fermes laitières. Cet idéal porte généralement un nom : la composabilité, la capacité à composer de petites pièces en unités plus grandes en toute confiance, en sachant que les pièces ne se feront pas exploser ou gripper l'une l'autre.

« Que personne ne bouge, et personne ne sera blessé »

En mathématiques, les choses s'emboîtent généralement à merveille. L'une des raisons en est ce qu'on appelle la clôture : le principe selon lequel, si vous avez une chose d'un certain genre et que vous la modifiez ou la combinez avec une autre, vous obtenez une chose du même genre. Les nombres en sont l'exemple le plus courant. Prenez l'entier 3 et combinez-le avec l'entier 7 par l'addition : vous avez 10, un autre entier. De la même façon, la beauté du Lego tient à ce que chaque brique peut se combiner à toutes les autres, et que l'on peut continuer à combiner les assemblages obtenus. Hélas, ce n'est généralement pas ainsi que les choses se passent en programmation. À moins d'y prendre un soin particulier, votre code ressemblera à une usine pleine de petites machines qui produisent toutes des choses différentes. La sortie d'une machine ne peut servir d'entrée à la plupart des autres (ni même à elle-même). Dans le pire des cas, une fois les petites machines raccordées et faisant à peu près ce que vous vouliez, vous hésitez à toucher à quoi que ce soit de peur que tout s'effondre.

La bonne chose à faire est donc manifestement de voler aux mathématiques tout ce que l'on peut, et d'amener un peu plus de ce plaisir d'emboîtement dans la programmation. Il se trouve qu'un excellent exemple de programmation mathématique se cache à la vue de tous, dans les bonnes vieilles bases SQL avec lesquelles la plupart d'entre nous travaillons (parfois à contrecœur) presque quotidiennement. Pour beaucoup, SQL est une relique grinçante d'une époque révolue (les années 1970), un dinosaure incongru qui arpente encore le paysage informatique d'aujourd'hui. Dans cette vue, la prévalence de SQL est l'un de ces accidents de l'histoire : quelque chose qui est apparu au bon moment, est devenu populaire et a tout infiltré au point qu'on ne puisse plus s'en débarrasser. Il y a quelques années, j'ai pensé écrire un article sur ce fait curieux : notre civilisation entière tourne sur ce vieux paradigme pittoresque. Puis, lentement, j'ai commencé à comprendre ce qu'est vraiment SQL.

Le modèle relationnel et ses jolis emballages

SQL est le langage d'interface avec lequel nous interrogeons les bases de données relationnelles. « Relationnel » renvoie au modèle relationnel des données, lui-même fondé sur des concepts fondamentaux de mathématiques et de logique. Loin d'être une solution primitive bricolée dans la pénombre d'une époque moins bien informée, ce paradigme est très élégant et possède beaucoup de cette qualité « Lego ». Sans surprise, cela tient en grande partie au principe de clôture : dans le modèle relationnel, il n'y a vraiment qu'un seul genre de chose avec lequel travailler, à savoir des ensembles de « tuples » (un paquet de valeurs qui vont ensemble, comme le prénom, le nom et l'âge d'une personne). Vous pouvez modifier et combiner ces ensembles de tuples, mais tout ce que vous obtenez en retour, ce sont encore des ensembles de tuples. Des tuples en entrée, des tuples en sortie, jusqu'au bout. C'est vous qui décidez de la forme et de la taille de vos briques (les tuples), vous disposez d'une poignée de façons de les modifier ou de les combiner (les opérations), et à partir de ces matériaux modestes vous pouvez assembler des programmes qui couvrent l'essentiel de vos besoins — pas tout à fait tout ce qu'exige un système logiciel typique, mais une part étonnamment grande.

(En note pour le lecteur technique : l'attrait principal de concepts comme les semi-groupes, les monoïdes et les monades tient précisément à ce qu'ils rendent algébrique un code autrement ingérable, c'est-à-dire formé de blocs clos sous des opérations utiles.)

Or, il y a une vingtaine d'années, beaucoup de gens ont cru avoir trouvé mieux que le modèle relationnel. Certains ont tenté de se débarrasser des bases relationnelles tout court, mais la plupart ont fini par emballer le modèle relationnel dans des couches de code qui leur étaient plus familières. Beaucoup de ces jolis emballages parviennent, à des degrés divers, à préserver une part de l'élégance du modèle relationnel, mais au bout du compte ils en obscurcissent la clarté et la simplicité. (Les ORM — Object-Relational Mappers — que je mentionnais plus haut sont un type d'emballage particulièrement lourd.) Pour moi, cela revient à posséder un clavier ergonomique et bien conçu, mais à décider de ne jamais taper dessus directement — seulement à travers un appareillage complexe et bricolé, doté de moins de touches. Commode dans certaines situations, au prix d'oublier comment on se sert d'un clavier.

L'algèbre relationnelle me trouve un emploi

Et nous voici à ma propre frustration grandissante avec les surcouches de bases de données, qui a atteint son sommet il y a environ cinq ans. Je m'intéressais déjà à l'usage de la logique formelle comme fondement de la programmation (j'ai lancé plus récemment un podcast sur la programmation logique), mais j'avais en quelque sorte manqué d'apprécier pleinement que le bon vieux SQL en est un bel exemple. J'ai décidé d'examiner les meilleures surcouches de bases de données dans tous les langages, pour trouver la meilleure approche, et j'en suis progressivement venu à la conclusion que même les meilleures (mention spéciale à Quill) ajoutent peu à ce que les bases SQL, correctement manipulées, offrent déjà. J'ai enfin commencé à voir la beauté du modèle relationnel. Je suis devenu partisan de se débarrasser de toutes les couches d'emballage et de programmer le plus près possible de la base, en SQL pur la plupart du temps.

Il faut toutefois faire une concession : si le modèle relationnel est très lucide, il n'en reste pas moins que SQL lui-même n'en est pas une incarnation parfaite (simplement bien meilleure que la plupart de ses prétendues améliorations). À un niveau plus profond, le noyau du paradigme relationnel est l'algèbre relationnelle, un modèle mathématique pur de la façon de structurer et d'interroger des données. SQL n'est pas à la hauteur de cette élégance sur plusieurs points. L'étape suivante de mon parcours, celle où j'en suis encore, a été de mieux comprendre l'algèbre relationnelle, et de chercher des façons de programmer qui y adhèrent de plus près que SQL. Parmi mes trouvailles, un petit paquet logiciel appelé bmg, qui prétendait implémenter l'algèbre relationnelle pure comme interface vers des bases SQL et d'autres sources de données. Cela m'avait l'air d'un projet de recherche, quelque chose à reprendre plus tard peut-être. Inspirant, mais probablement pas utilisable en pratique. J'ai mis une étoile au projet sur GitHub, et de temps en temps je recevais une notification de mise à jour ou de correction.

Avance rapide jusqu'au printemps 2020. J'étais revenu au conseil après quelques années de salariat et je cherchais de nouveaux projets intéressants. Un beau jour, en parcourant de vieilles notes, j'ai rouvert ce billet anti-ORM dont je parlais au début, en me disant qu'il serait intéressant de le relire. J'ai vite remarqué que l'auteur n'était autre que le créateur de bmg, la bibliothèque d'algèbre relationnelle : un certain Bernard Lambeau. Et ce sage n'était pas emmuré dans une institution académique, mais dehors, à monter des startups, dont Klaro.

Et voici le moment où je vous explique comment décrocher un excellent poste en informatique par la grâce de l'algèbre relationnelle (via LinkedIn) :

Bonjour Bernard — j'aime beaucoup vos anciens billets sur revision-zero, et je suis votre travail sur bmg. Alors quand j'ai vu que vous aviez une startup et que vous cherchiez de nouveaux équipiers, il fallait que je vous contacte ! Envisageriez-vous un développeur en remote ? (Depuis la Suède.) Grand amateur de programmation centrée base de données et de logique.

J'ai vite découvert que Bernard et moi avions pas mal de choses en commun sur la façon dont nous préférons construire des logiciels, et j'ai aussi appris que bmg tourne en production dans Klaro et dans d'autres projets. Après quelques échanges, j'ai eu la chance de pouvoir travailler sur Klaro — et d'apprendre bmg bien plus à fond. L'usage de bmg est particulièrement pertinent dans le contexte de Klaro, puisque Klaro est au fond une base de données qui donne à des utilisateurs ordinaires une part du pouvoir qu'offre l'algèbre relationnelle aux programmeurs : voir les données sous quantité d'angles différents. Mais c'est le sujet d'un autre billet.

À retenir

Prenez toujours des notes
Contacter les gens à froid est un bon moyen d'avancer dans le monde, surtout si vous vous intéressez à leurs bibliothèques open source obscures
L'algèbre relationnelle est bonne pour vous, pour le monde, et pour votre carrière
LEGO®