A Philosophy of Software Design

1La complexité a une définition, et elle est sournoise

Ousterhout refuse de parler de complexité « en général ». Il la définit : tout ce qui rend un système difficile à comprendre et à modifier. Elle se manifeste de trois façons :

• La modification en chaîne : changer la couleur d'une bannière oblige à éditer chaque page qui la recopie.
• La charge cognitive : tout ce qu'un développeur doit garder en tête pour toucher une ligne sans rien casser.
• Les inconnues inconnues (le pire) : vous ne savez même pas quel bout de code il faudrait modifier, vous le découvrez quand le bug apparaît.

Deux causes seulement nourrissent tout ça : les dépendances et l'obscurité. Et le constat qui fait mal : « la complexité est plus visible pour le lecteur que pour celui qui écrit » (p. 9). Celui qui pond le code ne la sent pas ; celui qui le reprend, si.

2Un bon module est profond

C'est l'idée centrale du livre, et le contre-pied le plus net à Clean Code. Un module profond, c'est beaucoup de fonctionnalité derrière une interface simple : « les meilleurs modules sont ceux dont l'interface est bien plus simple que l'implémentation » (p. 22). L'exemple parfait : les cinq appels d'entrée-sortie d'Unix (open, read, write, lseek, close). Cinq signatures triviales qui cachent des centaines de milliers de lignes (permissions, caches disque, ordonnancement, pilotes).

À l'inverse, un module peu profond (shallow) a une interface presque aussi compliquée que ce qu'il fait : il vous coûte en apprentissage sans rien vous épargner. Ousterhout met un nom sur la maladie : la « classite » (classitis), la croyance que « les classes c'est bien, donc plus de classes c'est mieux ». Empiler des mini-classes d'une méthode chacune ne simplifie rien, ça ajoute des interfaces à apprendre. Voilà pourquoi il s'oppose frontalement au culte de la petite fonction.

3Tactique contre stratégique : méfiez-vous du tornado

Faire marcher le code ne suffit pas. Le programmeur tactique se concentre sur la prochaine fonctionnalité, livre vite, et accumule de la complexité à chaque raccourci. Le programmeur stratégique considère que le bon design EST l'objectif, pas un bonus.

Ousterhout décrit une figure que tout le monde a croisée : le « tornado tactique », ce développeur ultra-productif qui pond du code plus vite que tout le monde, adulé par le management, et qui laisse derrière lui « un sillage de destruction » que les autres passeront des mois à nettoyer. Sa recommandation : investir 10 à 20 % de votre temps dans le design en continu. Parce que la dette technique, contrairement à la dette bancaire, n'est presque jamais remboursée.

4Cacher l'information, ne pas la découper dans le temps

La meilleure façon d'obtenir des modules profonds : l'information hiding, un principe que David Parnas posait déjà en 1972. Chaque module encapsule une décision de design qui n'apparaît pas dans son interface (le format d'un fichier, un protocole réseau, une structure d'arbre).

L'erreur inverse, c'est la décomposition temporelle : structurer le code selon l'ordre d'exécution. Vous lisez un fichier, vous le modifiez, vous le réécrivez, donc vous créez trois classes Lecture, Traitement, Écriture. Sauf que la classe qui lit et celle qui écrit doivent toutes les deux connaître le format du fichier. La même décision se retrouve dans deux endroits : c'est une fuite (information leakage), « l'un des red flags les plus importants du design » (p. 31). Le jour où le format change, vous éditez deux classes au lieu d'une. La bonne réponse : un seul module qui connaît le format, point.

5Tirez la complexité vers le bas

Face à une complexité inévitable, deux choix : la gérer dans le module, ou la repousser sur tous ceux qui l'utilisent. Ousterhout tranche : « il est plus important pour un module d'avoir une interface simple qu'une implémentation simple » (p. 61). Autrement dit, « mieux vaut que les développeurs souffrent que les utilisateurs » (p. 63) : une seule équipe encaisse la difficulté à l'intérieur, plutôt que mille appelants la subissent dehors.

Exemple concret, en code :

# ✗ complexité POUSSÉE dehors : chaque appelant doit deviner la valeur
client = Client(retry_interval=0.5)   # 0.5 ? 2 ? personne ne sait régler ça

# ✓ complexité TIRÉE dedans : le module mesure les temps réels et décide
client = Client()                     # interface nue, une équipe gère, mille appelants soulagés

6Faites disparaître les erreurs

L'idée la plus originale et la plus sous-estimée du livre. La gestion d'exceptions est « l'une des pires sources de complexité ». La meilleure parade n'est pas de mieux les attraper : c'est de redéfinir la sémantique pour que l'erreur n'existe plus.

Son propre aveu : en concevant le langage Tcl, il avait fait que supprimer une variable inexistante lève une erreur. Résultat, tout le monde entourait l'appel d'un catch pour l'ignorer. La bonne définition : « garantir que la variable n'existe plus ». Avec ça, supprimer une variable absente devient normal, l'erreur a disparu. Même logique pour substring en Java, qui lève une exception si l'index dépasse la longueur, vous forçant à écrire des vérifications partout. Python a choisi l'inverse : une tranche hors limites renvoie simplement un résultat vide. Pas d'exception, pas de code de garde, une méthode plus profonde.

// Java : lève IndexOutOfBoundsException, à blinder de checks
"hi".substring(0, 10);   // 💥 exception

# Python : tranche hors limites = résultat vide, aucune erreur
"hi"[0:10]               # → "hi"

7Le clash frontal avec Clean Code

C'est là que les deux livres s'affrontent. Ousterhout cite Robert Martin mot à mot : « la première règle des fonctions, c'est qu'elles doivent être petites. La deuxième, c'est qu'elles doivent être plus petites que ça. » Sa réponse : passé une certaine taille, raccourcir encore n'aide plus personne.

// ✗ trop découpé : on ne comprend pas l'une sans sauter à l'autre
function lirePrix(c) { return c.prix }          // "méthodes siamoises"
function avecTVA(c)  { return lirePrix(c) * 1.2 }

// ✓ une fonction "profonde" : autonome, lisible d'un seul bloc
function prixTTC(c)  { return c.prix * 1.2 }

Des fonctions trop découpées perdent leur indépendance et deviennent des méthodes siamoises (conjoined methods : on ne peut plus en comprendre une sans lire l'autre), ce qui est pire qu'une seule fonction un peu longue. Sa formule : « la profondeur compte plus que la longueur ».

Même bagarre sur les commentaires. Martin écrit « les commentaires sont toujours des échecs » ; Ousterhout, lui, est un défenseur acharné du commentaire, parce qu'il capture ce que le code ne peut pas dire : l'abstraction, l'intention, le pourquoi. Il se moque de la solution de Martin (remplacer un commentaire par un nom de méthode très long), qui finit par produire des noms comme isLeastRelevantMultipleOfNextLargerPrimeFactor.

Il va plus loin : écrivez les commentaires en premier, avant le code. Pas pour la doc, comme outil de conception. Si un commentaire devient long et pénible à écrire, c'est « le canari dans la mine » : le signe que votre abstraction est mauvaise.

8Les opinions qui fâchent, et la liste de red flags

Le chapitre le plus polémique passe les modes au crible d'une seule question : est-ce que ça réduit la complexité ? Le verdict est tranchant. Contre le Test-Driven Development (sauf pour corriger un bug) : « il concentre l'attention sur faire marcher des fonctionnalités précises, pas sur trouver le meilleur design. C'est de la programmation tactique pure ». Contre les getters et setters, « des méthodes peu profondes qui encombrent l'interface sans rien apporter ». Méfiance envers les design patterns, dont le vrai danger est la sur-application : ne forcez pas un problème dans un pattern quand une solution maison serait plus propre.

Et surtout, le cadeau pratique du livre : sa liste de red flags, applicable dès demain en revue de code :

• module peu profond ;
• fuite d'information ;
• décomposition temporelle ;
• méthode tunnel (pass-through) ;
• méthodes siamoises ;
• commentaire qui répète le code ;
• nom vague ;
• code non évident.

Quand l'un de ces signaux apparaît, arrêtez-vous : il y a probablement un problème de design caché derrière.