- Il s’agit d’un échange sur la conception logicielle entre Robert « Uncle Bob » Martin et John Ousterhout, mené de septembre 2024 à février 2025
- Tous deux ont écrit des ouvrages sur le design logiciel
- Ils ont montré des divergences de vue sur trois grands sujets : la longueur des méthodes, les commentaires et le Test-Driven Development
- Le cœur de la discussion porte sur la manière de réduire la complexité du code, d’en améliorer la lisibilité et de rédiger des tests de façon appropriée
Longueur des méthodes
- Uncle Bob (ci-après UB) insiste sur la position suivante : « les fonctions courtes sont préférables, et si possible il faut les découper davantage »
- Une méthode ne doit faire qu’une seule « chose » (
One Thing)
- Mais appliqué de façon trop extrême, cela peut conduire à une décomposition excessive (
over-decomposition)
- John souligne qu’à l’inverse, des méthodes trop petites rendent plus difficile la compréhension du flux global
- Quand les méthodes « peu profondes » (
shallow) se multiplient, il faut toutes les parcourir pour comprendre une seule fonctionnalité
- L’interdépendance entre méthodes (
entanglement) augmente, ce qui alourdit la lecture du code
- Exemple de
PrimeGenerator
- Le code d’origine d’UB était découpé en environ 8 petites méthodes, et leur enchevêtrement le rendait difficile à comprendre
- La version de John rassemblait le tout dans une seule méthode, avec suffisamment de commentaires pour permettre de saisir le flux d’ensemble d’un seul coup d’œil
- UB a lui aussi reconnu dans une certaine mesure qu’il y avait eu « décomposition excessive »
- En conclusion, les deux reconnaissent l’importance du découpage du code, mais l’essentiel est de trouver un équilibre entre « trop morceler » et « laisser des blocs trop gros »
Commentaires
- UB considère les commentaires comme un « mal nécessaire » (
necessary evil)
- Il estime qu’ils risquent de ne pas être mis à jour, ou de contenir des informations erronées
- Il préfère rendre l’intention aussi visible que possible dans le code, quitte à utiliser des noms très longs si nécessaire
- John affirme au contraire que les commentaires sont indispensables
- Expliquer clairement en anglais le but d’une interface (méthode) ou l’intention de l’implémentation évite aux autres développeurs de perdre du temps à fouiller inutilement dans le code
- Selon lui, « le plus dangereux, c’est une situation où il n’y a pas de commentaires et où il faut interpréter soi-même le code »
- En reprenant
PrimeGenerator comme exemple, John souligne qu’il est très difficile à comprendre s’il n’y a pas de commentaires expliquant « pourquoi l’algorithme fonctionne ainsi »
- UB estime que « si les commentaires ne sont pas exacts, ils peuvent faire plus de mal que de bien », tandis que John considère que « l’absence de commentaires est encore plus nuisible que de mauvais commentaires »
- Tous deux s’accordent dans une certaine mesure sur le fait qu’il faut un niveau de commentaire adapté à l’équipe et au contexte, mais dans l’ensemble John accorde beaucoup plus de valeur aux commentaires
Refactoring de PrimeGenerator par John
- John a restructuré un code initialement divisé en 8 méthodes en une méthode unique, ou en 2 à 3 méthodes
- Il a ajouté des commentaires riches aux endroits nécessaires pour expliquer « pourquoi l’implémentation est faite de cette manière »
- À l’aide des commentaires, il décrit à la fois l’intention des variables principales (
multiples, primes) et le fonctionnement de l’algorithme, afin d’accélérer la compréhension du code
- UB a indiqué que ce code non plus n’était pas totalement intuitif
- Même pour expliquer un algorithme complexe, il faut encore du temps, et l’auteur lui-même a éprouvé des difficultés au moment de le revoir
Refactoring de PrimeGenerator2 par Bob
- Il s’agit d’une version légèrement modifiée par UB du code de John
- Il a séparé quelques méthodes supplémentaires pour appliquer un « refactoring ultérieur »
- Cela a amélioré la lisibilité dans la partie boucle, mais a temporairement entraîné une baisse de performances
- John a souligné que « découper en méthodes trop petites peut poser des problèmes de performances », et UB a de nouveau modifié le code pour améliorer ces performances
- Toutefois, en raison de la préférence d’UB pour des « commentaires minimaux », John maintient qu’« ajouter davantage d’explications facilite toujours la compréhension »
Test-Driven Development
- UB recommande activement la méthode TDD, qui consiste à écrire d’abord des tests sur des cycles courts, puis à ajouter petit à petit le code nécessaire pour faire passer les tests en échec
- Il affirme que cette approche permet de conserver en permanence une couverture de test et d’éviter les débogages complexes
- Selon lui, le code est refactoré fréquemment et devient progressivement plus propre
- John craint que le TDD ne dérive vers une approche trop « tactique »
- Il fait remarquer que « la conception devrait venir d’abord, alors que le TDD pousse à écrire d’abord le code (une implémentation minimale pour les tests) »
- Il estime qu’une bonne conception consiste à réfléchir d’un coup à un périmètre un peu plus large, puis à rédiger les tests de manière groupée (
bundling) pour ce code
- UB reconnaît qu’il peut y avoir des problèmes dus à une mauvaise application du TDD, mais soutient que, bien pratiqué, il aide à la couverture de test et à la refonte du code (
refactoring)
- John exprime la crainte que « pour les débutants, le TDD augmente au contraire le risque que le code devienne vite désordonné »
- Au final, les deux s’accordent sur le fait que « le TDD comme l’approche
bundling, s’ils sont bien appliqués, peuvent tous deux produire un excellent code », mais leurs préférences restent différentes
Mot de la fin
- John :
- Il craint que
Clean Code mette trop l’accent sur le découpage en fonctions très petites et sur la limitation des commentaires, au risque que les lecteurs suivent cela de manière extrême
- Si les commentaires ne sont pas suffisamment présents, le code devient difficile à comprendre, et au final les développeurs y consacrent davantage de temps
- Il souligne aussi que le TDD peut faire perdre de vue la conception d’ensemble
- UB :
- Il explique avoir apporté certaines corrections dans la 2e édition de
Clean Code, en y intégrant en partie les remarques de John
- Tout en respectant la diversité des expériences et des points de vue, il insiste sur leur point commun : au final, tout le monde doit viser un code propre et facile à maintenir
- En conclusion, les deux accordent la priorité à l’importance de la conception logicielle et au fait de « rendre le code facile à lire »
- Ils divergent toutefois sur les critères de découpage des méthodes, l’usage des commentaires et l’ordre de rédaction des tests
- L’essentiel est de trouver le bon équilibre selon l’environnement de l’équipe et la structure du code, et de poursuivre continuellement l’amélioration de la conception
14 commentaires
J’ai plusieurs livres de la série Clean, mais j’ai l’impression qu’ils sont surtout utiles comme repères à un niveau métacognitif. Quand on les traite comme des principes ou des lois, ça devient extrêmement fatigant, et ce n’est pas non plus très pratique. C’est toujours Uncle Bob qui parle des principes SOLID… mais, personnellement, je ne trouve pas qu’il y ait tant de contenu vraiment pratique que ça.
À mon avis, Code Complete et Clean Code se partagent la première place des livres les plus surévalués.
Une traduction de The Philosophy of Software Design est-elle sortie ? J’ai cherché, mais je n’ai rien trouvé.
C’est paradoxal, mais pour apprendre à écrire du bon code, un livre ironique du genre « comment coder de façon à rendre la maintenance difficile » serait sans doute plus parlant qu’un livre qui explique simplement ce qu’est un bon code.
Ces temps-ci, j’ai l’impression de m’être davantage disputé avec des gens qui sont fans d’une stack technique ou d’une architecture donnée et qui parlent comme si c’était la catastrophe si on ne l’adoptait pas, qu’à propos du clean code. Il faut l’appliquer selon le contexte ; j’ai l’impression qu’il n’existe rien de bon à tous les coups.
Belle discussion.
En y repensant, moi aussi je recommande The Philosophy of Software Design de John aux juniors, mais je n’ai pas particulièrement recommandé Clean Code.
Je pense qu’il est important de ne pas suivre aveuglément n’importe quel titre, mais de bien comprendre le contexte et de l’appliquer.
Je pense que les livres de développement personnel appliqués au code peuvent convenir aux débutants qui n’ont pas encore de point de vue sur la technique ou les méthodes d’implémentation, mais que leur utilité diminue à mesure que l’expérience s’accumule. Il n’existe pas non plus de vérité absolue valable pour tous les projets et tous les environnements, et il arrive que les généralités ne s’appliquent pas. Comme pour les conseils des livres de développement personnel dans d’autres domaines, il semble préférable de garder une certaine distance, de n’appliquer que les conseils adaptés au contexte et de ne pas les poursuivre aveuglément.
Je me reconnais un peu plus dans ce que dit John.
L’essentiel n’est probablement pas de suivre aveuglément les propos de l’un ou de l’autre comme un dogme, mais de comprendre pourquoi ils disent cela et d’avancer à partir de là.
Il ne faut pas oublier que le clean code n’est pas un objectif, mais un moyen.
Comme toujours, l’important, c’est de garder la mesure.
C'est instructif 👍🏻
Avis Hacker News
Certaines personnes peuvent être très dogmatiques sur des sujets précis. Je ne comprends pas pourquoi on accepte ces idées comme un évangile
Quand on a connu un projet qui suit aveuglément les recommandations d’Uncle Bob, on comprend à quel point leur valeur est limitée
Clean Code est simplement un des outils dans la boîte à outils d’un bon ingénieur logiciel
Certaines personnes se contentent de regrouper des lignes proches entre elles et appellent ça du « refactoring », au lieu d’extraire une fonction quand elle est réutilisée ou quand cela a un sens logique
Il y a un cas important qui n’a pas été mentionné concernant l’importance des commentaires
Je recommande vivement "A Philosophy of Software Design"
C’était une réaction aux vrais problèmes de l’industrie logicielle avant le mouvement Clean Code
L’avis de Bob sur les commentaires est étrange
On finit par dépasser les livres d’Uncle Bob avec le temps
Il y a aussi un reproche à faire au nom Clean Code