什么时候违反YAGNI？

该YAGNI "原则"规定,你不应该集中在你需要像以前提供的功能:"你是不是要去需要它"反正.

我通常倾向于使用常识高于任何规则,无论如何,但有时我认为如果你有充分的理由过度设计或将来证明某些东西,即使你可能永远不会使用它.

我现在掌握的实际案例或多或少是这样的:

我有一个应用程序必须运行在一个简单的专有通信协议(OSI级别4).该协议具有一组理想的特性(例如遵循NORM规范),它们为应用程序提供稳健性,但并不是严格要求的(UDP多播可以执行可接受的).

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

那么,你的想法是什么？我应该只设计专有协议并将重构,接口提取等留给我真正需要的时候,还是应该设计现在考虑(不是到目前为止)的未来？

注意:为了清楚起见,我有兴趣听到对一般问题(何时违反YAGNI)的所有意见,但我真的想对我目前的困境提出一些建议或想法:)

YAGNI适用于代码的原因是变更成本很低.通过良好的,重构良好的代码,以后添加功能通常很便宜.这与建筑不同.

在协议的情况下,稍后添加更改通常并不便宜.旧版本中断,它可能导致通信失败,以及N ^ 2测试矩阵,因为您必须针对每个其他版本测试每个版本.将其与单个代码库进行比较,其中新版本只需要自己处理.

所以在你的情况下,对于协议设计,我不推荐YAGNI.

恕我直言

我先说YAGNI.使用' 最简单的工作 ' ,在没有NORM规范的情况下使其工作.

接下来比较一下,未来进行"设计变更"的成本是否明显高于现在进行变更的成本.您当前的解决方案是否可逆？如果您可以在明天或几个月后轻松进行更改,请立即进行更改.如果您现在不需要做出不可逆转的设计决定..延迟到最后一个负责任的时刻(以便您有更多信息做出更好的决定)

如果你已经确定地知道某些东西即将出现并且稍后添加它将会是一种痛苦,那么关闭它就不会是一种鸵鸟设计.
例如,我知道在产品发货之前需要诊断日志.在编写每个函数之后,在一个月之后添加日志记录代码比在今天添加日志代码要费力得多......所以这将是我重写YAGNI的情况,即使我现在不需要日志.

另见:T.和M. Poppendieck的精益书更能解释上面第2章子弹的困境.

很好地构建您的程序(抽象等)不是YAGNI适用的.您总是希望很好地构建代码.

只是为了澄清,我认为你目前的困境是由于过度使用YAGNI.以这样一种方式构建代码,即使用一个可重用的库来使用该协议,这只是一种很好的编程习惯.YAGNI不适用.