我們?nèi)绾慰梢詫懗龈子诰S護(hù)的，更易于擴(kuò)展的，更穩(wěn)定的，更整潔的、復(fù)雜度更低的、生命周期更長(zhǎng)的代碼呢？我相信這個(gè)應(yīng)該是每個(gè)優(yōu)秀coder的夢(mèng)想；當(dāng)然每個(gè)coder對(duì)于實(shí)現(xiàn)寫出更優(yōu)秀的代碼可能會(huì)有自己獨(dú)到的見解，但是對(duì)于大家都公認(rèn)的一些比較好的代碼設(shè)計(jì)原則應(yīng)該都會(huì)比較認(rèn)同，本文將簡(jiǎn)單介紹一些代碼編程原則。如果僅僅有了解了編程原則是不足夠?qū)懗鰞?yōu)秀的代碼，還需要我們不斷的實(shí)踐和在適合的場(chǎng)景中應(yīng)用，進(jìn)行不同的原則的抉擇。

本文受The Principles of Good Programming啟發(fā)。我覺得這份列表已經(jīng)足夠了，但這并不完全符合我個(gè)人的想法。此外，我還需要更多的論證、細(xì)節(jié)以及其他資料的鏈接。

通用

• [KISS (Keep It Simple Stupid)]
• [YAGNI]
• [做最簡(jiǎn)單的事情]
• [關(guān)注點(diǎn)分離]
• [保持事情不再重復(fù)]
• [為維護(hù)者寫代碼]
• [避免過(guò)早優(yōu)化]
• [童子軍軍規(guī)]

模塊間/類

• [最小化耦合]
• [迪米特法則]
• [組合優(yōu)于繼承]
• [正交性]
• [穩(wěn)健性原則]
• [控制反轉(zhuǎn)]

模塊/類

• [最大化聚合]
• [里氏代換原則]
• [開放/封閉原則]
• [單一職責(zé)原則]
• [隱藏實(shí)現(xiàn)細(xì)節(jié)]
• [科里定律]
• [封裝經(jīng)常修改的代碼]
• [接口隔離原則]
• [命令查詢分離]

編程規(guī)則Programing Principles.png

KISS

大多數(shù)系統(tǒng)如果保持簡(jiǎn)單而不是復(fù)雜，效果最好。

為什么？

• 更少的代碼可以花更少的時(shí)間去寫，Bug更少，并且更容易修改。
• 簡(jiǎn)單是復(fù)雜的最高境界。
• 完美境地，非冗雜，而不遺。

相關(guān)資料

• KISS principle
• Keep It Simple Stupid (KISS)

YAGNI

YAGNI的意思是“你不需要它”：在必要之前不要做多余的事情。

為什么

• 去做任何僅在未來(lái)需要的特性，意味著從當(dāng)前迭代需要完成的功能中分出精力。
• 它使代碼膨脹；軟件變得更大和更復(fù)雜。

怎么做

• 在當(dāng)你真正需要它們的時(shí)候，才實(shí)現(xiàn)它們，而不是在你預(yù)見到你需要它們的時(shí)候。

相關(guān)資料

• You Arent Gonna Need It
• You’re NOT gonna need it!
• You ain’t gonna need it

做最簡(jiǎn)單的事情

為什么

• 僅有當(dāng)我們只解決問(wèn)題本身時(shí)，才能最大化地解決實(shí)際問(wèn)題。

怎么做

• 捫心自問(wèn)：“最簡(jiǎn)單的事情是什么？”。

相關(guān)資料

• Do The Simplest Thing That Could Possibly Work

關(guān)注點(diǎn)分離

關(guān)注點(diǎn)分離是一種將計(jì)算機(jī)程序分離成不同部分的設(shè)計(jì)原則，以便每個(gè)部分專注于單個(gè)關(guān)注點(diǎn)。例如，應(yīng)用程序的業(yè)務(wù)邏輯是一個(gè)關(guān)注點(diǎn)而用戶界面是另一個(gè)關(guān)注點(diǎn)。更改用戶界面不應(yīng)要求更改業(yè)務(wù)邏輯，反之亦然。

引用Edsger W. Dijkstra (1974)所說(shuō)：

我有時(shí)將其稱為“關(guān)注點(diǎn)分離”，即使這不可能完全做到，但它也是我所知道的唯一有效的思維整理技巧。這就是我所說(shuō)的“將注意力集中在某個(gè)方面”的意思：這并不意味著忽略其他方面，只是對(duì)于從某一方面的視角公正地來(lái)看，另一方面是不相關(guān)的事情。

為什么

• 簡(jiǎn)化軟件應(yīng)用程序的開發(fā)與維護(hù)。
• 當(dāng)關(guān)注點(diǎn)很好地分開時(shí)，各個(gè)部分可以被重用，并且可以獨(dú)立開發(fā)和更新。

怎么做

• 將程序功能分成聯(lián)系部分盡可能少的模塊。

相關(guān)資料

• Separation of Concerns

保持事情不再重復(fù)

在一個(gè)系統(tǒng)內(nèi)，每一項(xiàng)認(rèn)識(shí)都必須有一個(gè)單一的、明確的、權(quán)威的表示。

程序中的每一項(xiàng)重要功能都應(yīng)該只在源代碼中的一個(gè)地方實(shí)現(xiàn)。相似的函數(shù)由不同的代碼塊執(zhí)行的情況下，抽象出不同的部分，將它們組合為一個(gè)函數(shù)通常是有益的。

為什么

• 重復(fù)（無(wú)意或有意的重復(fù)）會(huì)造成噩夢(mèng)般的維護(hù)，保養(yǎng)不良和邏輯矛盾。
• 對(duì)系統(tǒng)中任意單個(gè)元素的修改不需要改變其他邏輯上無(wú)關(guān)的元素。
• 此外，相關(guān)邏輯的元素的變化都是可預(yù)測(cè)的和均勻的，因此是保持同步的。

怎么做

• 只在一個(gè)處編寫業(yè)務(wù)規(guī)則、長(zhǎng)表達(dá)式、if語(yǔ)句、數(shù)學(xué)公式、元數(shù)據(jù)等。
• 確定系統(tǒng)中使用的每一項(xiàng)認(rèn)識(shí)的唯一來(lái)源，然后使用該源來(lái)生成該認(rèn)識(shí)的適用實(shí)例（代碼、文檔、測(cè)試等）。
• 使用三法則（Rule of three）.

相關(guān)資料

• Dont Repeat Yourself
• Don’t repeat yourself
• Don’t Repeat Yourself

相似資料

• 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)

為維護(hù)者寫代碼

為什么

• 到目前為止，維護(hù)是任何項(xiàng)目中最昂貴的階段。

怎么做

• 成為維護(hù)者。
• 不論何時(shí)編寫代碼，要想著最后維護(hù)代碼的人是一個(gè)知道自己住在哪里的暴力精神病人。
• 如果某個(gè)入門的人掌握了代碼，他們就會(huì)從閱讀和學(xué)習(xí)代碼中獲得樂(lè)趣，以這樣的想法去編寫代碼和注釋。
• 別讓我想（Don’t make me think）.
• 使用最少驚訝原則（Principle of Least Astonishment）.

相關(guān)資料

• Code For The Maintainer
• The Noble Art of Maintenance Programming

避免過(guò)早優(yōu)化

引用Donald Knuth所說(shuō)：

程序員浪費(fèi)大量的時(shí)間來(lái)思考或擔(dān)心程序的非關(guān)鍵部分的速度，而考驗(yàn)嘗試這些優(yōu)化實(shí)際上在調(diào)試和維護(hù)時(shí)有很強(qiáng)的負(fù)面影響。比如說(shuō)在97%的開發(fā)時(shí)間，我們應(yīng)該忽略低效率：過(guò)早的優(yōu)化是萬(wàn)惡之源。然而，我們不應(yīng)該在關(guān)鍵的3%中放棄我們的機(jī)會(huì)。

當(dāng)然，需要理解什么是“過(guò)早”什么不是“過(guò)早”。

為什么

• 瓶頸在哪是未知的。
• 優(yōu)化后，閱讀和維護(hù)可能會(huì)更困難。

怎么做

• 使它運(yùn)作，使它正確，使它更快（Make It Work Make It Right Make It Fast）
• 不要在你不需要的時(shí)候優(yōu)化，只有在你發(fā)現(xiàn)一個(gè)瓶頸之后才能優(yōu)化它。

相關(guān)資料

• Program optimization
• Premature Optimization

最小化耦合

模塊/組件之間的耦合是它們互相依賴的程度，較低的耦合更好。換句話說(shuō)，耦合是代碼單元“B”在未知的代碼單元“A”更改后“被破壞”的幾率。

為什么

• 一個(gè)模塊的更改通常會(huì)導(dǎo)致其他模塊的更改，產(chǎn)生漣漪效益。
• 由于模塊間的依賴性增加，模塊裝配可能需要更多的工作和/或時(shí)間。
• 特定的模塊可能難以重用和/或測(cè)試，因?yàn)楸仨毎嚓P(guān)模塊。
• 開發(fā)人員可能害怕更改代碼，因?yàn)樗麄儾淮_定什么會(huì)收到影響。

怎么做

• 消除，最小化和降低必要關(guān)聯(lián)的復(fù)雜性。
• 通過(guò)隱藏實(shí)現(xiàn)細(xì)節(jié)，減少耦合。
• 使用[迪米特法則]。

相關(guān)資料

• Coupling
• Coupling And Cohesion

迪米特法則【Law of Demeter or Least Knowledge Principle（LoD or LKP）】

迪米特法則或最少知道原則。它講的是“一個(gè)對(duì)象就盡可能少的去了解其它對(duì)象”，從而實(shí)現(xiàn)松耦合。如果一個(gè)類的職責(zé)過(guò)多，由于多個(gè)職責(zé)耦合在了一起，任何一個(gè)職責(zé)的變更都可能引起其它職責(zé)的問(wèn)題，嚴(yán)重影響了代碼的可維護(hù)性和可重用性。

為什么

• 這通常會(huì)導(dǎo)致更緊密的耦合。
• 可能會(huì)暴露過(guò)多的實(shí)現(xiàn)細(xì)節(jié)。

怎么做

對(duì)象的方法只能調(diào)用以下方法：

1. 對(duì)象自身的方法。
2. 方法參數(shù)中的方法。
3. 方法中創(chuàng)建的任何對(duì)象的方法。
4. 對(duì)象的任何直接屬性或字段的方法。

相關(guān)資料

• Law of Demeter
• The Law of Demeter Is Not A Dot Counting Exercise

組合優(yōu)于繼承

為什么

• 類之間的耦合減少。
• 使用繼承，子類很容易做出假設(shè)，并破壞里氏代換原則（LSP）。

怎么做

• 測(cè)試LSP（可替換性）以決定何時(shí)繼承。
• 當(dāng)存在“有”（或“使用”）的關(guān)系時(shí)使用組合，當(dāng)存在“是”的關(guān)系時(shí)使用繼承。

相關(guān)資料

• Favor Composition Over Inheritance

正交性

正交性的基本概念是，概念上不相關(guān)的東西在系統(tǒng)中不應(yīng)該相關(guān)。

來(lái)源：Be Orthogonal

它越簡(jiǎn)單，設(shè)計(jì)越正交，異常就越少。這使得用編程語(yǔ)言學(xué)習(xí)、讀寫程序變得更容易。正交特征的含義是獨(dú)立于環(huán)境；關(guān)鍵參數(shù)是對(duì)稱性與一致性。

來(lái)源：Orthogonality

穩(wěn)健性原則

堅(jiān)持保守自己的作為，自由接受他人的作為。

合作的服務(wù)依賴于彼此的接口。通常，接口需要提升，導(dǎo)致另一端接收未指定的數(shù)據(jù)。如果接收到的數(shù)據(jù)沒有嚴(yán)格遵守規(guī)范，那么簡(jiǎn)單的實(shí)現(xiàn)將僅拒絕合作。更復(fù)雜的實(shí)現(xiàn)卻可以忽略它無(wú)法識(shí)別的數(shù)據(jù)。

為什么

• 為了能夠提高服務(wù)，你需要確保提供者可以進(jìn)行更改以支持新的需求，同時(shí)對(duì)現(xiàn)有客戶端造成最小的破壞。

怎么做

• 向其他機(jī)器（或同一機(jī)器上的其他程序）發(fā)送指令或數(shù)據(jù)的代碼應(yīng)該完全符合規(guī)范，但接受輸入的代碼應(yīng)接受不一致的輸入，只要其意義明確。

相關(guān)資料

• Robustness Principle in Wikipedia
• Tolerant Reader

控制反轉(zhuǎn)

控制反轉(zhuǎn)又被稱為好萊塢原則，“不要打電話給我們，我們會(huì)打電話給你”。它是一種設(shè)計(jì)原則，計(jì)算機(jī)程序的自定義編寫部分從通用框架接收控制流?？刂品崔D(zhuǎn)具有強(qiáng)烈的含義，即可重用代碼和特定于問(wèn)題的代碼是獨(dú)立開發(fā)的，即使它們?cè)趹?yīng)用程序中一同工作。

為什么

• 控制反轉(zhuǎn)用于提高程序的模塊性，使其具有可擴(kuò)展性。
• 將任務(wù)的執(zhí)行與實(shí)現(xiàn)分離。
• 將模塊集中在其設(shè)計(jì)任務(wù)上。
• 使模塊不受關(guān)于其他系統(tǒng)如何執(zhí)行其任務(wù)的假設(shè)約束，而是依賴于約定。
• 以防止模塊更換時(shí)出現(xiàn)副作用。

怎么做

• 使用工廠模式
• 使用服務(wù)定位器模式
• 使用依賴注入
• 使用依賴查找
• 使用模板方法模式
• 使用策略模式

相關(guān)資料

• Inversion of Control in Wikipedia
• Inversion of Control Containers and the Dependency Injection pattern

最大化聚合

單個(gè)模塊/組件的聚合性是其職責(zé)形成有意義的單元的程度，越高的聚合性越好。

為什么

• 增加了理解模塊的難度。
• 增加了維護(hù)系統(tǒng)的難度，因?yàn)橛蛑羞壿嫷母臅?huì)影響多個(gè)模塊，并且一個(gè)模塊的更改需要相關(guān)模塊的更改。
• 由于大多數(shù)應(yīng)用程序不需要模塊提供的隨機(jī)操作集，因此重用模塊的難度增加。

怎么做

• 與組相關(guān)的功能共享一項(xiàng)職責(zé)（例如在一個(gè)類中）。

相關(guān)資料

• Cohesion
• Coupling And Cohesion

里氏替換原則【Liskov Substitution Principle（LSP）】

里氏替換原則（LSP）完全是關(guān)于對(duì)象的預(yù)期行為：

程序中的對(duì)象應(yīng)該可以替換為其子類型的實(shí)例，而不會(huì)改變?cè)摮绦虻恼_性。

相關(guān)資源

• Liskov substitution principle
• Liskov Substitution Principle

開-閉原則【Open-Close Principle（OCP）】

軟件實(shí)體（例如類）應(yīng)對(duì)擴(kuò)展是開放的，但對(duì)修改是封閉的。也就是說(shuō)，這樣的實(shí)體可以允許在不改變其源代碼的情況下修改其行為。

為什么

• 通過(guò)最小化對(duì)現(xiàn)有代碼的修改來(lái)提高可維護(hù)性和穩(wěn)定性

怎么做

• 編寫可以擴(kuò)展的類（而不是可以修改的類）
• 只暴露需要更換的活動(dòng)部分，隱藏其他所有部分。

相關(guān)資源

• Open Closed Principle
• The Open Closed Principle

單一職責(zé)原則【Single Responsibility Principle（SRP）】

一個(gè)類不應(yīng)該有多個(gè)修改的原因。

長(zhǎng)話版：每個(gè)類都應(yīng)該有一個(gè)單獨(dú)的職責(zé)，并且該職責(zé)應(yīng)該完全由該類封裝。職責(zé)可以定義為修改的原因，一次類或模塊應(yīng)該有且僅有一個(gè)修改的原因。

為什么

• 可維護(hù)性：僅有一個(gè)模塊或類中需要修改。

怎么做

• 使用 [科里定律]

相關(guān)資料

• Single responsibility principle

隱藏實(shí)現(xiàn)細(xì)節(jié)

軟件模塊通過(guò)提供接口來(lái)隱藏信息（即實(shí)現(xiàn)細(xì)節(jié)），而不泄露任何不必要的信息。

為什么

• 當(dāng)實(shí)現(xiàn)更改時(shí)，客戶端使用的接口不必更改。

怎么做

• 最小化類和成員的可訪問(wèn)性。
• 不要公開成員數(shù)據(jù)。
• 避免將私有實(shí)現(xiàn)細(xì)節(jié)放入類的接口中。
• 減少耦合以隱藏更多實(shí)現(xiàn)細(xì)節(jié)。

相關(guān)資料

• Information hiding

科里定律

科里定律是關(guān)于為任何特定代碼選擇一個(gè)明確定義的目標(biāo)：僅做一件事。

• Curly’s Law: Do One Thing
• The Rule of One or Curly’s Law

封裝經(jīng)常修改的代碼

一個(gè)好的設(shè)計(jì)可以辨別出最有可能改變的熱點(diǎn)，并將它們封裝在API之后。當(dāng)預(yù)期的修改發(fā)生時(shí)，修改會(huì)保持在局部。

為什么

• 在發(fā)生更改時(shí)，最小化所需的修改。

怎么做

• 封裝API背后不同的概念。
• 將可能不同的概念分到各自的模塊。

相關(guān)資料

• Encapsulate the Concept that Varies
• Encapsulate What Varies
• Information Hiding

接口隔離原則

將臃腫的接口減少到多個(gè)更小更具體的客戶端特定接口中。接口應(yīng)該比實(shí)現(xiàn)它的代碼更依賴于調(diào)用它的代碼。

為什么

• 如果類實(shí)現(xiàn)了不需要的方法，則調(diào)用方需要了解該類的方法實(shí)現(xiàn)。例如，如果一個(gè)類實(shí)現(xiàn)了一個(gè)方法，但只是簡(jiǎn)單的拋出異常，那么調(diào)用方將需要知道實(shí)際上不應(yīng)該調(diào)用這個(gè)方法。

怎么做

• 避免臃腫的接口。類不應(yīng)該實(shí)現(xiàn)任何違反[單一職責(zé)原則]的方法。

相關(guān)資料

• Interface segregation principle

童子軍軍規(guī)

美國(guó)童子軍有一條簡(jiǎn)單的軍規(guī)，我們可以使用到我們的職業(yè)中：“離開營(yíng)地時(shí)比你到達(dá)時(shí)更干凈”。根據(jù)童子軍軍規(guī)，我們應(yīng)該至終保持代碼比我們看到時(shí)更干凈。

為什么

• 當(dāng)對(duì)現(xiàn)有代碼庫(kù)進(jìn)行更改時(shí)，代碼質(zhì)量往往會(huì)降低，從而積累技術(shù)債務(wù)。根據(jù)童子軍軍規(guī)，我們應(yīng)該注意每一個(gè)提交（Commit）的質(zhì)量。無(wú)論規(guī)模有多小，技術(shù)債務(wù)都會(huì)受到不斷重構(gòu)的抵制。

怎么做

• 每次提交都要確保它不會(huì)降低代碼庫(kù)的質(zhì)量。
• 任何時(shí)候，如果有人看到一些代碼不夠清楚，他們就應(yīng)該抓住機(jī)會(huì)在那里修復(fù)它。

相關(guān)資料

• Opportunistic Refactoring

命令查詢分離

命令查詢分離原則規(guī)定，每個(gè)方法都應(yīng)該是執(zhí)行操作的命令，或者是向調(diào)用者返回?cái)?shù)據(jù)但不能同時(shí)做兩件事的查詢。提問(wèn)不應(yīng)該改變答案。

利用這個(gè)原則，程序員可以更加自信地進(jìn)行編碼。查詢方法可以在任何地方以任何順序使用，因?yàn)樗鼈儾粫?huì)改變狀態(tài)。而使用命令，你必須更加小心。

為什么

• 通過(guò)將方法清晰地分為查詢和命令，程序員可以在不了解每個(gè)方法的實(shí)現(xiàn)細(xì)節(jié)的情況下，更加自信地編碼。

怎么做

• 將每個(gè)方法實(shí)現(xiàn)為查詢或命令。
• 對(duì)方法名使用命名約定，該方法名表示該方法是查詢還是命令。

相關(guān)資料

• Command Query Separation in Wikipedia
• Command Query Separation by Martin Fowler