调和YAGNI与远见的悖论

Question

我上过一些课程，读过YAGNI的目的。但是，这一原则作为一个整体，从来没有与我相处得很好。它引入了一个逻辑悖论。

作为一个假设，您正在设计一个您打算扩展的框架。YAGNI (可能还有TDD)将鼓励您关注现在。让它在你可预见的硬件上工作。毕竟，对未来的要求是模糊的，而且，嗯，在未来。

但是，这在本质上限制了框架的可行性。在这个假设中，你有先见之明，知道未来会是什么样子。这可能是值得你的时间做一些原型和工作提前，知道它可以很好地帮助你前进的道路。毕竟，框架的本质是促进跨环境的某些功能--那么，如何设计框架并严格遵循YAGNI原则呢？

我不确定我是否在要求一个关于“如何使用YAGNI”的具体问题--我明白它可能比这更有哲理性。我可能只是问更多经验丰富的行业开发人员，YAGNI、对立原则和最佳实践之间的界限在哪里。YAGNI被执行了吗？这算不算什么？或者仅仅是学校教我们的东西，因为它在我们的书里？

谢谢。

Answer 1

YAGNI是一个重要的原则，在现实世界中开发和维护大型应用程序，有许多原因。以下是最引人注目的：

当使用工业规模的代码库时，经验丰富的开发人员会很不情愿地接受系统中的技术复杂性。在您需要额外的技术复杂性之前，您不应该开始支付它的隐含开销。

需求搅动--您可能认为您对系统的未来需求有一个清晰的概念，但您很可能错了。统计数据表明，在产品负责人描述为项目“必须拥有”的所有功能中，35%从未实现。试图预测未来的需求和做一些新的技术工作会导致浪费精力。

QA反馈循环，任何时候，您做任何开发，一个非平凡的技术系统，将有缺陷。这是不可避免的。根据一些研究，在创建之日和一年后发现一个bug会使开发成本增加100倍。现在，输入无法通过与UI交互执行的代码“以防我们以后需要它”是一个缺乏经验的开发人员的标志。

总之，最好的代码基本上一直坚持YAGNI原则，而最好的敏捷团队也是这样做的。如果您有远见，您可能会认为您正在使代码更易于使用、更灵活等等，但这几乎从来不是这样。当代码很简单的时候，它是最容易使用的，所以保持它的方式。