践行YAGNI

不久前，我在Laracon 大会上发表了关于“YAGNI 实践”的演讲。能够在如此重要的会议上面对如此众多的听众发表演讲，我深感荣幸。至今，我仍然收到大量反馈，并对我的演讲充满兴趣。

到目前为止，很多人要求我分享我的幻灯片。由于这些幻灯片大多是用于讨论的占位符，我觉得写一篇博客文章更能总结我的演讲。不过，如果你想看幻灯片，你可以在StreamACon上观看我的演讲。

我自认为是一个探索者，一直在追寻编程实践的圣杯——那种能够瞬间提升我技能的实践。虽然我知道这并不存在，但我确实相信一套实践。最近，我发现了其中之一，那就是YAGNI。

YAGNI 是极限编程的一项原则，我每天都在工作中实践它。YAGNI 是“你不会需要它”的缩写。它规定程序员不应该添加任何功能，除非它被认为是必要的。理论上，这似乎很简单，但很少有程序员真正实践它。

为什么实践 YAGNI 很困难

在继续讨论 YAGNI 之前，我们需要了解它解决的问题。这个问题就是过度工程。在某种程度上，我们开始以复杂性为荣——痴迷于玩设计模式宾果游戏，并在脑海中构建越来越复杂的架构。

XKCD通过“一般问题”很好地说明了过度工程。

这很有趣，因为这是事实。但这引出了一个问题——为什么我们不能直接把盐递过来？

KISS到底怎么了？ MVP有什么问题？答案是没有。我们需要回归简单。YAGNI 可以帮助我们实现这一点。

我认为极限编程的联合创始人之一 Ron Jeffries 对实践 YAGNI 进行了很好的总结：

当你真正需要时才去实现它们，而不是当你预见到需要它们时才去实现它们。

尽管如此，最常见的争论还是时间问题。我们总是在实际需要之前就编写代码。这是我们的过度设计。我们混淆了预见和需求。

为了区分两者，我们可以创建一个时间范围。Kent Beck 在Full Stack Radio的一次采访中对此进行了很好的描述：

……我做了一个小实验……如果我刻意不再预测未来，将我的设计期限限制在六个月内……情况会好转……我不再过度设计，进展也更快，焦虑感也更少……事情变得更清晰，更容易理解……那么三个月呢？一个月呢？通过这个实验，我从未达到极限……

这样一来，实践 YAGNI 就变成了一场时间实验。我们不断缩短时间范围，以限制代码编写量。理想情况下，我们会达到一个临界点：除非真正需要，否则我们不会编写代码。这不仅仅是因为我们在考虑，或者想要编写，或者它与我们正在编写的代码相关。我们会等到现有代码需要我们实现新代码才能正常工作时才开始编写。

我承认，一开始你会觉得这很懒惰。你会觉得你是在故意逃避写代码。某种程度上来说，确实如此。问题是，你想要写的代码还没准备好。等待可以避免你做假设时发生的所有坏事。

一旦你意识到 YAGNI 的好处，你就会尝试将它应用到所有事情上（又一个程序员的魔咒）。你需要记住，能力越大，责任越大。YAGNI 不是说“不”，而是推迟不必要的复杂性。

因此，有些时候你不应该调用 YAGNI。很遗憾，这需要经验。因此，我将概述一些场景，以帮助初学者。

学习新知识：评估一项新技术时，你应该花时间。这样，你以后就能节省时间，并降低因做出错误决策而浪费更多时间的风险。
基于未来需求的当前设计决策： YAGNI 不应妨碍或破坏我们的努力。在这种情况下，我们应该做出面向未来的设计决策，但只实现足以满足当前需求的功能。这使我们能够减少返工，而不会完全破坏 YAGNI。
抽象外部依赖项：外部依赖项会增加项目的复杂性。与前面的示例类似，花时间抽象这些依赖项可以避免返工并降低复杂性。
测试、安全、规模和业务需求：抱歉，但 YAGNI 并不是编写测试、安全代码、考虑规模或业务需求的免费通行证。

实践 YAGNI 给了我信心。我可以安心地推迟设计决策，因为将来我会更了解情况。我相信自己能够快速调整，因为我的代码很简单，很容易重构和改进。我写的代码更少，而且说实话，最好的代码就是没有代码。

想要更多？关注Twitter 上的@gonedark，获取每周编程技巧、精彩转发和其他随机资讯。