我花了好几天时间，只为把几个 API 设计好。是关于模块的新 API，还有一种新的 Redis 数据类型。当我说*好几天*时，我是认真的，仅仅是为了 API。写草稿，着手实现、塑造数据结构和调用，然后又推倒重来，以更好的方式再次迭代，去改进设计和面向用户的部分。

我为什么要这么做，甚至为此把功能推迟数周？这真的有那么重要吗？程序员是工程师，也许他们就应该去适应系统导出方认为更便于导出的那种 API。

我真的需要回答这些自问自答的问题吗？不，如今已不再需要，这本身就是一大进步。

我想假定，到了今天，程序员同样拥有用户界面这一点已是心照不宣、被视为理所当然的事实，并且这样的用户界面至关重要，甚至能彻底改变人们对一个系统的观感。数据库查询语言、库调用、编程语言、Unix 命令行工具，它们都有用户界面的部分。如果你每天都在使用它们，对你而言，它们首先是界面，其次才是其他东西。

那么，既然这一切都已广为人知，我为什么还要写这篇博客呢？因为我想强调简洁这一概念的重要性，它不仅适用于图形界面，也适用于为程序员设计的界面。一次又一次地迭代以寻找简洁的界面解决方案，并非完美主义，也不是徒劳的自恋。这更像是在设计空间中的一次探索，这个空间有时非常广阔，由带来巨大差异的细微变化构成，也由彻底改变视角的巨大变化构成。没有可循的规则，只有你的感知力。诚然，有一些最佳实践，但当需要航行的海洋是设计*空间*时，它们并不是好的指南针。

那么，为什么程序员就应该享有拥有优秀、简洁界面的特权呢？当然，使用一件制作精良、得心应手、感觉*恰到好处*的东西本身就有乐趣。但还有一个更核心的问题。通过 M4 宏来学习配置 Sendmail，或是费力折腾 Apache 虚拟主机的配置，并不是真正的知识。如果某天这样的系统不再被使用，你手中还能剩下什么，或者更确切地说，你的神经元里还能剩下什么？什么都没有。这就是特定于某个系统的临时性知识。它就像垃圾食品：只有空热量，却没有微量营养素。

对程序员而言，微量营养素是那些能够持续数十年的思想，而不是临时的垃圾。我不想发布垃圾，所以我会在发布前继续打磨我的设计。你也不应该接受垃圾，你的神经元更值得用来学习通用的概念。然而在一定程度上，这又是不可避免的：每个系统总会有一些非通用的、为了使用它而必须学习的东西。好吧，如果事情就是这样，至少，让那部分特定的内容尽量简单，如果可能的话，甚至让它变得有趣、好用。