《代碼整潔之道》：5大基本要點
常常有小伙伴推薦羅伯特·C·馬丁的《代碼整潔之道(Clean Code)》。今天我們就來了解一下這本書，它值不值得一看?
關于此書
《代碼整潔之道》出版于2008年，近年來，一直被列為“亞馬遜最暢銷的五本書”之一。本書作者被親切地稱為“Bob叔叔”，他也是《敏捷宣言》的原作者之一，資歷非常豐富。本書在Goodreads上平均評分為4.4(評分人數超13,000)。可以說，這是一本程序員的必讀書。
本文將本書精簡為五個要點。
1. 尊重抽象
圖片：abstraction(抽象)圖源： Abstruse Goose
《代碼整潔之道》中寫到：如果要確保函數僅做一件事，則需要確保每個函數的語句都位于同一抽象層次。
為說明這一點，馬丁用了以下示例(出自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. 編程是工藝
我時常認為，將編程喻為建筑和構造并不恰當。因為程序員不會做一個完整的設計，從頭開始建基，再一步步搭建直至完工。
編程的步驟是：先畫草圖，再反復添加細節。程序員要做的是修改、完善和擴展——這些都在各抽象層次上完成，直到軟件滿足要求為止。而軟件永遠不會真正完成。
這就是《代碼整潔之道》的中心思想。貫穿全書的要點是：軟件是一門藝術，做軟件就像“畫畫”。作者認為編程的本質是一門工藝。
圖片：“ Good Code(好代碼)” 網站：xkcd
但如何讓編程從單純地寫代碼變成“工藝”呢?
馬丁認為，程序員掌握的主要工具是持續重構和測試驅動開發(TDD)。兩者像硬幣的兩面般協同工作。來看一些概念：
重構是在不更改輸出的情況下調整現有計算機代碼結構的過程。
測試驅動開發是將需求轉換為特定測試用例，再添加代碼以使測試通過的過程。
因此，制作軟件的過程可能如下所示：
- 編寫測試代碼以驗證所需但未實現的功能。
- 編寫有效代碼(可能不整潔)，并通過測試。
- 逐步重構代碼(保證每次通過測試)，使代碼在每次開發迭代中都更加清晰。
| “不要想著一次性編程后系統就能正確、漂亮地運行。今日的任務僅僅是讓程序運行起來，而重構和擴展系統是明天的任務。這是迭代和增量敏捷的本質。”
——羅伯特·C·馬丁 |
因此，本書的中心思想是，整潔代碼是在開發和實踐中實現的，而非簡單地一口氣創建出來。
來源：Pexels
5. 代碼本身清晰易讀
注釋很少卻清晰、表達力強的代碼優于注釋多的混亂、復雜的代碼。” ——羅伯特·C·馬丁
在“注釋、有意義的命名和格式“一章中，馬丁強烈主張代碼本身應該清晰易讀。示例：
- // Check to see if theemployee is eligible for full benefits
- if ((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年書單中。
