程序員書庫（ID：CodingBook）編譯
鏈接：https://medium.com/better-programming/clean-code-5-essential-takeaways-2a0b17ccd05c
Bob叔有一句名言：任何一個傻瓜都能寫出計算機可以理解的代碼，惟有寫出人類容易理解的代碼，才是優秀的程序員。
Bob叔的《代碼整潔之道》相信大家都不陌生，2008年出版，一直被亞馬遜評為銷量最高的5本技術書籍之一，作者也被親切的成為“Bob叔”，他還是敏捷軟件開發宣言(2001)的17位簽署者之一。
《代碼整潔之道》在美亞上已經有13000個評價，平均評分4.4，在豆瓣上也有1650個人評價，豆瓣評分8.6，看完這本書，我將本書的5個要點提煉出來：
1、編程是門手藝
架構知識軟件開發中用到的借喻之一，不要創建一個完整的設計，然後從頭開始創建，一步步構建成一個完整的軟件，相反，我們應該從一個草圖開始，不斷迭代添加細節，不斷修改、改進、擴展——在不同的抽象層次上構建，直到我們需要的軟件構造完成。但記住，軟件永遠不會真正的完成。
這才是《代碼整潔之道》的精髓所在，在整本書裡，作者始終在傳達一個理念：軟件是一門藝術，就和畫畫一樣，本質上，他認為編程是一門手藝。
但是，我們如何從簡單的編寫代碼過渡到編寫整潔的代碼？Martin認為，我們有兩大途徑持續重構和測試驅動開發（TDD），它們就像硬幣的兩面，具有相互作用。以下是一些定義：
- 重構就是在不改變外部行為的情況下重構現有計算機代碼的過程
- 測試驅動的開發是一個過程，在這個過程中，需求被轉換成特定的測試用例，然後只編寫使測試通過的功能代碼。
因此，製作軟件的過程可能是這樣的：
- 編寫失敗測試，以驗證所需但未實現的功能
- 編寫一些(可能不好的)代碼，使這些測試通過。
- 增多重構代碼，測試通過，使得每次開發迭代都變得更加清晰。
Martin提出一箇中心思想就是整潔代碼，它是在開發過程和實踐中產生，而不是一次簡單的創建就可以。
2、保持簡短
函數的第一條規則是它們應該很小。函數的第二個規則是它們應該比小更小。
Martin的這句話就兩意思：函數體應該很短——幾乎不超過20行，大多數不超過10行；函數應該儘可能設置少的參數，最好不要有參數。
函數的簡潔性使代碼更容易閱讀，每個函數一個抽象層級。Martin在“類”上也提出了類似的觀點，他建議使用職責來衡量，而不是代碼行數，也就是說每個類應該只負責一件事，這就是所謂的單一責任原則（SRP）。
保持簡短是使代碼更簡潔的策略，如果我們有一個大文件，裡面有很多冗長、複雜的代碼，我們可以把這個文件分成模塊，把模塊分成函數，把函數分成子函數，知道邏輯和目的變得清晰為止。
3、代碼可讀性
帶有少量註釋的整潔而有表達力的代碼，要比帶有大量註釋的零碎而複雜的代碼像樣得多。
在關於註釋、格式這部分內容中，Martin給出了強有力的例子，你是更願意看到這段代碼：
<code>// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))/<code>
還是這一段代碼：
<code>if (employee.isEligibleForFullBenefits())/<code>
條件邏輯被封裝到一個方法中，因為使用的是方法而不是獨立函數，所以可以使用實例變量，從而創建零參數的方法調用，該方法還使用了描述性的名稱，使“整潔代碼”的職責更加明確。這本書專門設了一章來介紹命名，本質上是對Tim Ottinger規則的詳細說明。例如：
- 能夠清晰表達意圖——諸如用int elapsedTimeInDays，而不是in days
- 使用讀得出來的名稱——例如，客戶而不是DtaRcrd102
- 避免使用編碼——不要用前綴m_表示"members"，也不要使用匈牙利表標記法
- 每個概念對應一個詞——不要使用fetch,retrieve,get去給多個類中的同個方法命名。
4、尊重抽象
根據書中說的，如果我們想要確保我們的函數只做一件事，我們需要確保每個函數中的語句都處於相同的抽象級別。Martin用以下來自FitNesse的例子來說明這一點：
<code>public String render() throws Exception{
StringBuffer html = new StringBuffer("
if (size > 0)
html.append(" size="").append(size + 1).append("\"");
html.append(">");
return html.toString();
}/<code>這裡至少混合了兩個抽象層次。第一個是呈現具有給定大小的hr標記的高級概念，第二個是處理實際構造標記的低級語法細節。（詳細代碼：https://gist.github.com/jamiebullock/e92efb17b58af81b49bc6568b0de4a4e/raw/cc1c341430b40eeb4754033a086848561c960012/no_abstraction.java）
為了說明這一點，代碼被重構得更乾淨，如下所示：
<code>public String render() throws Exception{
HtmlTag hr = new HtmlTag("hr");
if (extraDashes > 0)
hr.addAttribute("size", hrSize(extraDahses));
return hr.html();
}
private String hrSize(int height){
int hrSize = height + 1;
return String.format("%d", hrSize);
}/<code>注:render()函數現在只負責構造一個hr標籤；構造標記的底層細節現在由HtmlTag模塊負責；大小格式被抽象為一個單獨的函數
按照Martin說的：分離抽象層次是重構最重要的功能之一，也是最難實現的功能之一。這當然也是我們在今後的代碼中需要多多考慮的問題。
5、《代碼整潔之道》是關於原則和如何努力工作的一本書
我寫這篇文章的目的不僅僅只是為了羅列出《代碼整潔之道》裡面的重點和名言，總結我們可以應用的規則，以獲得整潔的代碼，這樣做對這本書來說是一種傷害，因為這本書本身還沒有達到這種教條主義的地步。
相反，讓我印象更為深刻的是，Martin在引導我們培養一種強烈的個人原則意識，並不斷地說明將代碼從“髒”變成“整潔”所需要付出的努力，在書裡也稱之為“代碼感”，這需要“不斷的嚴格運用各種代碼技巧，才能達到所謂的整潔感”
寫在最後
《代碼整潔之道》書中的每一條規則並非都是由Bob叔提出的，他在書中多次公開承認這一點。如果說有什麼不同的話，那就是這是本書如此成功的原因之一——它是對編程社區中各種智慧的提煉，並使用了實際例子讓它變得更加充實。
如果本書還有什麼不足的話，我覺得有一個，就是關於細節的章節和關於概念的章節配比有點不平衡，比如系統這一章只有13頁，幾乎只有註釋那一章節的一般，我猜他這樣做的原因，是想要吧這一部分的內容，留到《Clean Architecture》中去討論。除此之外，我覺得這是最好的編程書籍之一。
閱讀更多 程序員BUG 的文章
