編寫好代碼的10條戒律

1. DRY: 不要重複你本身（Don’t repeat yourself）

　　DRY是一條最容易理解但又是相對比較難以應用的原則。它是指當你在兩處或者更多的地方發現類似代碼時，咱們應當把它們抽象成一個新的函數，在以前重複的地方調用新的函數並帶上適當的參數。

　　DRY也許是最廣泛的一條編程原則，我從未發現一個開發人員認爲編寫重複的代碼是件好事。可是我發現一些開發人員在編寫單元測試時忘記了這條原則，例如：設想一下你改變了一個類的接口，以前已經爲這個類編寫了不少的單元測試，若是你沒有應用DRY原則，這時你須要手動去修改全部使用這個類接口的調用，來與每個測試實例的新簽名匹配。


　　2. 編寫短小的函數/方法

　　有三個很是好的理由，選擇編寫短小的函數。

• 1. 代碼會更容易閱讀。

• 2. 代碼會更容易重用（短小的函數更容易產生鬆耦合）。

• 3. 代碼會更易於測試。

　　編者注：鬆耦合：在軟件領域中，「耦合」通常指軟件組件之間的依賴程度。耦合度鬆的軟件會有較好的擴展性。


　　3. 給類、函數和變量使用好的命名

　　直接使用其餘開發者的代碼而不須要閱讀說明文檔，沒有什麼比這更好的事情了，由於代碼中的類名、函數名已經可以告訴咱們全部須要的信息。因此，採用這種方法，每次在爲你的代碼中任何元素進行命名的以前請花上幾秒鐘（思考），這會讓你們的生活變得更輕鬆。


　　4. 爲每一個類分配正確的職責

　　一個類只承擔一個職責（單一權責），聽起來和有些人知道的SOLID原則很類似，可是這裏不是指任意的職責，而是正確的職責。因此，若是咱們要設計一個顧客類，咱們不會給它建立一個銷售的行爲，咱們只會讓它處理全部與一個客戶相關的數據。

　　編者注：SOLID：面向對象設計的五項原則 （是SRP單一職責原則、OCP開閉原則、LSP李式代換原則、ISP依賴反轉原則和 DIP接口分離原則，首字符的縮寫)。


　　5. 保持代碼的條理性

　　代碼條理性分兩個層次

• 物理上的條理性：不管你採用了哪一種結構，包、命名空間、文件夾等等，用一種更容易而且憑直覺就能找到代碼存放在哪裏的方式來組織你編寫的類。

• 邏輯上的條理性：不論邏輯上從屬關係如何，（只要有邏輯從屬關係）類都應該可以互相訪問彼此的成員變量，可是若是從屬於不一樣的邏輯結構就應當只能經過接口來訪問。這種邏輯分組一般會被實現成（邏輯）層、服務等。

　　6. 編寫不少的單元測試

　　測試越多越好，它們是全部代碼變更的安全保證，咱們會在未來的某一天須要運行這些測試代碼。


　　7. 儘早且常常地重構代碼（Refactor often and sooner）

　　軟件開發是一個持續發現的過程，爲了編寫保持與新增/改變的需求匹配的高質量代碼，隨着開發的進行，重構代碼是必不可少的。因爲重構是一項帶有風險的任務，須要有兩個主要的前提條件，來避免因爲重構給系統引入新的錯誤。

• 1. 編寫不少的單元測試

• 2. 每一次重構的幅度要比較小。在開發軟件過程當中，開始重構2000行代碼，3個小時之後發現全部的代碼都不能工做，而且致使問題的緣由無從查找，所以須要恢復到最第一版本，幾乎沒什麼事能比這更讓人抓狂了。

　　8. 註釋是惡魔

　　這條特殊戒律有一點爭議，咱們大多數人學到的是「註釋是一個好的習慣」，而且在一段晦澀的代碼中有一段註釋會比僅僅只有代碼好的多，這裏個人觀點是：給晦澀的代碼加註釋還不如僅僅留下代碼，只須要重構這段代碼直到它變得可讀爲止。（編注：固然了，除了做者說的這種類型的代碼，在其餘狀況下，仍是得添加必要的註釋，這不只方便本身往後查看，更有利於後來者維護，請參閱《提升代碼可讀性的10個註釋技巧 》一文。


　　9. 要面向接口編程，不要面向實現編程（Code to an interface, not to an implementation）

　　這是一條經典的原則，面向接口編程會讓咱們從實現的細節中解放出來，咱們只要定義一個協議，而且依據協議調用定義的操做，指望（對方，即被調用的代碼）能把實際的實現或者運行時態的實現傳遞給咱們的代碼。


　　10. 對代碼進行復查　　咱們都會犯錯誤，沒有什麼能比請別人對咱們代碼作一個非正式快速複查更好的辦法來查找錯誤了。最好不要等到代碼都完成之後再複查，當某些重要部分的代碼完成後，或者離上一次複查相隔幾天以後，就進行復查。