• • 通過所有測試(需求)
  • 盡可能消除重復(易重用,易修改性)
  • 盡可能清晰表達(可理解性)
  • 更少代碼元素(復雜性,無冗余)
  • 重要程度排序
    • 需求最大
    • 第二 (易修改性 大于 可理解性?)
  • 結論

---

原文 https://www.jianshu.com/p/0228d2dd90fe

Kent Beck給出了”簡單設計”的明確標尺 ,讓程序設計者判斷和遵守 ：

• 通過所有測試（Passes its tests）
• 盡可能消除重復 (Minimizes duplication)
• 盡可能清晰表達 (Maximizes clarity)
• 更少代碼元素 (Has fewer elements)
• 以上四個原則的重要程度依次降低。

這組定義被稱做簡單設計原則。

初看上去，這組原則平淡無奇，似乎是一組耳熟能詳的原則的羅列。但只要細細品味，就會發現其精妙絕倫之處。

通過所有測試(需求)

直觀的看，這句話貌似在講測試：一個項目只有具備完善的自動化測試，才算在做簡單設計。但事實上并非如此。這里提到的測試，真正的意思是客戶驗收。如果你的項目通過了客戶的所有驗收條件（Acceptance Criteria），那就說明你們已經完成與客戶約定的全部需求。至于驗收方式是靠人工還是靠自動化測試則無關緊要。

所以，這句話強調的是對外部需求——包括功能性需求和非功能性需求——正確的完成。

盡可能消除重復(易重用,易修改性)

重復，意味著低內聚，高耦合。而消除重復的過程，也就意味著是讓軟件走向高內聚，低耦合，達到良好正交性的過程。重復導致耦合度提高進而導致難以修改(一個邏輯的改變就導致所有重復代碼都要修改) 識別和消除重復，對于增強軟件應對變化能力的重要程度，怎么強調都不為過。關于這一點，我會另文說明，這里就不再贅述。

不過，并不是所有的重復都可以消除：比如，C++一個源文件里對外部公開的類，其每個public方法原型，除了在源文件里定義時，需要聲明一次，還需要在頭文件里再次聲明。這樣的重復，是語言機制的要求，無法消除。

因而，這條原則被描述為最小化重復，而不是消除重復。

盡可能清晰表達(可理解性)

清晰性，指的是一個設計容易理解的程度。注意：這不僅僅是對整潔代碼（Clean Code）及聲明式設計（Declarative Design）的強調。關于這一點，有著非常有趣的部分，我們在隨后的部分談到。

更少代碼元素(復雜性,無冗余)

這一條是點睛之筆，正是因為它的存在，這組原則才被稱做簡單設計原則，從而區別于其它設計原則。

在這里，常量，變量，函數，類，包 …… 都屬于代碼元素。代碼元素的數量，通常反映了設計的復雜度。因而，這句話強調的是：盡可能降低復雜度，保持簡單。

重要程度排序

這一句最容易讓人忽視，卻恰恰最為重要。如果第四條是點睛之筆，那么第五條就是將之前四條貫穿起來的那條龍。正是這一句，讓你知道當以上四條發生沖突時，應該如何取舍。(不能不做也不能過度做,而是要剛剛好)

• 對于第一條，它強調：簡單固然好，但你不能為了簡單，而不去實現和客戶約定好的需求。（當然，如果需求不合理，你應該在前期通過和客戶協商拒絕，或修改。但那是關于需求管理這個話題有關的故事，感興趣者可以去查閱相關文章和書籍）。(反向價值: 你不應該去實現一個客戶還不需要的需求，因為那會增加系統的復雜度。)

• 而對于第二條，比如，我們現在有兩個類：它們之間有一部分重復代碼。為了消除掉這個重復，我們將重復代碼提取到一個新的類里。于是兩個類變為三個類，增加了一個新的代碼元素。這當然讓設計變得更復雜了。但這種復雜度產生了更重要的價值（讓軟件更具備正交性，從而讓軟件更易于修改,和重用），所以，不能為了保持簡單，而不去消除這個重復。 (反向價值: 你不應該為還沒有出現的重復，或者為尚未出現的變化方向，去增加任何額外的復雜度。比如建立一個抽象接口，卻只有一個對應的實現.)

• 對于第三條也是如此，比如下面這句代碼中有一個magic number：a = 1000; 為了讓這段代碼更容易理解，我們將代碼修改為：
  const int MAX_NUM_OF_CONNECTIONS = 1000;
  a = MAX_NUM_OF_CONNECTIONS;
  從而增加了一個新的代碼元素。因而也稍微增加了設計的復雜度。但由于這個新的代碼元素也產生了相對于簡單更重要的價值，在簡單和表達力之間，我們應該選擇后者。不能為了保持簡單,而丟失掉表達力.

• 我們已經知道，第四條，是簡單設計的精髓，但是，它在前四條原則卻最不重要。 而第四條對于前兩條的約束，就是我們耳熟能祥的YAGNI（You Aren’t Gonna Need It）。它強調，我們要著眼當下，不去為自己猜想出的未來可能性去增加系統的復雜度。

總之，當你看到一個代碼元素，沒有產生之前三條中的任何一條價值(滿足需求? 消除重復(耦合)? 清晰表達?)，那么它就應該被刪除掉。而這正是簡單設計能夠簡單的原因。

需求最大

拋開第四條，單看前三條，它們之前的重要程度也是依次降低的。比如，

• 你不應該因為怕產生很難消除、或干脆消除不掉的重復而放棄一個對客戶有價值的需求。換句話說，哪怕一個需求會導致重復代碼，你也要去實現它。
• 同樣的，如果一個需求，會導致你的設計更加晦澀，你卻不應該因為它損害了清晰性、可理解性而拒絕它。

對于這兩點，絕大多數人都沒有太多爭議。(也有一派認為，不應該讓需求破壞設計的優雅，當兩者發生沖突時，選擇優雅)。

第二 (易修改性 大于 可理解性?)

我們經常能夠聽到一種爭議：一些人認為，放在一起的長篇累牘的大塊流程代碼，反而更容易理解。因為消除重復而導致的單一職責，會將一大段代碼分布到不同的類或者模塊，為了理解它，就不得不在類或者模塊間跳來跳去，反而不容理解了。

另外一部分人并不認同這種看法。他們認為，由于模塊或類的單一職責性，其每塊邏輯都更加簡單清晰，然后在另外一個層面再去看它們之間的交互，就可以很快理解整個邏輯。 這比大坨的面條式代碼更容易理解。而對于SLAP（Single Level of Abstraction Priciple）的遵守，會更進一步的增加可理解性。

由于可理解性屬于更加個人、更加主觀的事情，因而究竟哪種方式更容易理解，可能永遠也不會有統一的答案。

而簡單設計原則通過第二條和第三條之間的排序，給出了清晰的決策依據：由于消除重復，把一大塊代碼分隔到了不同的地方，即便團隊認為這確實損害了可理解性，但由于重復所導致的惡果更加嚴重，因而優先選擇消除重復。

另外，關于簡單設計原則，社區內有多個版本，用詞不同，但意思大致相同。關鍵的差別是第二條和第三條的順序：即消除重復和提升表達力哪個更重要。有一些人認為表達力比消除重復重要，因而把提升表達力放在第二條。但更多人認同的是本文之前的版本。

對于這一點，我個人的觀點是，越是主觀的東西，就越不具備可驗證性或科學性，因而對于工程技術而言，重要程度就越低。

另外，回歸到具體項目里，為了避免爭議，在不違背前兩點原則的情況下，團隊可以根據大多數人的審美和認知，決定怎樣的設計才更具備可理解性。事實上，在重復已經被消除殆盡的情況下，對于可理解性問題，無論怎樣選擇，影響都是局部的。

因而，對于這個問題，團隊覺得舒服最重要。

結論

簡單設計原則，通過對需求、易修改性、可理解性、復雜度，這四個在設計決策中最關鍵的因素給出了排序，讓簡單設計不再一個語義模糊的口號，而是對設計決策給出了清晰的guideline。

根據筆者經驗，深入理解、并在項目中反復品味和應用它，可以避免掉很多不必要的爭議，也會對設計質量產生非常顯著的幫助。

作者：袁英杰
鏈接：https://www.jianshu.com/p/0228d2dd90fe
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

總結

以上是生活随笔為你收集整理的C++正交设计笔记2 简单设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。