Cet article est une adaptation en français de AHA Programming de Kent C. Dodds.
Merci à lui pour cette découverte.
This article is a French adaptation of AHA Programming by Kent C. Dodds.
Thanks to him for sharing this insight.
DRY
DRY (un acronyme pour "Don't Repeat Yourself") est un principe de programmation bien connu que Wikipedia résume ainsi :
Dans un système, toute connaissance doit avoir une représentation unique, non ambiguë, faisant autorité.
C’est en général une bonne pratique à laquelle j’adhère (même si, dans mon cas, je la suis avec un peu moins de dogmatisme que ne le suggère cette définition).
Le plus gros problème que j’ai rencontré avec la duplication de code (aussi appelée copier-coller — l’antithèse de
DRY) est le suivant : on découvre un bug à un endroit, on le corrige, puis on réalise que le même bug existe ailleurs… et il faut tout recommencer.Une fois, j’ai repris une base de code qui abusait de la duplication, et j’ai dû corriger un même bug à huit endroits différents ! 😱
Frustration garantie. Extraire ce code dans une fonction, appelée partout où nécessaire, aurait clairement changé la donne.
WET
On rencontre aussi un autre concept, parfois appelé programmation
WET, qui signifie "Write Everything Twice" (Écrire chaque chose deux fois). C’est tout aussi dogmatique… et beaucoup trop prescriptif. Conlin Durbin définit ça ainsi :Vous pouvez vous demander deux fois « N'ai-je pas écrit cela avant ? » mais jamais trois.
Dans cette même base de code évoquée plus haut, il y avait une sur‑abstraction encore plus nocive que la duplication.
C’était du code AngularJS. Pour plusieurs contrôleurs, le code passait
this à une fonction qui “monkey‑patchait” méthodes et propriétés sur this afin d’enrichir l’instance du contrôleur avec certaines capacités. Une sorte de pseudo‑héritage, j’imagine.
Résultat : c’était extrêmement confus, difficile à suivre, et j’avais peur de toucher à cette partie du code.Le code était réutilisé à bien plus de trois endroits… mais l’abstraction était mauvaise. Avec le recul, j’aurais préféré que ce code soit dupliqué plutôt que de devoir subir cette complexité.
AHA 💡
AHA (prononcé « Aha ! », comme lorsqu’on vient de faire une découverte) est un acronyme que j’ai reçu de Cher Scarlett. Il signifie :Avoid Hasty Abstractions (Éviter les abstractions hâtives)
Ma façon de voir ce principe est très bien résumée par Sandi Metz qui écrit :
Préférer la duplication à la mauvaise abstraction
C’est une pépite de sagesse. Je vous invite à relire cette phrase, puis à lire l’article complet de Sandi sur le sujet : The Wrong Abstraction.
Il est excellent.
J’aimerais aussi ajouter un principe connexe important :
Optimiser pour le changement en premier
La clé, c’est que nous ne savons pas à quoi ressemblera l’avenir du code. On peut passer des semaines à optimiser pour les performances, ou à concevoir “la meilleure API” pour une nouvelle abstraction, pour découvrir dès le lendemain que nos hypothèses étaient fausses : l’API doit être refondue, ou la fonctionnalité n’est plus nécessaire.
En réalité, on ne peut pas en être certain. La seule chose dont on puisse être vraiment sûr, c’est que les choses vont probablement changer. Et si elles ne changent jamais, on ne touchera pas au code de toute façon… alors à quoi bon trop se soucier de son apparence ?
Attention : je ne prône pas l’anarchie. Je dis simplement qu’il faut garder en tête que nous ne savons pas vraiment quelles exigences notre code devra satisfaire à l’avenir.
Donc oui, je suis favorable à la duplication… jusqu’à ce que vous soyez suffisamment sûr des cas d’usage de ce code dupliqué. Qu’est‑ce qui change d’un endroit à l’autre ? Quelles différences feraient de bons paramètres ? Après quelques occurrences, les points communs vous “crieront” qu’une abstraction est nécessaire — et vous serez alors dans le bon état d’esprit pour la concevoir.
Si vous faites des abstractions trop tôt, vous risquez de croire que votre fonction ou composant est “parfait” pour votre besoin. Et au lieu d’adapter votre design, vous allez tordre le code pour qu’il colle à ce nouveau cas d’usage. Puis un autre, puis un autre… jusqu’à ce que l’abstraction devienne, en pratique, toute l’application, au milieu d’une forêt de
if et de boucles 😂😭Il y a quelques années, j’ai été embauché pour examiner la base de code d’une entreprise. J’ai utilisé un outil appelé jsinspect pour détecter les blocs copiés‑collés et leur montrer des opportunités d’abstraction. Il y avait énormément de duplication, et de mon point de vue, les abstractions possibles sautaient aux yeux.
Le grand enseignement de la programmation « AHA », c’est qu’il ne faut pas être dogmatique sur le moment où commencer à écrire des abstractions. Il vaut mieux attendre que l’abstraction s’impose : quand “ça semble juste”, et sans avoir peur de dupliquer tant que vous n’en êtes pas là.
Conclusion
Une approche mesurée et pragmatique des principes de programmation est essentielle. C’est pourquoi je préfère
AHA à DRY ou WET : AHA vous aide à rester vigilant face aux abstractions, sans imposer de règles rigides sur le moment où il est “acceptable” d’extraire du code dans une fonction ou un module.J’espère que cela vous sera utile. Si vous vous sentez piégé dans de mauvaises abstractions, rassurez‑vous : Sandi donne d’excellentes étapes pour en sortir.
Il ne vous reste plus qu’à lire son article.
Bonne chance !