什么时候违反YAGNI？

Question

YAGNI“原则”规定，您不应该在需要之前专注于提供功能，因为“您不会需要它”。

我通常倾向于将常识凌驾于任何规则之上，但有时，如果你有充分的理由，即使你可能永远不会使用它，我也会觉得过度设计或将来证明一些东西是有用的。

我现在掌握的实际情况大致如下：

我有一个应用程序，它必须运行一个简单的专有通信协议 (OSI级别4)。该协议具有一组理想的特性(如遵循规范规范)，这些特性为应用程序提供了鲁棒性，但这些特性并不是严格要求的(UDP组播可以执行可接受的)。

还有一个事实是，应用程序可能(但不是肯定的)将来会被其他客户端使用，这些客户端将无法访问专有解决方案，因此需要另一个解决方案。事实上，我知道应用程序的另一个客户端的概率很高。

那你是怎么想的？当我真的需要的时候，我应该只为专有协议设计，而把重构、接口提取等留给我，还是我现在应该设计来考虑未来(还不算太远)？

备注：只是想说清楚，我很想听听对一般问题的各种意见(什么时候违反YAGNI)，但我真的很想就我目前的困境提出一些建议或想法:)

Answer 1

国际水文学

• ，我想说的是，先去YAGNI。让它在没有规范规范的情况下工作，使用‘--最简单的工作方式--’。接下来，
• 比较一下，如果未来进行“设计更改”的成本是，那么要比现在进行更改要大得多。您目前的解决方案可逆？如果你能轻易地在明天或几个月后做出改变，现在就不要做了。如果你现在不需要做出不可逆转的设计决定..推迟到最后一个负责的时刻(以便您有更多的信息来做出更好的决定)

结束时，如果你相当肯定地知道有什么东西在地平线上，然后再加上它将是一种痛苦，不要成为鸵鸟。为它设计。

我知道在产品出厂之前需要诊断日志。当我编写每个函数时，一个月后添加日志代码要比在今天添加日志代码要困难得多.因此，即使现在不需要日志，我也会重写YAGNI。

也见: T & M. Poppendieck的精益书更好地解释了上面bullet#2的困境。

Answer 2

YAGNI应用于代码的原因是更改的成本很低。对于好的、重构良好的代码，以后添加一个特性通常很便宜。这与建筑不同。

在协议的情况下，以后添加更改通常并不便宜。旧版本中断时，可能会导致通信失败，而N^2测试矩阵则必须针对其他版本测试每个版本。将其与新版本只需自己工作的单个代码库进行比较。

所以在您的例子中，对于协议设计，我不推荐YAGNI。

Answer 3

很好地构造程序(抽象等等)不是YAGNI所适用的东西。您总是想要很好地构造代码。

我只想澄清一下，我认为你目前的困境是由于对YAGNI的过度应用。以这样一种方式构造您的代码，使您有一个可重用的库来使用该协议，这只是很好的编程实践。YAGNI不适用。