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