Selon Dan Maksimovich, il ne faut pas appliquer prématurément les principes DRY (Ne vous répétez pas) aux codes. L'application trop rigide des principes DRY conduit à des abstractions prématurées qui rendent les changements futurs plus complexes que nécessaire.Ne vous répétez pas (don’t repeat yourself en anglais, aussi désigné par l’acronyme DRY) est une philosophie en programmation informatique consistant à éviter la redondance de code au sein d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière.
La philosophie DRY est explicitée par la phrase suivante, formulée par Andy Hunt et Dave Thomas dans leur livre The Pragmatic Programmer : "Dans un système, toute connaissance doit avoir une représentation unique, non ambiguë, faisant autorité". Les auteurs appliquent ce principe pour inclure les bases de données, les plans de tests, le système de construction logiciel et même la documentation logicielle.
Lorsque le principe DRY est bien appliqué, la modification d'un élément d'un système ne change pas les autres éléments non liés logiquement. De plus, tous les éléments liés logiquement changent uniformément, de manière prévisible et restent synchronisés. En utilisant les méthodes et les sous-routines dans leur code, Thomas et Hunt se reposent sur les générateurs de code source, les systèmes de construction automatique, et les langages de scripts pour respecter le principe DRY à travers les diverses étapes de construction d'un logiciel.
Cette philosophie prévaut dans l'architecture dirigée par les modèles, dans lequel les artefacts logiciels sont dérivés d'un modèle objet central décrit dans un langage tel qu'UML. Le code DRY est créé par transformation de données et les générateurs de code qui évitent au programmeur de copier-coller du code. Le code DRY facilite la maintenance de systèmes logiciels complexes, à partir du moment où les transformations de données sont faciles à créer et maintenir. Des outils tels que les annotations, XDoclet et XSLT sont des exemples de technique de codage DRY.
Un exemple de système requérant une duplication d'information sont les EJB 2.0 qui nécessitent une duplication d'information non seulement dans le code Java, mais aussi dans les fichiers de configuration. Des exemples de systèmes essayant de réduire la duplication d'information sont le framework web Django, Ruby on Rails et les EJB 3.0.
N'appliquez pas prématurément les principes DRY à votre code
Voici ce que Dan Maksimovich écrit sur la santé du code et l'application des principes DRY :
Nous sommes nombreux à avoir entendu parler des vertus de la méthode « Don't Repeat Yourself » ou DRY (ne pas se répéter). Faites une pause et réfléchissez : La duplication est-elle vraiment redondante ou la fonctionnalité devra-t-elle évoluer indépendamment au fil du temps ? Une application trop rigide des principes DRY conduit à des abstractions prématurées qui rendent les changements futurs plus complexes que nécessaire.
Examinez attentivement si le code est réellement redondant ou s'il n'est que superficiellement similaire. Même si les fonctions ou les classes se ressemblent, elles peuvent servir des contextes différents et répondre à des exigences commerciales qui évoluent différemment au fil du temps. Réfléchissez à la manière dont l'objectif des fonctions se maintient dans le temps, et ne vous contentez pas de raccourcir le code. Lors de la conception d'abstractions, ne couplez pas prématurément des comportements qui peuvent évoluer séparément à plus long terme.
Quand l'introduction d'une abstraction nuit-elle à notre code ? Considérons le code suivant :
L'approche de droite semble violer le principe DRY puisque les contrôles ValueError sont identiques par coïncidence. Cependant, les tâches et les paiements représentent des concepts distincts avec une logique potentiellement divergente. Si la date de paiement nécessitait ultérieurement une nouvelle validation, vous pourriez facilement l'ajouter au code de droite ; l'ajouter au code de gauche est beaucoup plus invasif.
En cas de doute, séparez les comportements jusqu'à ce que suffisamment de modèles communs émergent au fil du temps pour justifier le couplage. À petite échelle, il peut être plus simple de gérer la duplication que de résoudre la complexité d'une abstraction prématurée. Aux premiers stades du développement, il convient de tolérer un peu de duplication et d'attendre avant de procéder à l'abstraction.
Les exigences futures sont souvent imprévisibles. Pensez au principe « You Aren't Gonna Need It » ou YAGNI. Soit la duplication s'avérera être un non problème, soit avec le temps, elle indiquera clairement la nécessité d'une abstraction bien réfléchie.
Examinez attentivement si le code est réellement redondant ou s'il n'est que superficiellement similaire. Même si les fonctions ou les classes se ressemblent, elles peuvent servir des contextes différents et répondre à des exigences commerciales qui évoluent différemment au fil du temps. Réfléchissez à la manière dont l'objectif des fonctions se maintient dans le temps, et ne vous contentez pas de raccourcir le code. Lors de la conception d'abstractions, ne couplez pas prématurément des comportements qui peuvent évoluer séparément à plus long terme.
Quand l'introduction d'une abstraction nuit-elle à notre code ? Considérons le code suivant :
L'approche de droite semble violer le principe DRY puisque les contrôles ValueError sont identiques par coïncidence. Cependant, les tâches et les paiements représentent des concepts distincts avec une logique potentiellement divergente. Si la date de paiement nécessitait ultérieurement une nouvelle validation, vous pourriez facilement l'ajouter au code de droite ; l'ajouter au code de gauche est beaucoup plus invasif.
En cas de doute, séparez les comportements jusqu'à ce que suffisamment de modèles communs émergent au fil du temps pour justifier le couplage. À petite échelle, il peut être plus simple de gérer la duplication que de résoudre la complexité d'une abstraction prématurée. Aux premiers stades du développement, il convient de tolérer un peu de duplication et d'attendre avant de procéder à l'abstraction.
Les exigences futures sont souvent imprévisibles. Pensez au principe « You Aren't Gonna Need It » ou YAGNI. Soit la duplication s'avérera être un non problème, soit avec le temps, elle indiquera clairement la nécessité d'une abstraction bien réfléchie.
Et vous ?
Pensez-vous que cet avis est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
L'utilisation de l'assistant d'IA GitHub Copilot pour la programmation entraîne une baisse de la qualité globale du code et une quantité importante de code redondant, selon une étude 7 signes révélateurs d'un code illisible : Comment identifier et résoudre le problème « Un bon code est comme une lettre d'amour destinée au prochain développeur qui va le maintenir », estime Addy Osmani. L'ingénieur de Google montre les similitudes entre les deux 
