Découplage vs YAGNI

Question

Est-ce qu'ils se contredisent?

Le découplage est une chose formidable et assez difficile à réaliser. Cependant, dans la plupart des applications, nous n'en avons pas vraiment besoin. Je peux donc concevoir des applications à couplage élevé et cela ne changera presque rien sauf des effets secondaires évidents tels que "vous ne pouvez pas séparer les composants", les tests unitaires sont pénibles. dans le cul " etc.

Qu'en penses-tu? Essayez-vous toujours de découpler et de gérer les frais généraux?

Answer 1

Il me semble que le découplage et YAGNI sont des vertus très complémentaires. (Je viens de remarquer la réponse de Rob et il semble que nous sommes sur la même page.) La question est de savoir combien de découplage vous devriez faire, et YAGNI est un bon principe pour vous aider à déterminer la réponse. (Pour ceux qui parlent de test unitaire - si vous devez vous découpler pour faire votre test unitaire, alors YAGNI ne s'applique évidemment pas.)

Je doute fort sincèrement des personnes qui disent "toujours" découpler. Peut-être qu'ils le font toujours à chaque fois qu'ils y pensent. Mais je n'ai jamais vu un programme où des couches supplémentaires d'abstraction ne pourraient pas être ajoutées quelque part, et je doute sincèrement qu'il existe un exemple non trivial d'un tel programme. Tout le monde trace une ligne quelque part.

D'après mon expérience, j'ai découplé le code et n'ai jamais profité de la flexibilité supplémentaire aussi souvent que j'ai laissé le code couplé et que j'ai ensuite dû revenir en arrière et le modifier plus tard. Je ne sais pas si cela signifie que je suis bien équilibré ou que je suis également divisé dans les deux sens.

Answer 2

YAGNI est une règle de base (pas une religion). Le découplage est plus ou moins une technique (ni une religion). Ils ne sont donc pas vraiment liés et ne se contredisent pas non plus.

YAGNI parle de pragmatisme. Supposons que vous n'avez pas besoin de quelque chose, jusqu'à ce que vous en ayez besoin.

Supposons généralement que YAGNI entraîne le découplage. Si vous n'appliquez pas ce couteau du tout, vous finissez par supposer que vous devez avoir des cours qui connaissent tout le comportement de chacun avant de démontrer que cela est vrai.

"Découpler" (ou "en vrac") est un verbe, il faut donc travailler. YAGNI est une présomption, pour laquelle vous ajustez lorsque vous trouvez que ce n'est plus vrai.

Answer 3

Je (presque) toujours découpler. Chaque fois que je faisais cela, je le trouvais utile et (presque) chaque fois que je ne le faisais pas, je devais le faire plus tard. J'ai également trouvé un bon moyen de réduire le nombre de bugs.

Answer 4

Je dirais qu'ils ne le font pas. Le découplage consiste à réduire les dépendances inutiles au sein du code et à resserrer les accès via des interfaces propres et bien définies. "Vous n'en aurez pas besoin" est un principe utile qui déconseille généralement une architecture trop large et extensible d’une solution où il n’existe aucun cas d’utilisation évident et courant.

Le résultat pratique est qu’il existe un système dans lequel il est beaucoup plus facile de refactoriser et de maintenir des composants individuels sans provoquer par inadvertance un effet d’enchaînement sur l’ensemble de l’application et où il n’ya pas d’aspect inutilement compliqué dans la conception - c’est aussi simple selon les besoins pour satisfaire aux exigences actuelles.

Answer 5

Découpler pour découpler peut être mauvais. La construction de composants testables est cependant très importante.

La partie difficile de l’histoire est de savoir quand et combien vous avez besoin de découpler.

Answer 6

Si "les tests unitaires font mal au cul" alors je dirais que vous en avez besoin. La plupart du temps, le découplage peut être réalisé avec un coût pratiquement nul, alors pourquoi ne voudriez-vous pas le faire?

En outre, l’un de mes plus gros problèmes lorsque je travaille sur une nouvelle base de code est de devoir découpler le code avant de pouvoir commencer à écrire des tests unitaires, car l’introduction d’une interface quelque part ou l’utilisation de l’injection de dépendances pourraient économiser beaucoup de temps

Answer 7

Comme l'indique votre mot-clé, c'est très subjectif. Il appartient entièrement à votre propre sagesse technique de décider de ce dont vous n’avez "pas besoin". Vous aurez peut-être besoin d'un couplage dans un cas, mais pas dans un autre. Qui doit dire? Vous , bien sûr.

Pour une décision aussi subjective, il ne peut y avoir de directive à prescrire.

Answer 8

Eh bien, YAGNI n’est guère plus qu’une fausse phrase simpliste que l’on jette autour de soi. Le découplage est cependant un concept assez bien compris. YAGNI semble impliquer que l'on est une sorte de psychique. C'est juste la programmation par cliché, ce qui n'est jamais une bonne idée. Pour être honnête, il y a des cas à prouver que YAGNI n'est probablement pas lié au découplage. Le couplage est typiquement "plus rapide". et "qui sait si vous êtes, vous allez avoir besoin d'une solution découplée; tu ne vas pas changer le composant X de toute façon! "

Answer 9

YAGNI the mess :) ... vraiment, il n'est pas nécessaire que tout le code soit mélangé pour aller "plus vite".

Les tests unitaires aident vraiment à sentir quand il est couplé (étant donné qu'on comprend bien ce qu'est un test unitaire par rapport à d'autres types de tests). Si vous le faites plutôt avec "Vous ne pouvez pas séparer les composants". état d'esprit, vous pouvez facilement ajouter des choses dont vous n'aurez pas besoin:)

Je dirais que YAGNI intervient lorsque vous commencez à tordre et à modifier la logique au-delà des scénarios d'utilisation réels requis par la mise en œuvre actuelle. Disons que vous avez un code qui utilise quelques fournisseurs de paiement externes avec lesquels les deux fonctionnent avec des redirections vers un site externe. Il est correct d'avoir une conception qui garde tout en ordre, mais je ne pense pas qu'il soit acceptable de penser à des fournisseurs dont nous ne savons pas s'il sera jamais pris en charge et qui proposent de nombreuses manières différentes de gérer l'intégration et les fonctions associées. flux de travail.