Les pièges du DRY : Pourquoi ne pas assécher votre code trop tôt

Dans le monde de la programmation, le principe DRY (Don’t Repeat Yourself) est souvent prôné comme une norme incontournable. Ce principe stipule qu’il ne faut pas répéter plusieurs fois les mêmes morceaux de code, mais plutôt les abstraire dans des fonctions ou des classes réutilisables. Cependant, l’application trop zélée de ce principe peut parfois mener à des désastres plus grands que ceux qu’il cherche à éviter. L’objectif de DRY est de réduire les redondances, mais il est crucial de se rappeler que la simplification et la lisibilité ne doivent jamais être sacrifiées sur l’autel de l’abstraction. Comme les commentaires des utilisateurs le soulignent, forcer le DRY trop tôt transforme souvent des projets gérables en casse-têtes quasi incompréhensibles.

Un problème majeur dans l’application prématurée de DRY est qu’il peut entraîner des abstractions incorrectes ou inutiles. **Znkr** note avec amertume que, dans ses dix ans d’expérience, il a souvent ressenti les douleurs causées par des projets où le DRY était appliqué sans une réflexion suffisante. La consolidation du code est facile, mais le démantèlement de ces consolidations est beaucoup plus laborieux. La complexité de retirer une abstraction lorsque les exigences commencent à diverger est souvent monumentale par rapport à écrire des sections de code légèrement répétées mais indépendantes.

def set_deadline(deadline):
  if deadline <= datetime.datetime.now():
    raise ValueError('Le délai doit être dans le futur!')

par rapport à :

class DeadlineSetter:
  def __init__(self, deadline):
    if deadline <= datetime.datetime.now():
      raise ValueError('Le délai doit être dans le futur!')

L’exemple ci-dessus montre comment une abstraction apparemment innocente peut complexifier inutilement le code. **PaulHoule** donne un exemple frappant où de simples méthodes d’encodage et de décodage ont dû être corrigées parce que des développeurs avaient peur d’utiliser `btoa` directement en JavaScript. Cette peur de la répétition a conduit à des méthodes incohérentes et mal appliquées à travers le code, augmentant le potentiel d’erreur et rendant les tests plus difficiles.

**Lpapez** souligne qu’avec les langages dynamiques, il est encore plus important d’éviter les abstractions prématurées car elles peuvent facilement devenir opaques. La navigation dans des classes service DRY sans types explicites peut devenir un cauchemar. Heureusement, l’industrie a reconnu les avantages du typage statique, mais il est toujours crucial de garder le contrôle des abstractions, aussi simples qu’elles paraissent au départ. Avant de extraire ce qui semble être un morceau de code commun, demandez-vous si ces sections doivent vraiment évoluer dans la même direction ou si leur convergence actuelle est juste une coïncidence.

Le fond du problème réside souvent dans la distorsion de l’intention du DRY lui-même. **Swatcoder** remarque pertinemment que le DRY vise à prévenir les erreurs de **pied-pistolet** où une modification dans un endroit oublie inconsciemment un autre endroit similaire. Cependant, lorsque cette logique est poussée trop loin, elle devient inextricablement liée à des optimisations prématurées. Une approche plus réfléchie serait de maintenir la duplication jusqu’à ce qu’il y ait une nécessité prouvée et claire pour une abstraction.

Une autre façon de rendre le code plus DRY est de se concentrer sur la