design-patterns - 调和 YAGNI 与远见的悖论

Question

我参加了一些类(class)并阅读了 YAGNI 的用途。但是，作为一个整体，这个原则从来没有让我满意。它引入了一个逻辑悖论。

作为一个假设，您正在设计一个打算向前扩展的框架。 YAGNI(可能还有 TDD)会鼓励你专注于现在。使其适用于您可预见的硬件。毕竟，对 future 的要求是模糊的，嗯， future 的。

但是，这从本质上限制了您的框架的可行性。在这个假设中，您有远见知道 future 会发生什么。花时间做一些原型(prototype)设计和提前工作可能是值得的，因为知道它可以很好地帮助你前进。毕竟，框架的本质是促进跨环境的某些功能——那么您如何设计框架并严格遵守 YAGNI 原则呢？

我不确定我是否要求具体说明“如何使用 YAGNI”——我认为它可能比这更哲学。我可能只是问行业中经验丰富的开发人员，YAGNI、对立原则和最佳实践之间的界限在哪里。 YAGNI 是否强制执行？甚至被重视？或者它只是我们的学校教给我们的东西，因为它在我们的书中？

谢谢。

Answer 1

出于多种原因，YAGNI 是大型应用程序的实际开发和维护中的重要原则。以下是最引人注目的:

技术复杂性
在处理工业规模的代码库时，经验丰富的开发人员会非常不愿意接受技术复杂性到他们的系统中。您不应该在需要之前就开始支付额外技术复杂性的隐含开销。

需求流失
您可能认为您对系统的 future 需求有一个清晰的认识，但您很可能错了。统计数据表明，产品负责人描述为项目“必须具备”的所有功能中有 35% 从未实现过。试图预测 future 的需求并做一些新的技术工作会导致浪费精力。

QA 反馈循环
任何时候你在一个非平凡的技术系统上做任何开发，都会有错误。这是不可避免的。根据一些研究，在创建当天和一年后发现错误会使开发成本相差 100 倍。现在键入不能通过与 UI 交互执行的代码“以防我们以后需要它”是缺乏经验的开发人员的标志。

综上所述，最好的代码基本上一直坚持YAGNI原则，最好的敏捷团队也以此为目标。如果您有远见，您可能会认为您正在使您的代码更易于使用、更灵活等，但事实并非如此。代码在简单时最容易使用，因此请保持这种方式。