重點摘要#

• 如果你無法為一個東西命名，你就無法知道它是什麼；如果你不知道它是什麼，你就無法寫出程式碼
• 命名反映了你對問題的理解程度——名字頻繁變動表示你還不清楚要建什麼
• 先解決具體問題，再抽象化；不要一開始就試圖建造什麼都能做的框架
• 名稱傳達意圖——設計的本質就是實現意圖

詳細內容#

作者聽到一些人決定他們的架構需要更多層次。他們的方向是對的，但方法是倒過來的——他們試圖先建立一個包含業務邏輯的「框架」，而不是先解決具體問題。這個框架應該包裝資料庫、產生物件、使用 ORM、支援訊息傳遞、支援 Web Services，還要能做各種酷炫的事情。

命名的困境#

不幸的是，由於他們不確切知道這個東西要做什麼，他們也不知道該怎麼叫它。於是他們舉辦了一個命名比賽。這正是問題的關鍵所在：

如果你不知道一個東西應該叫什麼，你就無法知道它是什麼。如果你不知道它是什麼，你就無法坐下來寫程式碼。

從歷史中學習#

查看版本控制歷史後，發現到處都是空的介面「實作」。更有趣的是，他們已經改了三次名字卻還沒有實際的程式碼——從 ClientAPI（此處的「client」指的是業務客戶而非 client-server 的 client）到最終的 ClientBusinessObjects——一個含糊、寬泛且具誤導性的名字。

名稱即意圖#

在最終意義上，名稱只是一個指標。一旦所有人都知道名稱只是名稱而不是設計隱喻，大家就可以繼續前進。但如果你無法就一個夠具體的名字達成共識，那你可能連起步都有困難。

如果你無法命名它，你就寫不出來。如果你已經改了三次名字，那就停下來，先搞清楚你到底要建什麼。

— By Sam Gardiner