我花了好幾天的時間，只為了把幾個 API 設計好。是關於模組的新 API，還有一種新的 Redis 資料型別。當我說*好幾天*時，我是認真的，而且光是為了 API 本身。先寫草稿，再開始實作、形塑資料結構與呼叫方式，然後又從頭來過，用更好的方式反覆迭代，以改進設計與面向使用者的部分。

我為什麼要這麼做，甚至為此把功能延後好幾個星期？這真的有那麼重要嗎？程式設計師是工程師，或許他們本來就應該去適應對提供方的系統而言比較好匯出的任何 API。

我真的需要回答這些自問自答的問題嗎？不用了，在今天已經不再需要，而這本身就是一大進展。

我想在此假定，有一點已經是大家心照不宣、視為理所當然的：程式設計師同樣擁有使用者介面，而且這樣的使用者介面至關重要，足以徹底改變人們對一個系統的觀感。資料庫查詢語言、函式庫呼叫、程式語言、Unix 命令列工具，它們全都有使用者介面的成分。如果你每天都在使用它們，對你而言，它們與其說是別的什麼，不如說更像是使用者介面。

那麼，既然這些都是眾所皆知的事，我為什麼還要寫這篇部落格文章？因為我想強調簡潔這個概念有多重要，不只是在圖形化使用者介面中，在為程式設計師設計的使用者介面中亦然。一次又一次地反覆迭代，只為找到一個簡潔的使用者介面解法，這並不是一種完美主義，也不是徒勞的自戀。它更像是在設計空間中的一場探索，這個空間有時非常廣闊，由能帶來巨大差異的細微變化所構成，也由能徹底改變觀點的巨大變化所構成。沒有什麼規則可以遵循，能依靠的只有你的敏銳度。的確，有所謂的良好實踐，但當你所要航行的是一片名為設計*空間*的大海時，它們並不是好的羅盤。

那麼，為什麼程式設計師應該享有擁有良好、簡潔的使用者介面這種特權？當然，使用一件製作精良、好上手、感覺*恰到好處*的東西，本身就是一種樂趣。但還有一個更核心的問題。透過 M4 macros 來學會設定 Sendmail，或是為了設定 Apache 虛擬主機而苦苦掙扎，並不是真正的知識。如果有一天這樣的系統不再被使用，還有什麼會留在你手中，或者更貼切地說，留在你的神經元裡？什麼也沒有。這就是特設知識。它就像垃圾食物：只有空熱量，卻沒有微量營養素。

對程式設計師而言，微量營養素是那些能持續數十年的觀念，而不是那些特設的垃圾。我不想推出垃圾，所以我會在發布前持續精煉我的設計。你也不該接受垃圾，你的神經元更值得用來學習通用的概念。然而，在某種程度上這是無可避免的：每個系統都會有一些非通用的、為了使用它而必須學習的東西。好吧，如果事情就是這樣，至少，讓我們把那個特設的部分變得簡單一點，如果可能的話，甚至讓它用起來是有趣的。