我們?nèi)绾慰梢詫懗龈子诰S護的，更易于擴展的，更穩(wěn)定的，更整潔的、復雜度更低的、生命周期更長的代碼呢？我相信這個應該是每個優(yōu)秀coder的夢想；當然每個coder對于實現(xiàn)寫出更優(yōu)秀的代碼可能會有自己獨到的見解，但是對于大家都公認的一些比較好的代碼設計原則應該都會比較認同，本文將簡單介紹一些代碼編程原則。如果僅僅有了解了編程原則是不足夠?qū)懗鰞?yōu)秀的代碼，還需要我們不斷的實踐和在適合的場景中應用，進行不同的原則的抉擇。
本文受The Principles of Good Programming啟發(fā)。我覺得這份列表已經(jīng)足夠了，但這并不完全符合我個人的想法。此外，我還需要更多的論證、細節(jié)以及其他資料的鏈接。
通用
- [KISS (Keep It Simple Stupid)]
- [YAGNI]
- [做最簡單的事情]
- [關注點分離]
- [保持事情不再重復]
- [為維護者寫代碼]
- [避免過早優(yōu)化]
- [童子軍軍規(guī)]
模塊間/類
- [最小化耦合]
- [迪米特法則]
- [組合優(yōu)于繼承]
- [正交性]
- [穩(wěn)健性原則]
- [控制反轉(zhuǎn)]
模塊/類
- [最大化聚合]
- [里氏代換原則]
- [開放/封閉原則]
- [單一職責原則]
- [隱藏實現(xiàn)細節(jié)]
- [科里定律]
- [封裝經(jīng)常修改的代碼]
- [接口隔離原則]
- [命令查詢分離]
KISS
大多數(shù)系統(tǒng)如果保持簡單而不是復雜，效果最好。
為什么？
- 更少的代碼可以花更少的時間去寫，Bug更少，并且更容易修改。
- 簡單是復雜的最高境界。
- 完美境地，非冗雜，而不遺。
相關資料
YAGNI
YAGNI的意思是“你不需要它”：在必要之前不要做多余的事情。
為什么
- 去做任何僅在未來需要的特性，意味著從當前迭代需要完成的功能中分出精力。
- 它使代碼膨脹；軟件變得更大和更復雜。
怎么做
- 在當你真正需要它們的時候，才實現(xiàn)它們，而不是在你預見到你需要它們的時候。
相關資料
做最簡單的事情
為什么
- 僅有當我們只解決問題本身時，才能最大化地解決實際問題。
怎么做
- 捫心自問：“最簡單的事情是什么？”。
相關資料
關注點分離
關注點分離是一種將計算機程序分離成不同部分的設計原則，以便每個部分專注于單個關注點。例如，應用程序的業(yè)務邏輯是一個關注點而用戶界面是另一個關注點。更改用戶界面不應要求更改業(yè)務邏輯，反之亦然。
引用Edsger W. Dijkstra (1974)所說：
我有時將其稱為“關注點分離”，即使這不可能完全做到，但它也是我所知道的唯一有效的思維整理技巧。這就是我所說的“將注意力集中在某個方面”的意思：這并不意味著忽略其他方面，只是對于從某一方面的視角公正地來看，另一方面是不相關的事情。
為什么
- 簡化軟件應用程序的開發(fā)與維護。
- 當關注點很好地分開時，各個部分可以被重用，并且可以獨立開發(fā)和更新。
怎么做
- 將程序功能分成聯(lián)系部分盡可能少的模塊。
相關資料
保持事情不再重復
在一個系統(tǒng)內(nèi)，每一項認識都必須有一個單一的、明確的、權(quán)威的表示。
程序中的每一項重要功能都應該只在源代碼中的一個地方實現(xiàn)。相似的函數(shù)由不同的代碼塊執(zhí)行的情況下，抽象出不同的部分，將它們組合為一個函數(shù)通常是有益的。
為什么
- 重復（無意或有意的重復）會造成噩夢般的維護，保養(yǎng)不良和邏輯矛盾。
- 對系統(tǒng)中任意單個元素的修改不需要改變其他邏輯上無關的元素。
- 此外，相關邏輯的元素的變化都是可預測的和均勻的，因此是保持同步的。
怎么做
- 只在一個處編寫業(yè)務規(guī)則、長表達式、if語句、數(shù)學公式、元數(shù)據(jù)等。
- 確定系統(tǒng)中使用的每一項認識的唯一來源，然后使用該源來生成該認識的適用實例（代碼、文檔、測試等）。
- 使用三法則（Rule of three）.
相關資料
相似資料
- Abstraction principle
- Once And Only Once is a subset of DRY (also referred to as the goal of refactoring).
- Single Source of Truth
- A violation of DRY is WET (Write Everything Twice)
為維護者寫代碼
為什么
- 到目前為止，維護是任何項目中最昂貴的階段。
怎么做
- 成為維護者。
- 不論何時編寫代碼，要想著最后維護代碼的人是一個知道自己住在哪里的暴力精神病人。
- 如果某個入門的人掌握了代碼，他們就會從閱讀和學習代碼中獲得樂趣，以這樣的想法去編寫代碼和注釋。
- 別讓我想（Don’t make me think）.
- 使用最少驚訝原則（Principle of Least Astonishment）.
相關資料
避免過早優(yōu)化
引用Donald Knuth所說：
程序員浪費大量的時間來思考或擔心程序的非關鍵部分的速度，而考驗嘗試這些優(yōu)化實際上在調(diào)試和維護時有很強的負面影響。比如說在97%的開發(fā)時間，我們應該忽略低效率：過早的優(yōu)化是萬惡之源。然而，我們不應該在關鍵的3%中放棄我們的機會。
當然，需要理解什么是“過早”什么不是“過早”。
為什么
- 瓶頸在哪是未知的。
- 優(yōu)化后，閱讀和維護可能會更困難。
怎么做
- 使它運作，使它正確，使它更快（Make It Work Make It Right Make It Fast）
- 不要在你不需要的時候優(yōu)化，只有在你發(fā)現(xiàn)一個瓶頸之后才能優(yōu)化它。
相關資料
最小化耦合
模塊/組件之間的耦合是它們互相依賴的程度，較低的耦合更好。換句話說，耦合是代碼單元“B”在未知的代碼單元“A”更改后“被破壞”的幾率。
為什么
- 一個模塊的更改通常會導致其他模塊的更改，產(chǎn)生漣漪效益。
- 由于模塊間的依賴性增加，模塊裝配可能需要更多的工作和/或時間。
- 特定的模塊可能難以重用和/或測試，因為必須包含相關模塊。
- 開發(fā)人員可能害怕更改代碼，因為他們不確定什么會收到影響。
怎么做
- 消除，最小化和降低必要關聯(lián)的復雜性。
- 通過隱藏實現(xiàn)細節(jié)，減少耦合。
- 使用[迪米特法則]。
相關資料
迪米特法則【Law of Demeter or Least Knowledge Principle（LoD or LKP）】
迪米特法則或最少知道原則。它講的是“一個對象就盡可能少的去了解其它對象”，從而實現(xiàn)松耦合。如果一個類的職責過多，由于多個職責耦合在了一起，任何一個職責的變更都可能引起其它職責的問題，嚴重影響了代碼的可維護性和可重用性。
為什么
- 這通常會導致更緊密的耦合。
- 可能會暴露過多的實現(xiàn)細節(jié)。
怎么做
對象的方法只能調(diào)用以下方法：
- 對象自身的方法。
- 方法參數(shù)中的方法。
- 方法中創(chuàng)建的任何對象的方法。
- 對象的任何直接屬性或字段的方法。
相關資料
組合優(yōu)于繼承
為什么
- 類之間的耦合減少。
- 使用繼承，子類很容易做出假設，并破壞里氏代換原則（LSP）。
怎么做
- 測試LSP（可替換性）以決定何時繼承。
- 當存在“有”（或“使用”）的關系時使用組合，當存在“是”的關系時使用繼承。
相關資料
正交性
正交性的基本概念是，概念上不相關的東西在系統(tǒng)中不應該相關。
它越簡單，設計越正交，異常就越少。這使得用編程語言學習、讀寫程序變得更容易。正交特征的含義是獨立于環(huán)境；關鍵參數(shù)是對稱性與一致性。
來源：Orthogonality
穩(wěn)健性原則
堅持保守自己的作為，自由接受他人的作為。
合作的服務依賴于彼此的接口。通常，接口需要提升，導致另一端接收未指定的數(shù)據(jù)。如果接收到的數(shù)據(jù)沒有嚴格遵守規(guī)范，那么簡單的實現(xiàn)將僅拒絕合作。更復雜的實現(xiàn)卻可以忽略它無法識別的數(shù)據(jù)。
為什么
- 為了能夠提高服務，你需要確保提供者可以進行更改以支持新的需求，同時對現(xiàn)有客戶端造成最小的破壞。
怎么做
- 向其他機器（或同一機器上的其他程序）發(fā)送指令或數(shù)據(jù)的代碼應該完全符合規(guī)范，但接受輸入的代碼應接受不一致的輸入，只要其意義明確。
相關資料
控制反轉(zhuǎn)
控制反轉(zhuǎn)又被稱為好萊塢原則，“不要打電話給我們，我們會打電話給你”。它是一種設計原則，計算機程序的自定義編寫部分從通用框架接收控制流?？刂品崔D(zhuǎn)具有強烈的含義，即可重用代碼和特定于問題的代碼是獨立開發(fā)的，即使它們在應用程序中一同工作。
為什么
- 控制反轉(zhuǎn)用于提高程序的模塊性，使其具有可擴展性。
- 將任務的執(zhí)行與實現(xiàn)分離。
- 將模塊集中在其設計任務上。
- 使模塊不受關于其他系統(tǒng)如何執(zhí)行其任務的假設約束，而是依賴于約定。
- 以防止模塊更換時出現(xiàn)副作用。
怎么做
- 使用工廠模式
- 使用服務定位器模式
- 使用依賴注入
- 使用依賴查找
- 使用模板方法模式
- 使用策略模式
相關資料
- Inversion of Control in Wikipedia
- Inversion of Control Containers and the Dependency Injection pattern
最大化聚合
單個模塊/組件的聚合性是其職責形成有意義的單元的程度，越高的聚合性越好。
為什么
- 增加了理解模塊的難度。
- 增加了維護系統(tǒng)的難度，因為域中邏輯的更改會影響多個模塊，并且一個模塊的更改需要相關模塊的更改。
- 由于大多數(shù)應用程序不需要模塊提供的隨機操作集，因此重用模塊的難度增加。
怎么做
- 與組相關的功能共享一項職責（例如在一個類中）。
相關資料
- Cohesion
- Coupling And Cohesion
里氏替換原則【Liskov Substitution Principle（LSP）】
里氏替換原則（LSP）完全是關于對象的預期行為：
程序中的對象應該可以替換為其子類型的實例，而不會改變該程序的正確性。
相關資源
開-閉原則【Open-Close Principle（OCP）】
軟件實體（例如類）應對擴展是開放的，但對修改是封閉的。也就是說，這樣的實體可以允許在不改變其源代碼的情況下修改其行為。
為什么
- 通過最小化對現(xiàn)有代碼的修改來提高可維護性和穩(wěn)定性
怎么做
- 編寫可以擴展的類（而不是可以修改的類）
- 只暴露需要更換的活動部分，隱藏其他所有部分。
相關資源
單一職責原則【Single Responsibility Principle（SRP）】
一個類不應該有多個修改的原因。
長話版：每個類都應該有一個單獨的職責，并且該職責應該完全由該類封裝。職責可以定義為修改的原因，一次類或模塊應該有且僅有一個修改的原因。
為什么
- 可維護性：僅有一個模塊或類中需要修改。
怎么做
- 使用 [科里定律]
相關資料
隱藏實現(xiàn)細節(jié)
軟件模塊通過提供接口來隱藏信息（即實現(xiàn)細節(jié)），而不泄露任何不必要的信息。
為什么
- 當實現(xiàn)更改時，客戶端使用的接口不必更改。
怎么做
- 最小化類和成員的可訪問性。
- 不要公開成員數(shù)據(jù)。
- 避免將私有實現(xiàn)細節(jié)放入類的接口中。
- 減少耦合以隱藏更多實現(xiàn)細節(jié)。
相關資料
科里定律
科里定律是關于為任何特定代碼選擇一個明確定義的目標：僅做一件事。
封裝經(jīng)常修改的代碼
一個好的設計可以辨別出最有可能改變的熱點，并將它們封裝在API之后。當預期的修改發(fā)生時，修改會保持在局部。
為什么
- 在發(fā)生更改時，最小化所需的修改。
怎么做
- 封裝API背后不同的概念。
- 將可能不同的概念分到各自的模塊。
相關資料
接口隔離原則
將臃腫的接口減少到多個更小更具體的客戶端特定接口中。接口應該比實現(xiàn)它的代碼更依賴于調(diào)用它的代碼。
為什么
- 如果類實現(xiàn)了不需要的方法，則調(diào)用方需要了解該類的方法實現(xiàn)。例如，如果一個類實現(xiàn)了一個方法，但只是簡單的拋出異常，那么調(diào)用方將需要知道實際上不應該調(diào)用這個方法。
怎么做
- 避免臃腫的接口。類不應該實現(xiàn)任何違反[單一職責原則]的方法。
相關資料
童子軍軍規(guī)
美國童子軍有一條簡單的軍規(guī)，我們可以使用到我們的職業(yè)中：“離開營地時比你到達時更干凈”。根據(jù)童子軍軍規(guī)，我們應該至終保持代碼比我們看到時更干凈。
為什么
- 當對現(xiàn)有代碼庫進行更改時，代碼質(zhì)量往往會降低，從而積累技術債務。根據(jù)童子軍軍規(guī)，我們應該注意每一個提交（Commit）的質(zhì)量。無論規(guī)模有多小，技術債務都會受到不斷重構(gòu)的抵制。
怎么做
- 每次提交都要確保它不會降低代碼庫的質(zhì)量。
- 任何時候，如果有人看到一些代碼不夠清楚，他們就應該抓住機會在那里修復它。
相關資料
命令查詢分離
命令查詢分離原則規(guī)定，每個方法都應該是執(zhí)行操作的命令，或者是向調(diào)用者返回數(shù)據(jù)但不能同時做兩件事的查詢。提問不應該改變答案。
利用這個原則，程序員可以更加自信地進行編碼。查詢方法可以在任何地方以任何順序使用，因為它們不會改變狀態(tài)。而使用命令，你必須更加小心。
為什么
- 通過將方法清晰地分為查詢和命令，程序員可以在不了解每個方法的實現(xiàn)細節(jié)的情況下，更加自信地編碼。
怎么做
- 將每個方法實現(xiàn)為查詢或命令。
- 對方法名使用命名約定，該方法名表示該方法是查詢還是命令。
相關資料
