CUPID出自Daniel的一篇名爲《CUPID—for joyful coding》的博文，即《CUPID-爲了快樂編程》。
CUPID是Composable/Unix philosophy/Predictable/Idiomatic/Domain based幾個單詞的縮寫，有經驗的同學一看就知道這是好代碼的一些屬性。
知道Cupid這個單詞的同學還能感受到這一組屬性所蘊含的對於軟件工程的熱情。
Cupid的中文是丘比特，是指古羅馬的愛神，其意象是一個長有翅膀的小孩，拿着弓箭射向人們，以便人們可以相互愛上對方。
特質
Daniel老爺子回憶了自己三十多年的編程經歷，他發現在修改代碼時，好的代碼會給人一種非常愉悅的感覺。
你可以輕鬆找到需要修改的地方，而且，那個地方的代碼是如此的易於理解，以至於一眼就能看出來代碼在幹什麼。
你可以很自信的完成修改，並且確信不會引入額外的副作用。
代碼是那麼的鮮活，它會主動的指引你去你想去的地方，並且熱情的歡迎你四處遊覽，就像在你熟悉的家裏一樣！
爲什麼好的代碼能有這樣的魅力？什麼樣的代碼纔是好代碼？提到這個問題，我們常常會想到SOLID（Single Responsibility/Open-close/Liskov Substitution/Interface Segregation/Dependency Injection）原則，Daniel老爺子認爲應該存在比SOLID更好用的東西。
SOLID
設計模式的六大原則有：
Single Responsibility Principle：單一職責原則
Open Closed Principle：開閉原則
Liskov Substitution Principle：里氏替換原則
Law of Demeter：迪米特法則
Interface Segregation Principle：接口隔離原則
Dependence Inversion Principle：依賴倒置原則
如何衡量代碼好壞？
SOLID採用了一組原則來定義好的代碼，但是原則更像是規則，要麼符合，要麼不符合。
而軟件開發過程非常複雜，其間充滿了平衡和妥協，事實上並沒有一種非黑即白的規則可以適用。
有沒有比原則更好的選擇？它可能是特質（Properties/Characteristics）。
特質是事物本身所具備的，而不是靠一組規則去定義的；特質吸引我們去深度挖掘，而不是信任已有的總結；特質通常不是簡單的0或1的判斷，而是一種從低到高的程度；特質是從觀察者的角度給出的，更關注觀察者的體驗，而更少關注與體驗無關的其他方面。
之所以我們會覺得某樣東西是好的，常常是因爲某樣東西具備了一些好的特質。比如藍天白雲圖，它具備了乾淨、純粹的特質。比如勾股定理和質能方程，它們具備簡潔、優雅的特質。
如果說好的代碼是一箇中心點，特質就像是定義了一些方向，通過這些方向的指引，就可以不斷向這個中心點靠攏。
CUPID就是從特質的角度來定義的，它嘗試用一組助記詞來指示好代碼所具備的一組特質，並希望這組特質是最重要的特質。
CUPID所指出的方向與SOLID定義的原則並不衝突，只是角度不同，CUPID更多站在代碼的用戶--將來修改代碼的人--的視角來看待代碼，並指出了好的代碼應該具備的特質。從這個角度來講，CUPID比SOLID的適用性更廣（SOLID事實上只是針對面向對象設計提出的）。
比如，給出一段代碼，用SOLID可能並不能判斷好壞，因爲這段代碼可能根本不涉及SOLID中提到的幾個原則（比如函數式風格的代碼）。
但是很大可能可以從CUPID指明的幾個方向來得到一些結論。
CUPID是完備的嗎，很遺憾，也不是。但CUPID所指出的五種特質可能是按照重要程度排序之後取前五的特質。
理解CUPID
下面我們一起看看CUPID到底是什麼，以及，如何用CUPID來幫助我們寫出好的代碼。
下面的內容，部分來自Daniel老爺子的原文，部分結合了個人的心得體會，分享給大家。
可組合特質（C）
CUPID的第一個字母C是指Composable，即可組合特質。
近兩年，我們在討論面向對象程序設計的時候，越來越關注到“組合優於繼承”這樣的原則。
作爲面向對象程序設計的三大特徵之一的“繼承”，似乎正越來越受到挑戰，這一部分原因是很多繼承的設計是不合理的，比如不符合SOLID所指出的里氏代換原則。
另一部分原因在於，過深的繼承樹帶來了代碼的可理解性問題，因爲我們總是需要理解了基類才能理解子類。其實繼承也是很有用的，但其前提是設計合理的繼承。“組合優於繼承”就是告訴我們優先考慮用組合模式來進行設計。
可組合還體現在以下三個方面：
精巧的接口
接口太多時，讀者需要知道如何組合這些接口去完成某個功能，而接口較少時，讀者可以更容易學習並更少犯錯。只對外公開一個模塊來提供接口，比對外公開多個模塊提供接口更好。只對外公開一個類來提供接口，比對外公開多個類提供接口更好。
正確的接口粒度設計比較困難，最佳的粒度是接口既不顯得臃腫也不碎片化。
設計模式中有一種常見的模式Facade，即門面模式，其意圖正是將對外公開的接口放到一個類中去提供，以便減少接口面，從而讓接口更容易使用。
可體現意圖的代碼
可體現意圖的代碼是用業務語言編寫且能反映業務過程的代碼。可體現意圖的代碼可以使讀者更容易弄清爲什麼代碼要這麼寫，因此更容易組合使用。代碼中的各類命名（比如變量、函數等）都可以用於將意圖體現得更爲明顯。
比如以下意圖不明的代碼：
def getTodos(todos, users):
todos = [todo for todo in todo if not todo.completed and todo.type == ‘HOME’]
todos = [{‘title’: todo.title, ‘user_name’: users[todo.userId].name} for todo in todo]
todos.sort(key=lambda todo: todo[’user_name’])
return todos
可以重構爲以下意圖明確的代碼：
def get_todos(todos, users):
top_priority_todos = [todo for todo in todo if not todo.completed and todo.type == ‘HOME’]
todo_view_models = [{‘title’: todo.title, ‘user_name’: users[todo.userId].name} for todo in top_priority_todos]
todo_view_models.sort(key=lambda todo: todo[’user_name’])
return todo_view_models
或者：
def get_todos(todos, users):
is_top_priority = lambda todo: not todo.completed and todo.type == ‘HOME’
todos = [todo for todo in todo if is_top_priority(todo)]
to_view_model = lambda todo: {‘title’: todo.title, ‘user_name’: users[todo.userId].name}
todos = [to_view_model(todo) for todo in todo]
user_name = lambda todo: todo[’user_name’]
todos.sort(key=user_name)
return todos
最小依賴
擁有最小依賴的代碼是容易組合使用的。
當一個庫有大量的依賴時，一旦使用了這個庫就會間接引入這些依賴。這不僅使我們發佈的二進制製品變得臃腫，也很容易引起一些依賴庫的版本衝突問題。大家如果做過Hadoop的MapReduce任務開發，應該對這個問題深有體會，因爲Hadoop本身有大量的Java依賴，如果我們在MapReduce任務中不小心引入了一個和Hadoop本身的依賴不兼容的版本，在任務運行時就會出錯。
一個擁有最小依賴的庫是很容易使用的，上述包衝突問題會更少發生。
我常常在項目中見到有人爲了實現一些很簡單的功能而引入沒必要的依賴。比如，當我們面對的問題只是簡單的查詢ElasticSearch服務中的數據時，就要評估一下是否有必要引入ElasticSearch的客戶端庫依賴，因爲我們可以很容易的使用通用的HTTP工具庫來發送一個請求來實現數據查詢。
面向對象程序設計有一個重要的原則，即迪米特法則（Law of Demeter），又被稱爲最小知識原則、不要和陌生人說話原則。其指導意義在於一個類不應該和與其不相關的類產生（依賴）關係。
Unix哲學（U）
CUPID的第二個特質U即是指Unix哲學。
Unix可以說是當今應用最廣泛的操作系統，不管是雲服務器還是個人電腦抑或智能手機、IoT設備，都有Unix的影子。Unix廣泛的以Linux、MacOS、iOS、Android等等操作系統的形式存在着。爲什麼Unix可以如此成功？這得益於Unix的簡單而一致的設計哲學。
CUPID中的Unix哲學主要指其最重要的一個觀點：一個程序應該做一件事，並將其做好。Unix中的大量程序都很好的提現了這一特質，比如ls程序只做列舉文件的事，而要查看文件詳情，則需要使用lstat，查看文件內容使用cat，搜索文件內容使用grep等等。如果我們查看這些程序的使用手冊（Manual Page），將發現每一個程序都提供了很多的參數供選擇，事實上每個程序的功能都很強大，並處理了大量的異常情況。這就是把一件事做好的體現。
Unix操作系統中定義了一個強大的管道（Pipe）概念，一個程序的輸出可以通過管道傳輸給另一個程序，從而簡單而一致的實現了多個程序的組合使用。比如ls命令可以列舉出文件列表，然後將結果傳輸給wc程序統計數量，就可以簡單的計算出目錄中的文件數量。
只做好一件事與SOLID中的單一職責原則很像。但是Unix哲學的出發點是讀者，從讀者角度來看程序，得出程序應該只做好一件事的結論。單一職責原則則是從代碼的角度出發進行描述的。Unix哲學更多描述的是程序的目的，並指明一個程序應該只有一個目的。
與Unix原則描述很相似的還有關注點分離的原則。關注點分離是指不同的模塊應該關注不同的事情。比如分層設計，每一層的關注點應該不一樣：MVC中的M關注業務模型和業務邏輯，V關注展示，C關注交互邏輯；TCP/IP四層網絡模型中物理層關注物理鏈路，網絡層關心節點鏈路如何建立，傳輸層關注數據發送的可靠性，應用層關注在具體的應用協議。
可預測性（P）
CUPID的第三個特質P是指Predictable，可預測性。
程序的可預測性是指它應該做它看起來要做的事情，一致且可靠，不隱藏任何出乎意料的行爲。
可預測性包括三個方面：1. 與期望一致的行爲；2. 輸出確定的結果；3. 內部行爲可觀測。
與期望一致的行爲
我們可以通過測試來定義所期望的程序的行爲，但是並不是一定需要用測試來讓程序與期望的行爲一致。精心的挑選名字，剋制的編寫邏輯，正確的處理異常這些都能使得程序與期望的行爲一致。
讀操作和寫操作常常被分開對待。讀操作不會對程序狀態產生影響，我們可以安全的調用，不用顧忌太多後果。寫操作用於修改程序狀態，因此，在使用時需要特別小心，比如如果有多線程訪問就需要考慮線程安全，同時操作多個狀態就需要考慮事務一致性。
如何在讀操作和寫操作中保持與期望一致的行爲？那就是讀操作中不應該隱藏某些讓人意外的寫操作。
輸出確定性的結果
具備確定性的程序很容易讓人理解和使用，因爲它在任何一次調用都會返回同樣的結果，我們可以明確的知道它將返回什麼。
我們常說易於推理的代碼是好代碼，具備確定性的就具備易於推理的特性。
大概是由於Web前端技術的飛速發展，近些年函數式編程範式得到廣大開發者的親睞。函數式編程範式中最重要的一個概念就是純函數。純函數是指沒有任何副作用且可以輸出確定的結果的函數。
純函數是更容易測試的，我們對使用它的信心也更強。但是，在函數式編程範式中，對純函數的規範定義顯得學院化，並加入了場景限定。事實上，我們主要需要的是程序的確定性。用面向對象範式編程，可以考慮把一個對象設計成值對象，這樣也可以增強程序的確定性。由於不確定性常常來自複雜且不確定的依賴（比如，某個依賴自己管理了複雜的狀態，就也會間接的使你的代碼充滿不確定性），在設計類時，嚴格控制其依賴的外部模塊，儘量做到無依賴，也可以增強程序的確定性。
具備確定性的代碼通常是健壯、可靠而具備彈性的。
內部行爲可觀測
如何預測程序的行爲？觀察它的運行時輸出是一個很好的方法。如果程序可以在運行時打印關鍵的內部狀態或行爲就可以讓我們推測其當前狀態。
觀察程序內部狀態可以分爲以下幾個級別：
- 信息儀表（Instrumentation）: 程序告訴我們它正在幹什麼
- 遙測（Telemetry）: 將程序告訴我們的信息以一種接口暴露出來，使其可以被遠程訪問
- 監控（Monitoring）: 將程序告訴我們的信息可視化出來
- 告警（Alerting）: 從監控信息中識別異常，發出通知
- 預測（Predicting）: 利用監控信息來預測即將發生的事件
- 自適應（Adapting）: 通過告警的或者預測的信息動態調整系統以適應變化
有一些工具可以自動提取程序運行時信息供分析，但是最佳的提升程序的可觀測性的方式還是通過有意識的設計來在關鍵處輸出程序的狀態或行爲。
符合慣例的（I）
CUPID的第四個特質I是指Idiomatic，符合慣例的。
大家都有自己的編碼習慣，這些習慣包括空格和製表符的使用，變量命名規則，括號放置位置，代碼結構，提交的粒度和註釋等等。這些不一樣的習慣將顯著的增加不熟悉代碼庫的讀者的認知負載。讀者不僅需要理解問題空間和解空間，還需要不斷進行翻譯，以便識別當前的代碼是有意編寫的，還是無意的，或者只是作者的習慣而已。
編寫代碼時的最偉大的特質是同情心：對你的代碼的用戶的同情；對提供支持服務的同事的同情；對將來修改代碼的開發者的同情。事實上，他們中任意一個可能就是將來的你。編寫“人類可讀的代碼”意味着爲別人編寫代碼。這正是“符合慣例”的意義。
編寫代碼時，可以假定你的用戶具備以下背景：
- 熟悉所使用的編程語言，及該語言對應的庫、工具鏈和生態
- 懂軟件開發的有經驗的開發者
還有一條，他們正努力的完成某件事情。
語言慣例
代碼應該遵循編程語言的慣例。有些編程語言在代碼風格上態度鮮明，我們會更容易判斷代碼是否符合語言慣例。另一些編程語言則可以兼容多種不同風格，此時我們應該選擇一種風格，並始終堅持它。
Python是一門在代碼風格上態度鮮明的語言。當我們在Python的交互式命令行中輸入import this，或者運行命令python -m this時，就會發現輸出了Python所推薦的編程風格。這些編程風格組合成了”Python之禪”（The Zen of Python）。比如“應該有一種顯然的實現方式，而且最好只有一種”（There should be one-- and preferably only one --obvious way to do it）。
Go語言內置了一個代碼格式化工具gofmt，它會處理縮進、括號位置等問題，可以使所有代碼變得風格一致。除此之外，還有一篇專門說明Go語言風格的文檔Effective Go來指導大家寫出風格一致的代碼。
語言慣例出現在各個級別的代碼中，函數名、類型、參數、模塊、代碼組織結構、模塊組織結構、工具鏈選擇、依賴選擇、管理依賴的方式等。如果你的代碼符合這些語言慣例，將會讀起來更讓人愉悅。
如何讓代碼遵循這些語言慣例？可能沒有什麼更好的辦法，只有讓自己多去學習這些慣例。
團隊慣例
當編程語言本身沒有風格傾向，或者有多種風格可選的時候，用什麼風格來寫代碼就由我們自己或者我們的團隊來決定了。通常團隊會自己定義一些慣例，比如用什麼工具，如何縮進等。藉助各種語言的代碼檢查工具，可以自動化的讓代碼保持一致的風格。
對於某些無法用工具覆蓋的慣例，利用架構設計決策記錄來文檔化這些慣例是一種好的實踐。這些慣例的重要性並不比其他的架構設計決策更低。
基於領域的（D）
CUPID的最後一個特質D是指Domain based，基於領域的。
近幾年，微服務的興起使得領域驅動設計（Domain Driven Design, 簡稱DDD）以新的面貌受到大家的廣泛關注。相對於其對於微服務設計的指導意義，DDD提出的以領域爲中心的軟件開發思想或許具有更重大的意義。
基於領域的語言
由於代碼的讀者通常對問題是清楚的，所以，代碼應該用問題空間的語言來寫，這樣就能讓代碼的讀者更容易的理解。問題空間語言即領域語言。
編程語言和庫裏面充滿了計算機技術術語。比如常用的數據結構，如數組、鏈表、哈希表、樹結構等。還比如數據庫表、網絡連接等。甚至基礎數據類型，如整型數值、浮點型數值、字符串等也都是技術術語。直接在代碼中使用這些術語不會告訴你的讀者你要解決什麼問題，他們需要根據對問題的理解進行翻譯。
TDD可以用於幫助我們更多的用領域語言編寫代碼。TDD要求在還沒有實現代碼的時候寫出測試代碼。如何做到呢？其實，TDD是希望我們可以在看到問題後，先用自然語言描述測試過程，然後再將自然語言的測試過程翻譯爲編程語言。由於描述測試過程時，會站在用戶的角度進行描述，所以將更多的使用領域語言。並且測試過程的描述將反映出程序應該有的公開接口，所以接口也會變成用領域語言描述的接口，這就很大程度上促進了用領域語言編寫代碼。
舉個例子，在電商場景中，如果要實現購物車的功能，則分析購物車的業務需求之後，可以將測試過程描述如下：
－ 準備一個空的購物車 － 向購物車添加商品1，數量1 － 向購物車添加商品2，數量2 － 購物車中應該有兩種商品，其中有1個商品1及2個商品2 － 向購物車添加商品1，數量1 － 購物車中應該有兩種商品，其中有2個商品1及2個商品2 － 從購物車取出商品1，數量2 － 購物車中應該有一種商品，即2個商品2
翻譯爲Java語言的測試代碼示例如下（部分）：
...
void testCart() {
var cart = new Cart();
var product1 = new Product();
var product2 = new Product();
cart.add(product1, 1);
cart.add(product2, 2);
assertTrue(cart.contains(product1));
assertEquals(1, cart.productCount(product1));
assertTrue(cart.contains(product2));
assertEquals(2, cart.productCount(product2));
cart.add(product1, 1);
......
}
...
可以看到，通過編寫測試，我們用領域語言設計了Cart類，Product類，並且對Cart類設計了add contains productCount三個方法。除了促進使用領域語言編寫代碼，TDD還可以讓我們提供的接口剛剛夠用，不多不少，從而實現可組合性特質中的“精巧的接口”。
使用領域語言編寫代碼的最佳狀態是，我們的代碼可以讓沒有技術背景的業務人員也能輕鬆看懂，整個代碼讀起來就像業務分析師在講解業務邏輯一樣。
基於領域的結構
除了使用領域語言編寫代碼，在模塊的設計、代碼目錄結構（或包結構）也應該優先使用領域語言命名。
很多使用Spring框架的Java程序員有個偏好，他們按照框架提供的概念來組織代碼，並且將不同的文件按照框架概念進行分類存放。一個可能的結構可能是：
app
|----controllers
|----assets
|----models
|----events
|----repositories
|----requests
|----responses
|----dtos
|----configurations
......
這帶來的問題是，當要修改一個API時，不得不在多個目錄中去查找和修改代碼。這不僅增加了認知負載，使代碼耦合在一起，還增加了修改代碼的負擔。
使用基於領域的結構，建議儘量將目錄按照領域進行劃分，而不是框架概念。比如，如果是一個電商的場景，目錄結構應該是user product order payment shipment等。
當前一個流行的架構模式是分層架構，如果按照分層架構進行設計，則頂層目錄可以是不同的分層名稱，分層以下，就應該是由領域概念組成的目錄。並且分層之間應該有嚴格的依賴順序，不應產生兩個分層循環依賴的情況。雖然看起來這是一個例外，但是這種拆分是有缺陷的。近兩年微服務架構非常流行，而微服務的拆分是按照業務領域進行拆分的，這可以理解爲微服務是整體產品這個根目錄下的基於領域的子目錄。這個現象可以理解爲大家對於分層架構的目錄劃分並不滿意，還是希望在更上層基於領域來劃分目錄。
基於領域的邊界
無論我們如何組織代碼結構，目錄（或模塊）的邊界變成了事實上的領域邊界。一打開代碼庫就能看到目錄結構，目錄的層級和名字逐漸變成了大家最熟系的信息。所以，在設計上，一個重要的原則就是將領域劃分和目錄劃分保持一致。這將有效降低團隊的認知負載，開發者將因此而更不容易犯錯，團隊效率最終將得到提高。
這並不意味着需要組織成一個平坦（flat）的目錄結構。領域以下可以有子領域，目錄以下可以有子目錄，模塊以下可以有子模塊。重要的是這一個一個層級需要能對應上。
總結
到這裏，我們應該瞭解了CUPID所指出的五種特質的內涵。可以明顯的看到，相比不符合CUPID特性的代碼，符合CUPID的代碼可以讓人更加愉悅地進行閱讀和修改。事實上，CUPID中的五個特質並不是相互獨立的，它們常常可以互相促進。
可組合並符合Unix風格的代碼（做一件事，並把它做好）讓人感覺就像是一個可靠的老朋友。符合慣例的代碼讓從未看過此代碼的人也覺得非常熟悉。可預測的代碼將我們從一系列“驚喜”中解脫出來。基於領域的代碼減少了從需求到方案之間的認知距離。
在每次修改代碼時，如果每個人都能將代碼向這幾個方向所指向的中心點靠近一點，那就可以讓代碼越來越好。
參考：
