Ton cerveau ne ment pas : la science derrière le code propre

Écrire pour les humains, compiler pour les machines

Voilà le renversement complet en cinquante ans. Au départ, on rêvait de mesurer le code comme une pièce mécanique. On a fini par comprendre qu’il se transmet, d’un cerveau à un autre, avec toutes les limites que ça suppose.

Cela redéfinit ce qu’est un bon développeur. Son talent se mesure moins à l’astuce ou à la densité de son code qu’à la facilité avec laquelle un collègue pourra le reprendre, en respectant les contraintes bien réelles de la mémoire de travail humaine. Chaque niveau d’imbrication superflu est une dette prélevée sur l’attention de la prochaine personne qui ouvrira ce fichier.

Et ce n’est pas qu’une affaire de confort entre pairs. Les bugs ne se répartissent pas au hasard dans une base de code, ils s’agglutinent. Sur de grands systèmes industriels, Ostrand, Weyuker et Bell ont retrouvé une distribution de Pareto : environ 20 % des fichiers concentrent près de 80 % des défauts. Et ces foyers, d’autres travaux le montrent, sont souvent les recoins les plus complexes à lire.

Réduire la charge cognitive revient donc à s’attaquer en priorité à la part du code qui coûte le plus cher, en temps, en bugs et en heures perdues à déchiffrer. Et comme un programme qu’un seul cerveau tient en tête fait peser un risque sur toute l’équipe, la lisibilité cesse d’être une préférence individuelle pour devenir un enjeu collectif. En réalité, écrire du code est une activité sociale : tu codes toujours pour quelqu’un d’autre, même quand ce quelqu’un, c’est toi dans six mois.

Alors la prochaine fois qu’un bout de code te fera plisser les yeux, ne mets pas ça sur le compte du goût ou de l’habitude. Écoute le signal. La science te dit qu’il est juste.

Parce qu’au fond, coder proprement n’a jamais été une affaire de goût. C’est de l’empathie, rendue exécutable. Tu n’écris pas pour épater la machine, tu écris pour soulager un humain.