Pourquoi il ne faut pas supprimer la duplication de code trop tôt
- Appliquer le principe DRY (Don't Repeat Yourself) de manière trop stricte peut provoquer une abstraction « prématurée », ce qui peut compliquer les changements futurs
- Il faut se demander si la duplication est réellement inutile, ou s’il s’agit de fonctionnalités qui évolueront indépendamment avec le temps
- Même si des fonctions ou des classes semblent identiques, elles peuvent relever de contextes et d’exigences métier différents
- Au lieu de simplement raccourcir le code, il faut se demander si l’objectif de la fonction restera pertinent dans le temps
- Le risque de l’abstraction : si une fonctionnalité est susceptible d’évoluer différemment, l’abstraction peut au contraire être nuisible
- Lorsqu’on conçoit une abstraction, il ne faut pas coupler trop tôt des comportements qui pourraient évoluer séparément à long terme
- En cas de doute, il vaut mieux garder les comportements séparés jusqu’à ce qu’un schéma commun suffisant apparaisse avec le temps pour justifier leur couplage
- À petite échelle, il peut être plus simple de gérer la duplication que de résoudre la complexité introduite par une abstraction prématurée
- Au début du développement, il vaut mieux tolérer un peu de duplication et attendre avant d’abstraire
- Les besoins futurs sont souvent imprévisibles
- Il faut réfléchir au principe YAGNI (You Aren't Gonna Need It)
- La duplication ne posera peut-être pas de problème, ou montrera clairement avec le temps la nécessité d’une abstraction mûrement réfléchie
10 commentaires
À l’origine, le principe DRY devrait s’appliquer lorsqu’il y a effectivement de la répétition, afin de la réduire,
mais si l’on pense au code d’abord à travers ce critère, cela me semble être une mauvaise application de DRY.
Parmi les avis sur Hacker News,
l’idée qui me parle le plus est celle-ci : mauvaise compréhension du principe DRY : DRY vise à éviter la duplication d’informations/de connaissances, et non la duplication de code. Se concentrer uniquement sur la duplication de code peut conduire à une optimisation inutile.
Cette opinion est celle qui me parle le plus.
On ne se pose pas souvent ce genre de question pendant les périodes de transition ? Comme il n’existe pas de code parfait, se creuser la tête en permanence fait sans doute partie de notre métier. J’ai l’impression que ça dépend des cas.
On voit revenir assez souvent ces derniers temps des billets qui portent un regard sceptique sur les structures très fortement abstraites.
MSA, clean code, SOLID, DRY, etc.
J’ai l’impression que les gens commencent à ressentir une certaine fatigue vis-à-vis de ce genre de termes.
En réalité, ce ne sont que des repères à garder en tête quand on réfléchit à écrire du code facile à lire, facile à comprendre, sans fuite mémoire, sans erreur, et performant...
Il suffit de les appliquer avec mesure, en les adaptant bien à la réalité métier dans laquelle on se trouve actuellement.
https://velog.io/@kineo2k/…
C’est un excellent article.
Je pense que c’est encore plus important lors du passage d’un modèle waterfall à un modèle agile.
On est en agile, mais on essaie trop de prédire l’avenir.
À partir de quand est-on « trop pressé » ?
La réponse est très simple. Si vous le faites dès le départ, c’est simplement « prématuré ».
La question un peu plus difficile est de savoir à partir de quand cela ne l’est plus.
C’est un jeu de mots, mais si on ne le fait tout simplement pas dès le départ, alors ce ne sera pas « trop hâtif » ^^;
Oui, surtout en Agile
Avis Hacker News
Application précoce du principe DRY : Il est préférable d’appliquer le principe DRY dès le départ. Utiliser une base de code commune est plus efficace que de traiter séparément des données similaires.
Priorité des bonnes pratiques : Toutes les bonnes pratiques ne se valent pas. Il est important de privilégier la lisibilité et la cohésion. Écrire du code consiste à choisir les pratiques les plus adaptées.
Mauvaise compréhension du principe DRY : DRY vise à éviter la duplication d’informations ou de connaissances, pas simplement la duplication de code. Se focaliser uniquement sur le code dupliqué peut mener à des optimisations inutiles.
Problème de réutilisabilité : Il arrive qu’une fonctionnalité donnée ne soit pas réutilisable dans d’autres contextes. Une meilleure approche est nécessaire pour éviter les doublons de travail.
Problème des solutions DRY complexes : Du code répétitif peut parfois être préférable à une solution DRY complexe. Appliquer DRY trop vite peut entraîner des problèmes structurels inattendus.
DRY n’est pas une bonne pratique en soi : La répétition est souvent le signal qu’une abstraction est nécessaire. Une application irréfléchie de DRY est une erreur fréquente chez les ingénieurs intermédiaires.
Exemple simple de code : Deux fonctions peuvent être fusionnées en une seule. Il est important d’expliquer clairement les avantages et les inconvénients d’un refactoring.
Problèmes de maintenance du code DRY : Le code DRY peut devenir complexe et difficile à maintenir. À l’inverse, le code WET est plus simple, mais ses changements sont plus prévisibles.
Effets secondaires du principe DRY : Le principe DRY peut complexifier une base de code et la rendre plus difficile à maintenir. Certains livres sur le clean code ont eu un impact négatif sur l’industrie.
Généralisation et performance : La généralisation peut avoir un impact négatif sur les performances. Du code dupliqué adapté à des motifs de données spécifiques peut aider à optimiser les performances.