Utilisation de modèles différents pour des fonctionnalités similaires

Je suis le seul développeur d'un projet qui, comme tout projet logiciel, pourrait être repris par quelqu'un d'autre à l'avenir.

Disons que j'ai utilisé le modèle X pour implémenter la fonctionnalité A. Après avoir développé et terminé la fonctionnalité, je me rends compte que je pouvais implémenter la même fonctionnalité en utilisant le modèle Y, que je viens d'apprendre. Mais la fonctionnalité A fonctionne bien, et la refactorisation de X en Y prend du temps et donne peu d'avantages.

Ensuite, il est temps d'implémenter la fonctionnalité B. C'est similaire à A, mais cette fois, je veux profiter de cette occasion pour jouer avec le motif Y. Je suis content du résultat final, mieux que lorsque je fais la fonctionnalité A, mais maintenant mon code utilise deux différents modèles, X et Y, pour des caractéristiques similaires.

Mais il n'y a pas vraiment de raison d'utiliser des modèles différents, à l'exception du fait que lors de la création de la fonctionnalité, l'IA n'était pas suffisamment compétente pour utiliser le même modèle que pour la fonctionnalité B.

Notez que cette question ne concerne pas le choix du bon modèle pour un problème donné ; il s'agit de deux modèles coexistants dans la base de code pour résoudre des problèmes similaires, qui pourraient être réduits à un seul compte tenu du temps nécessaire pour refactoriser.

• Cette odeur de code?
• Quels sont les inconvénients de conserver le code source comme ceci?
• Dois-je m'en tenir à utiliser un seul motif? ie refactor A pour utiliser Y ou continuer à utiliser X lors de l'écriture de B?
• Comment, dans la source, puis-je communiquer que la raison pour laquelle il existe deux modèles différents pour des fonctionnalités similaires n'est essentiellement pas une raison?
• Suis-je trop inquiet de ce que le prochain développeur pense de mon code?

Si les modèles X et Y résolvent le même problème et qu'aucun n'est objectivement meilleur, alors vous devriez en choisir un et vous y tenir. Si cela est possible, vous devez vous efforcer de résoudre le même problème de la même manière de manière cohérente.

Vous ne vous inquiétez pas trop, c'est plutôt une odeur de code sérieuse que vous devez absolument gérer et nettoyer.

Les inconvénients d'avoir différentes solutions au même problème dans une base de code:

• il faudra deux fois plus de temps pour comprendre le code
• il faudra deux fois plus de temps pour modifier le code lorsque vous modifiez une partie du comportement impliquant le modèle
• vous aurez deux fois plus de bugs
• vos collègues actuels et futurs vous détesteront

Je suis d'accord avec la réponse de JacquesB . J'ajouterais, en répondant à d'autres de vos questions, que si en ce moment vous avez les deux modèles coexistant, et que vous n'avez pas (encore) le temps de refactoriser votre application pour utiliser celle que vous avez trouvée la meilleure, vous devriez mettre que dans vos commentaires dans la classe "fautive" (celle à refactoriser). De cette façon, il est évident pour le futur développeur (vous ou quelqu'un d'autre) qu'il y a encore une dette à payer.

Enfin, le principal inconvénient de maintenir une base de code comme celle-ci est la complexité supplémentaire, mais inutile. Vous voulez définitivement éviter à tout prix une complexité inutile!

Ne jouez pas dans la base de code. Écrire des prototypes fait que vous pouvez trouver les avantages et les inconvénients d'un modèle / design par rapport aux autres.

Il peut s'avérer que ce que l'on ressent intuitivement peut être réduit, peut en fait être plus complexe que d'avoir 2 modèles différents.

Attendez-vous à jeter une grande partie du code développé pour le prototype.

Que ce soit ou non une odeur de code dépend vraiment de la similitude des problèmes A et B. La réponse de JacquesB semble supposer qu'ils sont très similaires, et que si vous changez le problème A (pour corriger un bug par exemple), vous devrez également changer le problème B en même temps. JaqueB pourrait avoir raison, mais il pourrait également arriver que A et B changent indépendamment, car ils ne sont pas tous similaires. Dans cette situation, il est peu probable que vous ayez décrit les inconvénients.

D'après votre description, cela ressemble à une odeur de code (duplication), mais il est difficile de dire à quel point l'odeur est puante. Par exemple, si A utilise la méthode de modèle et B utilise la stratégie, les deux problèmes peuvent être très différents malgré les modèles de mise en miroir utilisés. Je voudrais attendre et voir l'approche. Dans le cas où le problème C survient et que c'est comme A et B, je refactoriserais A pour être cohérent avec B, puis créer C devrait être très simple. S'il y a un bogue dans A, je voudrais également le refactoriser pour qu'il corresponde à B, puis corriger le bogue. Dans le cas où rien ne change alors ... cela n'a pas d'importance n'est-ce pas?

Avoir plusieurs façons de résoudre des problèmes similaires dans une base de code est une réalité. Même dans le cas où vous êtes le seul développeur, vous allez apprendre de nouvelles choses et avoir de nouvelles perspectives, donc vos solutions changeront. Comme vous le reconnaissez correctement, vous devez corriger ces imperfections tout en apportant de la valeur. Reconcevoir (ce que vous faites vraiment lorsque vous changez un modèle) un code qui ne changera plus jamais ne fournit pas de valeur. La seule vraie façon de savoir que ça va changer est d'avoir à faire le changement, c'est pourquoi j'attendrais un problème C.

Non, vous pouvez utiliser plusieurs modèles dans une seule base de code.

Cependant, si vous implémentez un composant et que vous exposez une façon de l'utiliser qui suit un modèle, il est probablement préférable de s'en tenir à celui-ci. Supposons, par exemple, que j'utilise le modèle de générateur pour mon client de requête REST, mais que j'implémente différemment l'une des ressources. Cela va dérouter les gens.