全文共3257字，預計學習時長10分鐘
評論區常常有小夥伴推薦羅伯特·C·馬丁的《代碼整潔之道（Clean Code）》。今天我們就來了解一下這本書，它值不值得一看？
關於此書
《代碼整潔之道》出版於2008年，近年來，一直被列為「亞馬遜最暢銷的五本書」之一。本書作者被親切地稱為「Bob叔叔」，他也是《敏捷宣言》的原作者之一，資歷非常豐富。本書在Goodreads上平均評分為4.4（評分人數超13,000）。可以說，這是一本程式設計師的必讀書。
本文將本書精簡為五個要點。
1.尊重抽象
《代碼整潔之道》中寫到：如果要確保函數僅做一件事，則需要確保每個函數的語句都位於同一抽象層次。
為說明這一點，馬丁用了以下示例（出自FitNesse）：
public String render() throws Exception{ StringBuffer html =new StringBuffer("<hr"); if (size >0) html.append(" size="").append(size + 1).append("\""); html.append(">"); return html.toString();} 在GitHub上查看no_abstraction.java原始碼
這裡至少混合了兩個抽象層次。第一個是固定大小的hr標籤的高級概念，第二個是處理實際標籤構造的低級語法細節。為了說明這一點，對代碼進行更清晰地重構，如下所示：
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);} 在GitHub上查看abstraction.java原始碼
注意：
· Render（）函數現在僅負責構建hr標籤
· 將構建標籤的底層詳細信息的任務轉給HtmlTag模塊
· 大小格式被抽象為獨立的函數
馬丁認為：
「分離抽象層次是重構最重要的功能之一，也是最難實現的功能之一。」
當然，在以後的代碼中，我會有更多考慮。
2.整潔代碼關乎規則，要花大量精力
我不希望本文僅是列出編寫整潔代碼的要點和規則。對本書而言這也無甚作用——因為採取教條式的教學方法是遠遠不夠的。
相反，在本書中馬丁呼籲發展強烈的個人原則感，且不斷說明將「髒代碼」變整潔所需的努力和職責。本書將其稱為「代碼感」，它要求「嚴格使用艱難獲得整潔代碼的大量小技巧。」
「整潔代碼並非遵循一組規則編寫的。不可能因為學習一套金規玉律就成為軟體大師。專業精神和手工藝來自於推動規則形成的價值。」 —羅伯特·C·馬丁（RobertC. Martin）
就個人而言，我沒什麼自信，所以很喜歡這種說法。就連Bob叔叔都堅信編寫代碼是一份需要嚴肅自律的工作，要花費大量精力，真是極大的安慰。為了真正擅於整潔代碼，我們需要迭代我們作為程式設計師的個人開發以及代碼的開發。
3.代碼儘量精簡
「函數的首要規則是體積小。第二規則是使其儘可能地變小。」 ——羅伯特·C·馬丁
這裡有兩個含義：
· 函數本身應該簡短——幾乎不超過20行，大多數情況下少於10行
· 函數應儘可能不要採用參數
簡潔函數能增加代碼的易讀性。這也使我們傾向於編寫功能單一高效的函數。
對於類，他也有類似的看法。他建議使用「職責」而非「代碼行」來衡量類的大小。即一個類應該只有一個職責。這就是所謂的「單一職責原則」（SRP）。
保持代碼簡短是「分劃」策略，如果一個大文件包含大量冗長而複雜的代碼，則可以將該文件分為多個模塊，將模塊分為多個函數，再將函數分為多個子函數，直至看到代碼邏輯和任務。
4.編程是工藝
我時常認為，將編程喻為建築和構造並不恰當。因為程式設計師不會做一個完整的設計，從頭開始建基，再一步步搭建直至完工。
編程的步驟是：先畫草圖，再反覆添加細節。程式設計師要做的是修改、完善和擴展——這些都在各抽象層次上完成，直到軟體滿足要求為止。而軟體永遠不會真正完成。
這就是《代碼整潔之道》的中心思想。貫穿全書的要點是：軟體是一門藝術，做軟體就像「畫畫」。作者認為編程的本質是一門工藝。
但如何讓編程從單純地寫代碼變成「工藝」呢？
馬丁認為，程式設計師掌握的主要工具是持續重構和測試驅動開發（TDD）。兩者像硬幣的兩面般協同工作。來看一些概念：
重構是在不更改輸出的情況下調整現有計算機代碼結構的過程。
測試驅動開發是將需求轉換為特定測試用例，再添加代碼以使測試通過的過程。
因此，製作軟體的過程可能如下所示：
1. 編寫測試代碼以驗證所需但未實現的功能。
2. 編寫有效代碼（可能不整潔），並通過測試。
3. 逐步重構代碼（保證每次通過測試），使代碼在每次開發迭代中都更加清晰。
「不要想著一次性編程後系統就能正確、漂亮地運行。今日的任務僅僅是讓程序運行起來，而重構和擴展系統是明天的任務。這是迭代和增量敏捷的本質。」——羅伯特·C·馬丁
因此，本書的中心思想是，整潔代碼是在開發和實踐中實現的，而非簡單地一口氣創建出來。
5.代碼本身清晰易讀
注釋很少卻清晰、表達力強的代碼優於注釋多的混亂、複雜的代碼。」 ——羅伯特·C·馬丁
在「注釋、有意義的命名和格式「一章中，馬丁強烈主張代碼本身應該清晰易讀。示例：
// Check to see if theemployee is eligible for full benefitsif ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
將其重構為：
if(employee.isEligibleForFullBenefits())
注意：
· 刪除注釋
· 條件邏輯封裝到一個方法中
· 因為使用的是方法而不是獨立函數，因此可以使用實例變量，從而創建調用零參數的方法
· 給該方法起一個描述性的名稱，使其職責更加明確
《代碼整潔之道》關於命名寫了整整一個章節，本質上是對Tim Ottinger規則的詳細說明。包括：
· 設置可讀性高的名稱——例如，int elapsedTimeInDays，而不是in days
· 使用讀得出來的名稱——例如，客戶而不是DtaRcrd102
· 避免使用編碼——不要用前綴m_表示"members"，也不要使用匈牙利表示法
· 每個概念對應一個詞——不要fetch,retrieve,get多個概念對應一個詞
結語
《代碼整潔之道》中，並非每個想法都是Bob叔叔提出的，他在書中的各部分都承認了這一點。而這反而是使本書如此成功的一個原因——它是編程界智慧的匯聚，並附有實例。
如果要說一個小瑕疵，那就是與高層概念的章節相比，有關底層細節的章節有點少。「系統」章只有13頁，僅僅是「注釋「章的一半。但是，我懷疑減少對系統的重視，是為了將討論保留在他後來的書《架構整潔之道（CleanArchitecture）》中。
綜合考慮，這真的是目前最好的編程書籍之一，我會把該書放到我的2021年書單中。
留言點讚關注
我們一起分享AI學習與發展的乾貨
如轉載，請後臺留言，遵守轉載規範