Je suis sûr qu'il y a un nom pour cet anti-modèle quelque part; cependant je ne connais pas assez la littérature anti-modèle pour la connaître.
Considérez le scénario suivant:
or0
est une fonction membre d'une classe. Pour le meilleur ou pour le pire, cela dépend fortement des variables des membres de la classe. Le programmeur A vient et a besoin de fonctionnalités comme or0
mais plutôt que d'appeler or0
, le programmeur A copie et renomme toute la classe. Je suppose qu'elle n'appelle pas or0
parce que, comme je l'ai dit, cela dépend fortement des variables membres pour sa fonctionnalité. Ou peut-être qu'elle est programmeur junior et ne sait pas comment l'appeler à partir d'un autre code. Alors maintenant, nous avons or0
et c0
(c pour copie). Je ne peux pas blâmer complètement le programmeur A pour cette approche - nous respectons tous des délais serrés et nous piratons le code pour faire le travail.
Plusieurs programmeurs maintiennent or0
donc c'est maintenant la version orN
. c0
est maintenant une version cN
. Malheureusement, la plupart des programmeurs qui ont maintenu la classe contenant or0
semblaient ignorer complètement c0
- ce qui est l'un des arguments les plus forts auxquels je puisse penser pour la sagesse du principe DRY. Et il peut également y avoir eu une maintenance indépendante du code dans c
. De toute façon, il semble que or0
et c0
ont été maintenus indépendants les uns des autres. Et, joie et bonheur, une erreur se produit cN
qui ne se produit pas orN
.
J'ai donc quelques questions:
1.) Y a-t-il un nom pour cet anti-modèle? J'ai vu cela se produire si souvent que j'aurais du mal à croire que ce n'est pas un anti-modèle nommé.
2.) Je peux voir quelques alternatives:
a.) Correction orN
pour prendre un paramètre qui spécifie les valeurs de toutes les variables membres dont il a besoin. Modifiez ensuite cN
pour appeler orN
avec tous les paramètres nécessaires transmis.
b.) Essayez de porter manuellement les correctifs de orN
à cN
. (Attention, je ne veux pas faire ça mais c'est une possibilité réaliste.)
c.) Recopiez orN
à - encore une cN
fois, beurk mais je l'énumère par souci d'exhaustivité.
d.) Essayez de comprendre où cN
est cassé puis réparez-le indépendamment de orN
.
L'alternative a semble être la meilleure solution à long terme, mais je doute que le client me laisse la mettre en œuvre. Jamais de temps ou d'argent pour réparer les choses mais toujours du temps et de l'argent pour réparer le même problème 40 ou 50 fois, non?
Quelqu'un peut-il suggérer d'autres approches que je n'ai peut-être pas envisagées?