解耦vs YAGNI [英] Decoupling vs YAGNI

问题描述

它们矛盾吗？

去耦是一件很棒的事情，而且很难实现。但是，在大多数应用程序中，我们实际上并不需要它，因此我可以设计高度耦合的应用程序，除了明显的副作用（例如您无法分离组件，单元测试是痛苦的之外），它几乎不会改变其他任何东西。 arse等。

Decoupling is something great and quite hard to achieve. However in most of the applications we don't really need it, so I can design highly coupled applications and it almost will not change anything other than obvious side effects such as "you can not separate components", "unit testing is pain in the arse" etc.

您怎么看？您是否总是尝试分离并处理开销？

What do you think? Do you always try to decouple and deal with the overhead?

推荐答案

在我看来，去耦和YAGNI是非常互补的优点。 （我刚刚注意到了Rob的答案，似乎我们在同一页上。）问题是您应该进行多少次去耦，YAGNI是帮助确定答案的好原则。 （对于那些谈论单元测试的人-如果您需要解耦来进行单元测试，那么YAGNI显然不适用。）

It seems to me decoupling and YAGNI are very much complementary virtues. (I just noticed Rob's answer, and it seems like we're on the same page here.) The question is how much decoupling you should do, and YAGNI is a good principle to help determine the answer. (For those who speak of unit testing -- if you need to decouple to do your unit test, then YAGNI obviously doesn't apply.)

我真的很怀疑说他们总是脱钩的人。也许他们每次想到时都会做。但是我从来没有见过一个无法在某个地方添加额外的抽象层的程序，并且我真诚地怀疑那里有这样一个程序的重要例子。每个人都在某处画一条线。

I really sincerely doubt the people who say they "always" decouple. Maybe they always do every time they think of it. But I have never seen a program where additional layers of abstraction couldn't be added somewhere, and I sincerely doubt there is a non-trivial example of such a program out there. Everyone draws a line somewhere.

根据我的经验，我将代码分离，然后再也没有像其他情况那样利用附加的灵活性。然后必须回去并在以后进行更改。我不确定这是否意味着我在两个方向上都均衡或均衡。

From my experience, I've deoupled code and then never taken advantage of the additional flexibility about as often as I've left code coupled and then had to go back and change it later. I'm not sure if that means I'm well-balanced or equally broken in both directions.

这篇关于解耦vs YAGNI的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！