在软件设计领域，追求简洁性和实用性是一种重要的设计理念。本文探讨了在设计软件系统时，如何通过做最简单的事情来实现高效和可维护的系统。

在设计软件系统时，尽可能做最简单的事情。

令人惊讶的是，你对这条建议的接受程度如此之高。我真心觉得你可以 一直 这样做。你可以用这种方法来修复错误、维护现有系统以及构建新系统。

很多工程师在设计时，总是试图设想一个“理想”的系统：一个结构合理、几乎无限可扩展、分布优雅的系统等等。我认为这是完全错误的软件设计方法。相反，应该花时间深入了解现有系统，然后尽可能地做最简单的事情。

简单可能会让人失望

系统设计需要熟练掌握各种工具：应用服务器、代理、数据库、缓存、队列等等。随着初级工程师对这些工具的熟悉，他们自然会想要使用它们。用各种不同的组件构建系统非常有趣！在白板上画方框和箭头的感觉非常满足——就像在做真正的工程一样。

然而，正如许多技能一样，真正的精通往往在于学会何时该少用，而不是多用。雄心勃勃的新手和老手之间的对决，是武术电影中常见的老套桥段：新手动作模糊，翻腾旋转。老手则基本静止不动。但不知何故，新手的攻击似乎总是无法完全命中目标，而老手最后的一击却至关重要。

在软件领域，这意味着优秀的软件设计看起来平庸无奇。它看起来似乎没什么特别之处。当你开始产生这样的想法时，你就能判断自己正在面对优秀的软件设计：“哦，我没想到问题这么简单”或“哦，太好了，你实际上不需要做任何困难的事情”。

Unicorn 的软件设计非常出色，因为它依靠 Unix 原语 ，提供了 Web 服务器中所有最重要的功能（请求隔离、水平扩展、崩溃恢复） 。行业标准的 Rails REST API 也非常出色，因为它以最枯燥的方式提供了 CRUD 应用所需的一切。我不认为这些软件有什么了不起的。但它们是令人印象深刻的设计壮举 ，因为它们用最简单的方式实现了最简单的功能。

你也应该这么做！假设你有一个 Golang 应用程序，想要添加某种速率限制功能。最简单的可行的方法是什么？你的第一个想法可能是添加某种持久存储（比如 Redis），用漏桶算法来跟踪每个用户的请求数。这可行！但你需要一个全新的基础设施吗？如果你把每个用户的请求数保存在内存中会怎么样？当然，应用程序重启后会丢失一些速率限制数据，但这重要吗？实际上，你确定你的边缘代理 还不支持速率限制吗？你能只在配置文件中写几行代码，而不是完全实现这个功能吗？

也许你的边缘代理不支持速率限制。也许你无法在内存中跟踪它，因为你有太多的服务器实例在并行运行，所以你能通过这种方式强制执行的最严格的速率限制范围太宽。也许你丢失了速率限制数据，这会让你的服务崩溃，因为有人正在对你的服务进行如此严重的攻击。在这种情况下，最简单的方法可能就是添加持久存储，所以你应该这样做。但是，如果你可以采用更简单的方法之一，你难道不想这样做吗？

你真的可以用这种方式从头开始构建一个完整的应用程序：从最简单的开始，然后只有当有新的需求迫使你扩展它时才扩展。这听起来很傻，但确实有效。你可以把它想象成将YAGNI作为终极设计原则：超越单一职责，超越选择最佳工具，超越“好的设计”。

做最简单的事有什么错？

当然，总是做尽可能简单的事会面临三大问题。首先，如果不预测未来的需求，最终会得到一个僵化的系统，或者一个一团糟的系统。其次，“最简单”的含义并不明确，所以在最糟糕的情况下，我只能说“要想设计得好，就必须做好设计”。第三，你应该构建可扩展的系统，而不是仅仅能马上运行的系统。让我们依次来讨论这些反对意见。

大泥球

对一些工程师来说，“做尽可能简单的事”听起来就像我在告诉他们别再做工程了。如果最简单的事通常都是临时拼凑的，那是不是意味着这条建议必然会导致一团糟？我们都见过代码库里一堆堆的“黑客”代码，这绝对不是好的设计。

但是 hack 真的简单吗？我其实并不这么认为。hack 或 kludge 的问题恰恰在于它并不简单：它引入了另一个你必须时刻记住的东西，从而增加了代码库的复杂性。hack 只是更容易想到而已。找到合适的修复方案很难，因为它需要理解整个代码库（或者其中的大部分）。事实上，合适的修复方案几乎总是比 hack 简单得多。

做一件可能行得通的最简单的事并不容易。当你审视一个问题时，最初想到的几个解决方案不太可能是最简单的。找到最简单的解决方案需要思考许多不同的方法。换句话说，这需要工程学。

什么是简单？

工程师们对于什么是简单的代码存在很大分歧。如果“最简单”已经意味着“设计良好”，那么“你应该做尽可能简单的事”是否只是一种同义反复？换句话说，Unicorn 真的比Puma更简单吗？添加内存速率限制真的比使用 Redis 更简单吗？以下是“简单” 的粗略而直观的定义：

1. 简单的系统有更少的“移动部件”：使用它们时需要考虑的事情更少
2. 简单的系统内部连接较少。它们由具有清晰、直接接口的组件组成。

Unix 进程比线程更简单（因此 Unicorn 比 Puma 更简单），因为进程间的连接更少：它们不共享内存。这对我来说很有道理！但我认为它并不能让你在任何情况下都找到更简单的方法。

内存限流和 Redis 相比如何？一方面，内存限流更简单，因为你无需考虑构建独立持久内存服务所涉及的所有细节。另一方面，Redis 更简单，因为它提供的限流保证更直接——你不必担心某个服务器实例认为用户受到了限流，而另一个却不这么认为的情况。

当我不确定什么对我来说“似乎”更简单时，我喜欢使用这个决胜法则：简单的系统是稳定的。如果你比较软件系统的两种状态，其中一种在需求没有变化的情况下需要更多持续的工作 ，那么另一种状态更简单。Redis 必须部署和维护，它可以有自己的事件，需要自己的监控，在服务所处的任何新环境中都需要单独部署，等等。因此，内存速率限制比 Redis 更简单。

为什么你不想具有可扩展性？

现在有些工程师会自言自语：“内存限速根本无法扩展！” 哪怕是最简单的方法，即使能用，也绝对无法构建出最大规模的网络系统。它只能构建出一个在现有规模下运行良好的系统。这难道不是不负责任的工程设计吗？

不。在我看来，大型科技公司 SaaS 工程的一大败笔在于对规模的痴迷。我见过太多不可避免的痛苦，都是因为为了应对比当前规模大几个数量级的规模而对系统进行过度设计造成的。

不尝试的主要原因是它根本行不通。根据我的经验，对于任何重要的代码库，你都无法预测它在流量增加几个数量级时的表现，因为你无法提前知道所有的瓶颈在哪里。你最多只能尝试确保自己已经准备好应对 2 倍或 5 倍的流量，然后随时准备处理可能出现的问题。

另一个不该尝试的原因是，这会降低代码库的灵活性。将服务解耦成两部分，以便它们可以独立扩展，这很有意思（我见过这种情况大概十次，其中一次真正有效地独立扩展过）。但这会使某些功能难以实现，因为它们现在需要通过网络进行协调。在最坏的情况下，它们需要通过网络进行事务处理，这确实是一个棘手的工程问题。大多数时候，你根本不需要做这些！

最后的想法

我在科技行业工作的时间越长，就越对我们预测系统未来走向的集体能力感到不乐观。要弄清楚一个系统目前处于什么位置已经够难的了。事实上，这正是做好设计的主要实际困难：对系统有一个准确的整体理解。大多数设计都是在缺乏这种理解的情况下完成的，因此大多数设计都很糟糕。

广义上讲，开发软件有两种方法。第一种是预测六个月或一年后的需求，然后设计出最适合这个需求的系统。第二种是针对你当前的实际需求来设计最佳系统：换句话说，做尽可能最简单的事情。

编辑：这篇文章在Hacker News上得到了一些评论 。

一个有趣的评论说，架构的简单性在规模化时并不重要，因为“实现中的状态空间探索”（我认为它的意思类似于我在这里写的内容）的复杂性高于其他任何复杂性。我不同意——你的功能交互越复杂，简单的架构就越重要，因为你的“复杂性预算”几乎已经耗尽。

我还要感谢 Ward Cunningham 和 Kent Beck 发明了这个表达式——我真以为自己只是自己想出来的，结果几乎可以肯定是突然想起来而已。哎呀！感谢 HN 用户ternaryoperator指出了这一点。