Steve Smith, dans le livre 97 choses que tout programmeur devrait savoir, a écrit sur le thème du Don’t Repeat Yourself.

De tous les principes de la programmation, le Don’t Repeat Yourself (DRY) est peut-être l’un des plus fondamental. Le principe a été formulé par Andy Hunt et Dave Thomas dans The Pragmatic Programmer, et sous-tend de nombreuses autres bonnes pratiques de développement de logiciels. Le développeur qui apprend à reconnaître la répétition, et comprend comment l’éliminer par une pratique appropriée (ou une abstraction appropriée), peut produire un code beaucoup plus propre.

La duplication = gâchis

Chaque ligne de code qui entre dans une application doit être conservée et constitue une source potentielle de bogues futurs. La duplication gonfle inutilement la base de code, ce qui augmente les possibilités de bogues et ajoute une complexité accidentelle à l’application. Le gonflement que la répétition ajoute au projet rend également plus difficile, pour les développeurs travaillant sur le projet, la compréhension de l’ensemble du projet, voir même de s’assurer que les modifications apportées à un emplacement ne doivent pas nécessairement être effectuées ailleurs ils travaillent dessus. DRY exige que «chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté, faisant autorité au sein d’un système».

Répétition des appels de processus par l’automatisation

De nombreux processus de développement de logiciels sont répétitifs et facilement automatisable. Le principe DRY s’applique dans ces contextes, ainsi que dans le code source de l’application. Les tests manuels sont lents, sujets aux erreurs et difficiles à répéter, de sorte que les suites de tests automatisées doivent être utilisées dans la mesure du possible. L’intégration d’un logiciel peut prendre beaucoup de temps et être sujette à des erreurs si elle est effectuée manuellement. Par conséquent, un processus de génération doit être exécuté aussi souvent que possible, idéalement à chaque enregistrement. Partout où des processus manuels pénibles peuvent être automatisés, ils doivent être automatisés et normalisés. L’objectif est de s’assurer qu’il n’y a qu’un seul moyen d’accomplir la tâche, et c’est aussi indolore que possible.

Répétition dans les appels logiques pour l’abstraction

La répétition dans la logique peut prendre de nombreuses formes. Copier-coller la logique if-then ou switch-case est parmi les plus faciles à détecter et à corriger. De nombreux modèles de conception ont l’objectif explicite de réduire ou d’éliminer la duplication de la logique dans une application. Si un objet nécessite généralement plusieurs choses avant de pouvoir être utilisé, cela peut être accompli avec un modèle abstrait ou un modèle de méthode d’usine. Si un objet a de nombreuses variations possibles dans son comportement, ces comportements peuvent être injectés en utilisant le modèle de stratégie plutôt que de grandes structures if-then. En fait, la formulation des modèles de conception eux-mêmes est une tentative de réduire la duplication des efforts nécessaires pour résoudre des problèmes communs et discuter de ces solutions. En outre, DRY peut être appliqué aux structures, telles que le schéma de base de données, ce qui entraîne une normalisation.

Une question de principe

D’autres principes logiciels sont également liés à DRY. Le principe ‘Once and Only Once’, qui ne s’applique qu’au comportement fonctionnel du code, peut être considéré comme un sous-ensemble de DRY. Le principe ‘Open/Closed’, qui stipule que «les entités logicielles doivent être ouvertes pour extension, mais fermé pour modification», ne fonctionne qu’en pratique lorsque DRY est suivi. De même, le fameux principe de responsabilité unique, qui exige qu’une classe ait «une seule raison de changer», repose sur DRY. Lorsqu’il est suivi en termes de structure, de logique, de processus et de fonction, le principe DRY fournit des conseils fondamentaux aux développeurs de logiciels et facilite la création d’applications plus simples, plus faciles à maintenir et de meilleure qualité. Bien qu’il existe des scénarios où la répétition peut être nécessaire pour répondre aux performances ou à d’autres exigences (par exemple, la dénormalisation des données dans une base de données), il ne doit être utilisé que lorsqu’il traite directement un problème réel plutôt qu’un problème imaginaire.