Est la violation du principe DRY toujours mauvais?

Question

J'ai discuté sur DRY (Don't Repeat Yourself) principe est également connu comme DIE (Duplication Est le Mal) et il y a des votes, qu'une simple répétition de code est toujours un mal. Je voudrais connaître votre opinion sur les points suivants:

1. Avenir incertain. Disons, que nous avons le même code en deux endroits. La clé est que ces deux endroits ont seulement accessoires de la connotation. Il y a une possibilité, qu'ils varient dans l'avenir, en raison de leur contexte et de la sémantique sont différents. Faire abstraction de ces lieux n'est pas pas cher, et si l'un de ces lieux de changement, de déballage de l'abstraction sera encore plus cher.
2. La lisibilité. Il y a un calcul complexes qui impliquent plusieurs variables ou des étapes. Dans un autre endroit du code, il en est une autre, qui ont certaines parties identiques. Le problème, c'est que si nous prenons les parties communes, la lisibilité de calcul va diminuer et créé l'abstraction sera très difficile de lui donner un nom descriptif. Pire, si une partie de l'algorithme qui va changer dans l'avenir comme dans le point 1.

Le cas ci-dessus sont une bonne raison d'abandonner processus d'abstraction et il suffit de laisser le code dupliqué en faveur de risque de futurs changements ou tout simplement de la lisibilité?

Answer 1

Ceux-ci sont tout à fait valables raisons de violer SÈCHE. Je me dois d'ajouter un troisième: la performance. C'est rarement une grosse affaire, mais il peut faire une différence, et l'abstraction risque de ralentir les choses.

En fait, je vais ajouter un quatrième: de perdre du temps et, potentiellement, d'introduire de nouveaux bogues en modifiant les deux (ou plus) parties d'une base de code qui pourrait déjà être fonctionne correctement. Vaut-il le coût de trouver comment faire abstraction de ces choses si vous n'avez pas et il ne sera probablement pas enregistrer tout ou beaucoup de temps dans l'avenir?

Généralement, le code dupliqué n'est pas l'idéal, mais il y a certainement des raisons impérieuses de l'autoriser, dont probablement d'autres raisons que ce que l'OP et me l'ont suggéré.

Answer 2

Oui, certaines duplications de code sont notoirement difficiles à prendre sans les rendre la lisibilité bien pire. Dans de telles situations, je laisse un TODO dans les commentaires comme un rappel qu'il ya un certain chevauchement, mais au moment de l'écriture, il semble préférable de le laisser comme ça.

Habituellement ce qui se passe est ce que vous écrivez dans votre premier point, les duplications divergent et ne sont plus les duplications. Il arrive aussi que la duplication est un signe d'un problème de conception, mais il ne devient clair plus tard.

Longue histoire courte: essayez d'éviter les doubles emplois; si la duplication est notoirement difficiles à prendre et au moment de la rédaction inoffensif, il suffit de laisser un commentaire, comme un rappel.

---

Voir aussi 97 Choses à Chaque Programmeur Doit Savoir:

p. 14. Méfiez-vous de la Partager par Udi Dahan

Le fait que les deux sauvagement les différentes parties du système effectuée à une certaine logique de la même manière conduit à moins que je ne le pensais. Jusqu'à ce que je l'ai eu ces les bibliothèques de code partagé, ces pièces n'étaient pas dépendants les uns des autres. Chaque pourrait évoluer de façon indépendante. Chacun pouvait changer sa logique pour répondre aux besoins de la système de changement de l'environnement des affaires. Ces quatre lignes de code similaires ont été accidentelle-temporelle de l'anomalie, d'une coïncidence.

Dans ce cas, il a créé dependece entre les deux parties du système qui ont été mieux rester indépendant. La solution a été essentiellement la duplication.

Answer 3

Essayons de comprendre pourquoi la SEC est important, et puis on peut comprendre d'où la rupture de la règle est raisonnable:

SEC devrait être utilisé pour éviter la situation où les deux morceaux de code sont conceptuellement à faire le même travail, donc à chaque fois que vous modifiez le code dans un seul endroit, vous devez changer le code à l'autre endroit. Si la même logique est en deux endroits distincts, alors vous devez toujours vous rappeler de changer la logique dans les deux endroits, ce qui peut être source d'erreurs. Cela peut s'appliquer à n'importe quelle échelle. Il peut être une application complète qui est dupliqué ou il peut être une valeur constante. Il ne peut également pas être n'importe quel code à répétition, il peut juste être une répétition de ce principe. Vous devez vous demander "Si je devais faire un changement dans un endroit, je serais forcément besoin de faire un équivalent de changement quelque part d'autre?". Si la réponse est "oui", alors le code est en train de violer SÈCHE.

Imaginez que vous avez une ligne comme ceci dans votre programme:

cost = price + price*0.10 // account for sales tax

et quelque part d'autre dans votre programme, vous avez une ligne similaire:

x = base_price*1.1; // account for sales tax

Si les changements de taxe de vente, vous allez avoir besoin de changer à la fois de ces lignes. Il n'y a presque pas de code à répétition ici, mais le fait que si vous apportez une modification dans un endroit, il nécessite un changement dans un autre lieu est ce qui rend le code SÈCHE pas. Ce qui est plus, il peut être très difficile de se rendre compte que vous avez à faire le changement dans les deux endroits. Peut-être que votre unité de tests de l'attraper, mais peut-être pas, afin de se débarrasser de la duplication est important. Peut-être que vous feriez le facteur de la valeur de la taxe de vente séparée en une constante qui peut être utilisé dans plusieurs endroits:

cost = price + price*sales_tax;
x = base_price*(1.0+sales_tax);

ou peut-être créer une fonction d'abstraction encore plus:

cost = costWithTax(price);
x = costWithTax(base_price);

De toute façon, il est très probable à être en vaut la peine.

Alternativement, vous pouvez avoir un code qui ressemble beaucoup, mais n'est-ce pas violer SEC:

x = base_price * 1.1; // add 10% markup for premium service

Si vous deviez changer la façon dont la taxe de vente est calculé, vous ne voulez pas modifier la ligne de code, de sorte qu'il n'est pas en répétant à toute logique.

Il y a aussi des cas où le fait d'avoir à faire le même changement dans de multiples lieux de est bien. Par exemple, vous avez peut-être un code comme ceci:

a0 = f(0);
a1 = f(1);

Ce code n'est pas SÈCHE en quelques manières. Par exemple, si vous modifiez le nom de la fonction f, vous aurez à changer deux endroits. Vous pourriez peut-être rendre le code plus SEC par la création d'une petite boucle et en tournant a dans un tableau. Toutefois, cette duplication n'est pas une grosse affaire. Tout d'abord, les deux modifications sont très proches, et si la modification accidentelle de l'un sans changer l'autre est peu probable. Deuxièmement, si vous êtes dans un langage compilé, puis le compilateur sera très probablement le problème de toute façon. Si vous n'êtes pas dans un langage compilé, puis j'espère que vos tests unitaires attraper.

Il y a beaucoup de bonnes raisons pour faire de votre code SEC, mais il y a de nombreuses bonnes raisons de ne pas également.

Answer 4

Le génie est tout au sujet de compromis, donc il n'y a pas d'avis définitif ou motif de conception qui est valable pour tous les problèmes. Certaines décisions sont plus difficiles à justifier que d'autres (la répétition de code est l'un d'entre eux), mais si les pros de la répétition du code emportent sur ses inconvénients dans votre situation, d'aller pour elle.

Answer 5

Il n'y a pas d'absolu, il est toujours va être un jugement d'appel entre le moindre de deux maux. Généralement, SÈCHE gagne et vous devez être prudent de pentes glissantes lorsque vous commencez à la violer, mais votre raisonnement semble bien pour moi.