我参加了一些课程并阅读了有关 YAGNI 的目的。但是，这个原则作为一个整体从来没有让我满意。它引入了一个逻辑悖论。
作为一个假设，您正在设计一个打算向前扩展的框架。YAGNI（可能还有 TDD）会鼓励你专注于现在。让它适用于您可预见的硬件。毕竟，对未来的要求是模糊的，而且是在未来。
但是，这从本质上限制了您的框架的可行性。在这个假设中，你有先见之明，知道未来会怎样。做一些原型设计和提前工作可能值得你花时间，因为知道它可以很好地帮助你。毕竟，框架的本质是促进跨环境的某些功能——那么你如何设计一个框架并严格遵守 YAGNI 原则？
我不确定我是否要求提供关于“如何使用 YAGNI”的具体内容——我知道它可能比这更具哲学意义。我可能只是在询问业内经验丰富的开发人员，YAGNI、对立原则和最佳实践之间的界限在哪里。YAGNI 是否被强制执行？它甚至被视为？或者这只是我们学校教给我们的东西，因为它在我们的书中？
谢谢。
出于多种原因，YAGNI 是大型应用程序的实际开发和维护中的重要原则。以下是最引人注目的：
技术复杂性 在处理工业规模的代码库时，经验丰富的开发人员非常不愿意接受系统中的技术复杂性。您不应该在需要之前就开始支付额外技术复杂性的隐含开销。
需求流失 您可能认为您对系统的未来需求有一个清晰的概念，但您很可能错了。统计数据表明，产品负责人描述为项目“必须具备”的所有功能中有 35% 从未实现过。试图预测未来的需求并做一些新的技术工作会导致浪费精力。
QA 反馈循环 任何时候你在一个重要的技术系统上进行任何开发，都会有错误。这是不可避免的。根据一些研究，在创建之日和一年后发现错误会使开发成本相差 100 倍。现在“以防我们以后需要它”键入无法通过与 UI 交互来执行的代码是开发人员缺乏经验的标志。
综上所述，最好的代码基本上始终坚持 YAGNI 原则，最好的敏捷团队也以此为目标。如果您有远见，您可能会认为您正在使您的代码更易于使用、更灵活等，但情况几乎从未如此。当代码很简单时，它最容易使用，所以请保持这种方式。