我花了好几天时间，就为了把几个 API 的设计敲定。是关于模块的新 API，还有一种新的 Redis 数据类型。当我说*好几天*时，我是认真的——光是 API 本身就花了这么久。先写草案，再着手实现、搭建数据结构和调用方式，然后又推倒重来，用更好的方式再迭代一轮，只为把设计和面向用户的部分做得更好。

我为什么要这么做，甚至为此把功能推迟数周？这真的有那么重要吗？程序员都是工程师，或许他们本就应该去适应系统为了自身方便而导出的任何 API。

我还需要回答这些自问自答的问题吗？不用了，在今天，这已经无需回答——而这本身就是一大进步。

我想，如今我们可以默认一个前提已是不言自明：程序员同样面对用户界面，而且这种界面至关重要，甚至足以彻底改变人们对一个系统的观感。数据库查询语言、库调用、编程语言、Unix 命令行工具，它们都有属于用户界面的那一面。如果你每天都在使用它们，对你而言，它们首先是界面，其次才是别的什么。

既然这些都已是共识，我为什么还要写这篇博客？因为我想强调“简洁”这个概念有多重要——不仅是在图形界面中，在面向程序员的界面里同样如此。一次又一次地迭代，只为找到一个简洁的界面方案，这并非完美主义，也不是徒劳的自恋。这更像是在设计空间中的一次探索，有时这个空间无比广阔，既包含带来巨大差异的细微变化，也包含彻底改变视角的巨大变革。这里没有可以遵循的固定规则，能依靠的只有你的感知力。诚然，有一些最佳实践，但当你要航行的是一片名为设计*空间*的汪洋大海时，它们算不上可靠的罗盘。

那么，为什么程序员就该享有拥有良好、简洁界面的特权呢？当然，使用一件做工精良、得心应手、让人感觉*恰到好处*的东西，本身就是一种乐趣。但还有一个更核心的问题。通过 M4 宏去配置 Sendmail，或是费劲周折去搞定 Apache 虚拟主机的配置，这些算不上真正的知识。如果有一天这样的系统不再被使用，你手里——或者说，你脑子里——还能剩下什么？什么也没有。这就是特设性知识。它就像垃圾食品：只有空热量，却没有任何微量营养素。

对程序员而言，微量营养素是那些能够持续数十年的思想，而不是那些特设的垃圾。我不想交付垃圾，所以在发布之前，我会继续打磨我的设计。你也不应该接受垃圾，你的神经元更值得用来学习通用的概念。当然，在某种程度上，这在所难免：每个系统总会有一些为了使用它而不得不学的、非通用的东西。既然如此，至少让我们把这部分特设的内容做得简单一些，如果可能，甚至让它用起来饶有趣味。