Philosophie de l'ingénierie : Linus Torvalds, le cas particulier qui disparaît

Points clés

• Le bon goût, c’est lorsque le cas particulier disparaît. Remodelez la structure de données — un pointeur vers un pointeur plutôt qu’un simple pointeur — et le if du cas limite n’a plus nulle part où exister.
• « Montrez-moi le code » est une épistémologie, pas un slogan. Une conception est une hypothèse ; seul le code qui s’exécute tranche le débat.
• git fait de la distribution une conséquence de sa structure de données. Des objets adressés par leur contenu signifient que tout dépôt est l’égal des autres : « la seule copie véritable » n’existe donc jamais et n’a pas à être défendue.
• À grande échelle, la confiance doit être structurée, pas présumée. Torvalds a résolu le problème deux fois — un arbre de mainteneurs pour savoir qui est responsable, un historique infalsifiable pour savoir ce qui s’est passé.

Le principe

« Je veux que vous compreniez que parfois on peut voir un problème sous un autre angle et le réécrire de sorte qu’un cas particulier disparaisse et devienne le cas normal, et ça, c’est du bon code. » — Linus Torvalds, TED, 2016¹

Torvalds se tenait sur une scène TED, deux fonctions C côte à côte sous les yeux. Toutes deux supprimaient une entrée d’une liste chaînée simple. La première parcourait la liste avec un pointeur prev, vérifiait si l’entrée à supprimer était la tête, puis se ramifiait : cas particulier pour la tête, cas général pour tout le reste. Dix lignes, un if. La seconde fonction parcourait la liste avec un pointeur vers un pointeur — **indirect — de sorte que la tête n’était plus du tout un emplacement particulier. Elle n’était que la première chose vers laquelle le pointeur-vers-un-pointeur se trouvait pointer. Quatre lignes, aucun if.¹

Réduire le nombre de lignes n’a jamais été l’enjeu. La condition de la première version n’existait que parce que le programmeur modélisait la tête de la liste comme distincte du reste. Choisissez une meilleure structure de données — un pointeur vers un pointeur plutôt qu’un simple pointeur — et la différence s’évapore. Le cas limite n’était jamais inhérent au problème ; c’était un artefact de la façon dont le problème avait été représenté. Le goût, au sens où l’entend Torvalds, est exactement ce geste, et c’est la même conviction qui fait du goût un système technique plutôt qu’une préférence esthétique : la version élégante l’emporte non parce qu’elle est plus jolie, mais parce qu’elle est plus correcte, ayant moins d’endroits où se tromper.

Cet instinct — éliminer le cas particulier pour que le cas limite n’ait plus où se cacher — traverse tout ce que Torvalds a construit. Il explique aussi pourquoi son autre phrase célèbre se lit moins comme un manifeste que comme une consigne : « Les paroles ne coûtent rien. Montrez-moi le code. »²

Essayez ci-dessus : supprimez un nœud du milieu, puis supprimez la tête dans chaque mode. Dans « la façon évidente », la tête déclenche la branche if (!prev) ; dans « le bon goût », la tête n’est qu’un lien parmi d’autres, et la même ligne unique la gère.

Contexte

Linus Benedict Torvalds est né à Helsinki, en Finlande, en 1969, dans une famille de langue suédoise. Étudiant en informatique à l’université d’Helsinki, il faisait tourner Minix, un petit système d’exploitation de type Unix écrit par le professeur néerlandais Andrew Tanenbaum comme outil pédagogique. Minix était instructif mais délibérément limité — Tanenbaum le gardait simple pour que les étudiants puissent en lire l’intégralité. Torvalds voulait plus que ce à quoi il avait droit.

Le 25 août 1991, il publia sur le groupe Usenet comp.os.minix : « Je fais un système d’exploitation (gratuit) (juste un passe-temps, ça ne sera pas gros et professionnel comme gnu) pour les clones AT 386(486). »³ La réserve entre parenthèses est l’erreur de jugement la plus citée de l’histoire du logiciel.

Le passe-temps est devenu, selon toute mesure de déploiement, le noyau le plus exécuté sur Terre — il fait tourner la majorité des serveurs web, chaque téléphone Android et l’écrasante majorité des infrastructures cloud et de supercalcul.

L’architecture fut contestée dès le départ. Début 1992, Tanenbaum ouvrit un fil intitulé « LINUX is obsolete », soutenant qu’un noyau monolithique constituait « un pas de géant en arrière vers les années 1970 » et que les micro-noyaux — où le système d’exploitation est décomposé en services isolés communiquant par messages — étaient l’avenir.⁴ Torvalds concéda que les micro-noyaux étaient supérieurs « d’un point de vue théorique et esthétique », puis poursuivit la construction du noyau monolithique parce qu’il fonctionnait, qu’il était rapide et qu’il était livré. Le débat est resté dans les mémoires comme l’acte fondateur d’un tempérament : la théorie cède face à un système qui tourne.

L’œuvre

Le noyau Linux (1991-) : un monolithe qui a passé l’échelle

Linux est un noyau monolithique : ordonnanceur, gestionnaire de mémoire, systèmes de fichiers et pilotes de périphériques s’exécutent tous dans un unique espace d’adressage privilégié. La critique de Tanenbaum n’était pas fausse en théorie — une défaillance dans un pilote monolithique peut faire tomber le système, là où un micro-noyau peut l’isoler. La réponse de Torvalds était empirique. Le monolithe était plus rapide, plus simple à écrire, et pouvait être modifié par des milliers de contributeurs sans que chacun d’eux ait à apprendre au préalable un protocole de messagerie. L’architecture qui avait perdu le débat académique a remporté la guerre du déploiement parce qu’elle abaissait le coût de la contribution.

Le noyau est aujourd’hui l’un des plus vastes artefacts d’ingénierie collaborative jamais réalisés — des dizaines de millions de lignes, des milliers de contributeurs par version. Rien de cette échelle n’a été conçu d’avance. Elle s’est accumulée, un correctif fusionné à la fois, sous un modèle de développement que Torvalds a lui aussi dû inventer.

Le modèle des mainteneurs : la confiance comme un arbre

Torvalds ne lit pas la majeure partie du code qui entre dans Linux. Il ne le peut pas — le volume dépasse de loin les capacités d’une seule personne. Le noyau est plutôt gouverné par une hiérarchie de confiance. Les mainteneurs de sous-systèmes sont responsables de leurs domaines. Ils relisent les correctifs, les intègrent dans leurs arbres et envoient des demandes de fusion vers le haut, aux lieutenants puis, en définitive, à Torvalds, qui fusionne les arbres auxquels il fait confiance. Il est le dictateur bienveillant à la racine, mais sa véritable tâche consiste à choisir qui il croit, et non à auditer chaque ligne qu’ils produisent.

L’arbre des mainteneurs est une architecture sociale, et il affronte le problème auquel toute chaîne d’approvisionnement logicielle moderne est confrontée : on ne peut pas tout vérifier personnellement, alors la confiance doit être structurée plutôt que présumée. C’est la raison pour laquelle un dépôt ne devrait pas voter sur sa propre fiabilité et pour laquelle l’open source n’est pas une frontière de sécurité — les regards ne servent que si quelqu’un est responsable de regarder. La liste de diffusion, avec ses relectures d’une franchise célèbre, est le mécanisme qui rend l’arbre de confiance lisible : les décisions et leurs justifications sont publiques, archivées et attribuables.

git (2005) : la confiance distribuée comme structure de données

Pendant des années, le noyau a été développé à l’aide de BitKeeper, un système propriétaire de gestion de versions distribuée dont l’éditeur accordait au projet un usage gratuit. En 2005, cet arrangement s’est effondré dans un conflit de licence, et Torvalds s’est retrouvé soudain sans outil capable de gérer le flux de travail du noyau.⁵ Il en a donc écrit un. Le premier commit de git date du 7 avril 2005 ; en une dizaine de jours environ, il s’auto-hébergeait et gérait le noyau.⁶

Ce qui fait de git l’expression du même principe que l’exemple de la liste chaînée, c’est sa structure de données fondamentale. git ne stocke pas des diffs pour reconstruire l’état. Chaque version de chaque fichier, chaque arborescence de répertoires, chaque commit est stocké comme un objet nommé par le hachage SHA-1 de son propre contenu — un stockage adressé par contenu. Torvalds est explicite : le hachage « n’a jamais concerné la sécurité. Il s’agissait de détecter la corruption ».⁶ L’identité est le contenu : deux fichiers ayant les mêmes octets sont automatiquement le même objet, et un seul bit inversé produit un nom différent et devient détectable. Et parce que « chaque dépôt est identique et égal », il n’existe aucun serveur central privilégié — le cas particulier de « la seule copie véritable » disparaît de la même façon que le cas particulier de « la tête de la liste ».⁶ La distribution n’est pas une fonctionnalité greffée sur git ; c’est une conséquence du choix de la bonne structure de données.

Cette dernière propriété — une chaîne infalsifiable de commits adressés par contenu — est ce qui permet au graphe de commits de porter un sens au-delà du code, et c’est pourquoi je conçois la session comme le message de commit : l’historique est l’artefact, et non un sous-produit de celui-ci.

La méthode

La méthode de Torvalds est un pragmatisme imposé par les preuves. « Les paroles ne coûtent rien. Montrez-moi le code » était une réponse littérale, sur la liste de diffusion du noyau, à quelqu’un qui décrivait ce que son correctif ferait.² Une conception est une hypothèse ; le correctif est l’expérience. Tant que le code n’existe pas et ne s’exécute pas, le débat n’est pas tranché.

En dessous se trouve sa formulation la plus précise de l’endroit où réside réellement le jugement d’ingénieur : « Les mauvais programmeurs se soucient du code. Les bons programmeurs se soucient des structures de données et de leurs relations. »⁷ L’exemple de la liste chaînée est cette phrase rendue concrète. Si la structure de données est juste, le code qui opère dessus est court et compte peu de branches, parce que la structure a déjà absorbé la complexité. Si la structure de données est mauvaise, on le paie à jamais en cas particuliers — en instructions if qui n’existent que pour masquer un mauvais modèle. Se soucier du code, c’est traiter les symptômes. Se soucier de la structure de données, c’est le remède.

La méthode de gouvernance reflète la méthode technique. Le modèle du dictateur bienveillant et de ses lieutenants existe moins pour concentrer l’ego que pour maintenir la décision de fusion responsable devant un goût unique, tout en répartissant le travail de relecture entre les personnes les plus proches de chaque sous-système. Et la brutalité de ses relectures de code — qui, de son propre aveu ultérieur, a parfois basculé dans une dureté inutile — vient de la même racine : le code est jugé sur le fait qu’il est juste, non sur celui qui l’a écrit ni sur l’effort qu’il représente. Le critère est impersonnel, même quand la manière de le formuler ne l’était pas.

Chaîne d’influence

Qui l’a façonné

Andrew Tanenbaum et Minix. Minix était le système d’exploitation sur lequel Torvalds a appris et la chose qu’il cherchait à dépasser. Tanenbaum lui a fourni un système de type Unix lisible à étudier et, à travers le débat « LINUX is obsolete », un contradicteur assez tranchant pour clarifier exactement ce à quoi Torvalds tenait : un système qui est livré plutôt qu’une architecture qui satisfait. (Influence formatrice)⁴

Unix et les outils GNU. Linux est un Unix par sa filiation de conception — processus, fichiers, tubes, l’abstraction « tout est un fichier ». Et il n’était utile que parce que le compilateur, le shell et les utilitaires du projet GNU existaient déjà pour s’exécuter par-dessus ; Torvalds a porté bash et gcc avant que le noyau ne puisse faire grand-chose.³ Il a construit la seule pièce manquante — le noyau — et a laissé les pièces existantes faire le reste. Construisez ce dont vous avez besoin ; réutilisez ce qui marche. (Influence directe)

Qui il a façonné

Tout le monde de l’open source. Linux a prouvé qu’un hybride mondialement distribué, mêlant bénévoles et entreprises, pouvait surpasser en ingénierie des équipes propriétaires à la plus grande échelle, et le modèle des mainteneurs est devenu le modèle de référence pour la gestion des grands projets ouverts.

Tous les systèmes de gestion de versions distribuée qui ont suivi. git n’a pas seulement gagné — il est devenu le substrat. GitHub, GitLab et le flux de travail moderne des demandes de fusion sont tous bâtis sur le modèle distribué, adressé par contenu, que Torvalds a choisi en ces dix jours. La structure de données a survécu à l’urgence qui l’avait fait naître.

Le fil conducteur

John Carmack et Torvalds parviennent au même endroit depuis des spécialités opposées. Carmack presse un problème jusqu’à ce que l’algorithme et le matériel s’emboîtent sans rien gaspiller ; Torvalds remodèle un problème jusqu’à ce que la structure de données fasse s’évanouir le cas particulier. Tous deux traitent la performance et l’élégance comme une même propriété vue sous des angles différents, et tous deux refusent de laisser la théorie l’emporter sur une chose qui tourne de façon démontrable. Le bon goût, tout au long de cette série, ne signifie jamais décoration ; il signifie une justesse que l’on peut ressentir. (Pont de série)

Ce que j’en retiens

La leçon de la liste chaînée est celle vers laquelle je reviens le plus souvent. Quand le code fait pousser un if pour gérer « le premier » ou « le cas vide » ou « l’utilisateur administrateur », cette branche est généralement l’aveu que le modèle de données est légèrement faux. Le correctif est rarement un meilleur if. C’est une meilleure représentation, après quoi la branche n’est plus nécessaire parce que le cas contre lequel elle protégeait ne peut plus se produire. C’est la défense la moins coûteuse possible : un cas limite qui ne peut pas exister n’a besoin d’aucun code pour être géré.

La seconde leçon porte sur la confiance à grande échelle, et c’est celle qui compte le plus dans le monde où je construis désormais — les systèmes d’agents, où l’on orchestre un travail que l’on n’a pas écrit ligne par ligne. Torvalds a résolu le même problème deux fois : socialement, avec un arbre de mainteneurs qui structure qui est responsable, et techniquement, avec l’historique adressé par contenu de git qui rend ce qui s’est passé infalsifiable. On ne peut pas plus lire tout ce qu’un agent produit que Torvalds ne peut lire chaque correctif du noyau. Alors on fait ce qu’il a fait — rendre la confiance structurelle et l’historique vérifiable — et c’est exactement pourquoi je traite le goût comme une infrastructure et la chaîne d’approvisionnement comme la surface d’attaque. La discipline qui a fait d’un passe-temps un noyau est la même discipline qui permet à une base de code d’accélérer au lieu de se dégrader : trouvez la bonne structure, et les cas particuliers cessent de se multiplier.

FAQ

Quelle est la définition du « bon goût » dans le code selon Linus Torvalds ?

Dans son entretien TED de 2016, Torvalds a défini le bon goût à l’aide de deux implémentations de la suppression d’un élément dans une liste chaînée. La version qu’il a qualifiée de sans goût utilisait une instruction if pour traiter en cas particulier la suppression de la tête de la liste ; la version qu’il a qualifiée de bon code utilisait un pointeur-vers-un-pointeur, de sorte que la tête n’était plus du tout un cas particulier. Son résumé : « parfois on peut voir un problème sous un autre angle et le réécrire de sorte qu’un cas particulier disparaisse et devienne le cas normal, et ça, c’est du bon code. »¹

Qu’a créé Linus Torvalds ?

Torvalds a créé le noyau Linux, qu’il a annoncé pour la première fois sur le groupe comp.os.minix le 25 août 1991, et qui est aujourd’hui le noyau de système d’exploitation le plus largement déployé au monde. En 2005, il a également créé git, le système de gestion de versions distribuée, après que le projet Linux eut perdu l’accès à l’outil propriétaire BitKeeper. Il demeure le mainteneur principal du noyau Linux.³⁵

Pourquoi Linus Torvalds a-t-il construit git, et combien de temps cela a-t-il pris ?

Le projet Linux avait utilisé BitKeeper, un système propriétaire de gestion de versions distribuée, jusqu’à ce qu’un conflit de licence en 2005 mette fin à l’accès gratuit du projet. Torvalds a écrit git en remplacement, avec un premier commit le 7 avril 2005 et un outil gérant le noyau en une dizaine de jours environ — même s’il précise avoir passé des mois auparavant à en réfléchir la conception.⁵⁶

Que signifie « Les paroles ne coûtent rien. Montrez-moi le code. » ?

Torvalds a publié cette phrase sur la liste de diffusion du noyau Linux le 25 août 2000, en réponse directe à une discussion sur ce que ferait un certain code.² Elle résume son pragmatisme : la description d’une approche n’est qu’une hypothèse, et le débat n’est tranché que lorsqu’un code fonctionnel existe et peut être exécuté et testé. (À noter : la phrase apparentée « avec assez de regards, tous les bugs sont superficiels » est la loi de Linus telle que formulée par Eric Raymond, et non une citation de Torvalds lui-même.⁸)

Sources