Le clean code n’existe pas
(steveonstuff.com)- Les gens s’efforcent d’écrire du code « propre », mais « propre » n’est pas une mesure utile
- Le code ne peut pas simplement être « propre ». Parce que « propre » ne décrit en réalité rien du code
- Quand les gens disent qu’un code est propre, c’est généralement parce qu’il est excellent d’une manière ou d’une autre
Le clean code est-il vraiment du bon code ?
-
Le code peut être excellent pour de nombreuses raisons
→ lisible, facile à comprendre, simple, performant, sûr, élégant, testable, encapsulé, extensible, maintenable, réutilisable... -
Mais ces caractéristiques sont, à certains égards, en tension les unes avec les autres
→ le code le plus simple n’est probablement pas le plus facile à tester
→ les interfaces et les dépendances injectées facilitent les tests, mais s’éloignent de la simplicité
→ utiliser beaucoup de singletons peut faciliter la compréhension, sans pour autant produire une application maintenable -
Certaines de ces qualités sont fondamentalement opposées, et il peut donc être difficile de toutes les satisfaire en même temps
→ l’ingénierie est affaire de trade-offs, donc il peut être utile d’en discuter en équipe
Si un code est excellent, il faut expliquer « pourquoi »
- Quand quelqu’un dit qu’une solution est « propre », il ne rationalise souvent pas la raison et se contente de dire que c’est un meilleur choix
- Pour avoir une discussion constructive sur une solution technique, il faut pouvoir expliquer clairement pourquoi une solution est meilleure qu’une autre
→ au lieu de simplement dire « c’est propre », dire plutôt « c’est découplé, facile à comprendre, facile à tester... »
Il faut utiliser des termes précis
- Le développement est généralement un sport d’équipe. Quand on code seul, on peut faire comme on veut, mais lorsqu’on travaille en équipe, il faut discuter des idées
- Utiliser un langage précis pour parler de solutions techniques et partager une compréhension commune dans toute l’équipe est essentiel pour bien se comprendre
- L’expression « clean code » signifie des choses différentes selon les personnes
→ pour certains, cela veut dire une architecture bien définie ; pour d’autres, un code simple avec un formatage cohérent - Des mots comme « encapsulé », « testable » ou « réutilisable » ont un sens sur lequel nous pouvons tous nous accorder
- Quand nous utilisons des termes plus spécifiques pour décrire les propriétés du code, nous pouvons être certains d’être sur la même longueur d’onde
- « Propre » a à peu près le même niveau de précision que « bien »
Alors, qu’est-ce que le « clean code » ?
-
J’en suis arrivé à la conclusion que, lorsque je décris un code comme « propre », cela signifie souvent : « ce code est bon, mais je ne suis pas tout à fait sûr de pouvoir expliquer pourquoi »
→ ou bien je connais les raisons pour lesquelles ce code est bon, mais je ne trouve pas les mots précis pour l’exprimer -
Développer cette intuition est une bonne chose, mais il ne faut pas s’arrêter là. Il faut creuser davantage pour comprendre « pourquoi ce code est bon »
→ ce code a-t-il des propriétés que d’autres n’ont pas ? Et ces propriétés conviennent-elles le mieux à notre projet ? Il est possible que ce ne soit finalement pas la bonne solution -
J’aimerais que nous puissions être certains que nous n’avons pas besoin de clean code, mais de ______ code
6 commentaires
Merci pour ce très bon article ~~
Ne maltraite pas le code legacy à la légère
Toi, à qui as-tu déjà réussi à satisfaire ne serait-ce qu'une première requirement ?
Je suis d’accord.
Il me semble que, dans « ce livre », le clean code dont parle l’auteur mettait l’accent sur deux aspects parmi ceux-ci : « facile à comprendre » et « testable ». Bien sûr, je pense que ce sont tous les deux des critères très importants. Mais il arrive qu’on utilise ce qu’on appelle un « hack » à cause de spécifications encore non formalisées ou de bibliothèques inachevées, et dans ce genre de cas, il semble inévitable de renoncer en partie à la qualité du code pour préserver la qualité du programme.
Je partage cet avis. Si l’on considère que « propre » signifie « de haute qualité », alors, comme le disait Weinberg, la qualité est quelque chose qui a de la valeur pour quelqu’un, donc je pense qu’il est nécessaire d’avoir au sein de l’équipe des critères et une définition de la qualité.
C’est un article qui défend l’idée qu’au lieu de parler vaguement de « clean code », il faut dire précisément de quoi l’on parle.
À ce sujet, il y a aussi eu diverses discussions sur Hacker News autour de l’interprétation de « clean code ». N’hésitez pas à lire les commentaires également.
There’s No Such Thing as Clean Code https://news.ycombinator.com/item?id=30111516
Le sujet est un peu différent, mais vous pouvez aussi consulter l’article ci-dessous, publié auparavant.