软体设计原则 YAGNI (You aren't gonna need it!)

YAGNI (You aren't gonna need it!)，是敏捷开发的核心设计原则之一。此原则指出，程式开发者应该在面临确凿的需求时，才实作相应的功能。换言之，就是不要实作那些现在用不到的东西，也不要因为未来可能需要的理由而事先实作。这样做的目的是为了避免浪费时间和资源去开发最终可能永远不会使用到的功能，同时也能使软体的设计变得更加简洁和易于维护。

以下是违反 YAGNI 原则的经典案例:

我先把这段程式注解起来，也许之后会用到。

我先将这段程式码抽出成 Util 类，或许以后可以与其他人共用。

这个 function 先加入额外的参数，这样以后可以更有弹性和易于重複使用。

我先将这个类别抽象化，这样在替换实作时不需要修改太多程式码，更具弹性。

我觉得这个功能将来可能会被要求，虽然目前还不需要，但我先预先做出来。

上述的预先设计，很有可能最终与实际情况背道而驰，或是达不到预期的结果。

作为开发者，我们并非算命仙，无法预测未来。在这个瞬息万变的时代，计划往往追不上变化。因此，我们应该更多地专注于解决当前的问题，专注于用户目前的需求，儘快将产品交付给用户，以便我们能够更快地获得反馈。我们不应该为了应对未来的各种变化而做出多余的设计，造成更多问题。

也许有些人会质疑:

这些设计虽然目前用不到，但保留着也没有什么坏处。

除非这个专案日后不再维护，否则每行程式码、每个设计都是有成本的，包括：

总之，违反 YAGNI 原则会增加程式的複杂度和修改难度，同时降低可测试性。因此，除了不要实作目前用不到的程式码，我们也应该学会抛弃不需要的程式码，保持整个专案的整洁。遵循此原则不仅有助于团队加快开发速度，还能使程式码保持简单，更易于维护。

如何遵守 YAGNI 原则

首先，要明确你要解决的问题是什么。在满足客户需求的同时，以"简单"为出发点，自我检视：

我要写的这个 class/method/function，现在真的需要吗? 可以真正的解决问题吗?

如果答案是否定的，那么不要急着着手开发，而是停下来重新思考。

什么情况下可以违反 YAGNI 原则

如果你正在开发的专案是让其他人使用的 API、library，那么你需要花更多心思考虑未来可能发生的情况和可能需要的功能，因为这种情况下的变动往往造成牵一髮而动全身。以拥有千万用户的 library 为例，他们无法每次更新都要求 client 修改、编译和重新上架。在这种情况下，预先的设计是必要的，此时开放封闭原则（Open-Closed Principle，OCP）在这里就显得重要。

后记

The best code is no code. 不要实作目前用不到的程式码，没有什么比不写程式码更好了。

References

本文转录自我的部落格 https://kaisheng714.github.io/articles/yagni-principle

更多你可能会感兴趣的文章