🚫
methodologie

DRY

Principe "Don't Repeat Yourself" : chaque concept doit avoir une seule representation dans le code.

Qu'est-ce que le principe DRY ?

DRY (Don't Repeat Yourself) est un principe de developpement logiciel formule par Andy Hunt et Dave Thomas dans leur livre "The Pragmatic Programmer" (1999). Il stipule que "chaque element de connaissance doit avoir une representation unique, non ambigue et faisant autorite au sein d'un systeme". En pratique, cela signifie eviter la duplication de logique, de donnees et de configuration.

Application du principe DRY

La duplication de code est la forme la plus visible : deux blocs de code identiques ou presque identiques. La solution est l'extraction dans une fonction, une classe ou un module reutilisable. La duplication de logique est plus subtile : deux blocs de code differents en surface mais implementant le meme concept metier. La duplication de donnees concerne les memes informations stockees a plusieurs endroits (schema de base de donnees et code de validation dupliques). La duplication de configuration survient quand les memes parametres sont repetes dans plusieurs fichiers.

Techniques pour appliquer DRY

Extraction de fonctions : identifier les blocs de code repetes et les isoler dans des fonctions nommees. Abstraction : creer des classes ou interfaces pour les concepts partages. Centralisation de la configuration : fichiers de constantes, variables d'environnement, fichiers de config centralises. Generation de code : schemas qui generent la validation, les types et la documentation (OpenAPI, Prisma, GraphQL codegen). Templates et generiques : code parametrable qui s'adapte a differents types de donnees.

Limites et pieges du DRY

Le DRY excessif est un piege courant. Deux morceaux de code qui se ressemblent ne representent pas forcement le meme concept. Forcer une abstraction prematuree pour eviter la duplication cree un couplage inapproprie : quand un des cas evolue differemment, l'abstraction devient un frein. La regle pratique : la duplication est acceptable tant qu'il n'y a pas trois occurrences (rule of three). Un code duplique mais simple est souvent preferable a une abstraction complexe et fragile.

DRY vs WET vs AHA

WET (Write Everything Twice / We Enjoy Typing) est l'anti-pattern de la duplication excessive. AHA (Avoid Hasty Abstractions), propose par Kent C. Dodds, recommande de preferer la duplication a une mauvaise abstraction. "Optimisez pour le changement d'abord, puis pour la duplication." L'objectif n'est pas zero duplication mais le bon equilibre entre reutilisation et simplicite. Le contexte determine le bon choix : dans une bibliotheque, DRY est crucial ; dans un script jetable, la duplication est acceptable.

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions frequentes

Quand est-il acceptable de dupliquer du code ?
Quand les deux occurrences representent des concepts metier differents qui evoluent independamment, quand une abstraction serait plus complexe que la duplication, quand il n'y a que deux occurrences (attendez la troisieme), et dans les tests (la lisibilite et l'independance des tests priment sur le DRY).
Le DRY s'applique-t-il aux tests unitaires ?
Avec moderation. Les tests doivent etre independants et lisibles. Trop de factorisation dans les tests (fixtures partagees, helpers abstraits) les rend fragiles et difficiles a comprendre. Privilegiez des tests explicites meme si cela implique une certaine repetition. Les fixtures de setup et les factories de donnees sont un bon compromis.

Pages liees

Chaque semaine, le meilleur de la tech francaise

Tendances, salaires, outils et opportunites — directement dans votre boite mail.

Gratuit. Desabonnement en un clic. Pas de spam.