什麼是整潔代碼？大咖程式設計師們這樣說

這是本有關編寫好程序的書。它充斥著代碼。我們要從各個方向來考察這些代碼。從頂向下，從底往上，從裡而外。讀完後，就能知道許多關於代碼的事了。

《代碼整潔之道》

馬丁 著

而且，我們還能說出好代碼和糟糕的代碼之間的差異。我們將瞭解到如何寫出好代碼。我們也會知道，如何將糟糕的代碼改成好代碼。

閱讀本書有兩種原因：第一，你是個程序員；第二，你想成為更好的程序員。很好。我們需要更好的程序員。

要有代碼

有人也許會以為，關於代碼的書有點兒落後於時代——代碼不再是問題；我們應當關注模型和需求。確實，有人說過我們正在臨近代碼的終結點。很快，代碼就會自動產生出來，不需要再人工編寫。程序員完全沒用了，因為商務人士可以從規約直接生成程序。

扯淡！我們永遠拋不掉代碼，因為代碼呈現了需求的細節。在某些層面上，這些細節無法被忽略或抽象，必須明確之。將需求明確到機器可以執行的細節程度，就是編程

我期望語言的抽象程度繼續提升。我也期望領域特定語言的數量繼續增加。那會是好事一樁。但那終結不了代碼。實際上，在較高層次上用領域特定語言撰寫的規約也將是代碼！它也得嚴謹、精確、規範和詳細，好讓機器理解和執行。

那幫以為代碼終將消失的夥計，就像是巴望著發現一種無規範數學的數學家們一般。他們巴望著，總有一天能創造出某種機器，我們只要想想、嘴都不用張就能叫它依計行事。那機器要能透徹理解我們，只有這樣，它才能把含糊不清的需求翻譯為可完美執行的程序，精確滿足需求。

這種事永遠不會發生。即便是人類，傾其全部的直覺和創造力，也造不出滿足客戶模糊感覺的成功系統來。如果說需求規約原則教給了我們什麼，那就是歸置良好的需求就像代碼一樣正式，也能作為代碼的可執行測試來使用。

記住，代碼確然是我們最終用來表達需求的那種語言。我們可以創造各種與需求接近的語言。我們可以創造幫助把需求解析和彙整為正式結構的各種工具。然而，我們永遠無法拋棄必要的精確性——所以代碼永存。​

糟糕的代碼

最近我在讀Kent Beck著Implementation Patterns（中譯版《實現模式》）[1]一書的序言。他這樣寫道：“……本書基於一種不太牢靠的前提：好代碼的確重要……”這前提不牢靠？我反對！我認為這是該領域最強固、最受支持、最被強調的前提了（我想Kent也知道）。我們知道好代碼重要，是因為其短缺實在困擾了我們太久。

20世紀80年代末，有家公司寫了個很流行的殺手應用，許多專業人士都買來用。然後，發佈週期開始拉長。缺陷總是不能修復。裝載時間越來越久，崩潰的幾率也越來越大。至今我還記得自己在某天沮喪地關掉那個程序，從此再不用它。在那之後不久，該公司就關門大吉了。

20年後，我見到那家公司的一位早期僱員，問他當年發生了什麼事。他的回答叫我愈發恐懼起來。原來，當時他們趕著推出產品，代碼寫得亂七八糟。特性越加越多，代碼也越來越爛，最後再也沒法管理這些代碼了。是糟糕的代碼毀了這家公司。

你是否曾為糟糕的代碼所深深困擾？如果你是位有點兒經驗的程序員，定然多次遇到過這類困境。我們有專用來形容這事的詞：沼澤（wading）。我們趟過代碼的水域。我們穿過灌木密佈、瀑布暗藏的沼澤地。我們拼命想找到出路，期望有點什麼線索能啟發我們到底發生了什麼事；但目光所及，只是越來越多死氣沉沉的代碼。

你當然曾為糟糕的代碼所困擾過。那麼——為什麼要寫糟糕的代碼呢？

是想快點完成嗎？是要趕時間嗎？有可能。或許你覺得自己要幹好所需的時間不夠；假使花時間清理代碼，老闆就會大發雷霆。或許你只是不耐煩再搞這套程序，期望早點結束。或許你看了看自己承諾要做的其他事，意識到得趕緊弄完手上的東西，好接著做下一件工作。這種事我們都幹過。

我們都曾經瞟一眼自己親手造成的混亂，決定棄之而不顧，走向新一天。我們都曾經看到自己的爛程序居然能運行，然後斷言能運行的爛程序總比什麼都沒有強。我們都曾經說過有朝一日再回頭清理。當然，在那些日子裡，我們都沒聽過勒布朗（LeBlanc）法則：稍後等於永不（Later equals never）。

混亂的代價

只要你幹過兩三年編程，就有可能曾被某人的糟糕的代碼絆倒過。如果你編程不止兩三年，也有可能被這種代碼拖過後腿。進度延緩的程度會很嚴重。有些團隊在項目初期進展迅速，但有那麼一兩年的時間卻慢如蝸行。對代碼的每次修改都影響到其他兩三處代碼。修改無小事。每次添加或修改代碼，都得對那堆扭紋柴瞭然於心，這樣才能往上扔更多的扭紋柴。這團亂麻越來越大，再也無法理清，最後束手無策。

隨著混亂的增加，團隊生產力也持續下降，趨向於零。當生產力下降時，管理層就只有一件事可做了：增加更多人手到項目中，期望提升生產力。可是新人並不熟悉系統的設計。他們搞不清楚什麼樣的修改符合設計意圖，什麼樣的修改違背設計意圖。而且，他們以及團隊中的其他人都揹負著提升生產力的可怕壓力。於是，他們製造更多的混亂，驅動生產力向零那端不斷下降。如圖1-1所示。

圖1-1　生產力vs.時間

1 華麗新設計

最後，開發團隊造反了，他們告訴管理層，再也無法在這令人生厭的代碼基礎上做開發。他們要求做全新的設計。管理層不願意投入資源完全重啟爐灶，但他們也不能否認生產力低得可怕。他們只好同意開發者的要求，授權去做一套看上去很美的華麗新設計。

於是就組建了一支新軍。誰都想加入這個團隊，因為它是張白紙。他們可以重新來過，搞出點真正漂亮的東西來。但只有最優秀、最聰明的傢伙被選中。其餘人等則繼續維護現有系統。

現在有兩支隊伍在競賽了。新團隊必須搭建一套新系統，要能實現舊系統的所有功能。另外，還得跟上對舊系統的持續改動。在新系統功能足以抗衡舊系統之前，管理層不會替換掉舊系統。

競賽可能會持續極長時間。我就見過延續了十年之久的。到了完成的時候，新團隊的老成員早已不知去向，而現有成員則要求重新設計一套新系統，因為這套系統太爛了。

假使你經歷過哪怕是一小段我談到的這種事，那麼你一定知道，花時間保持代碼整潔不但有關效率，還有關生存.

2 態度

你是否遇到過某種嚴重到要花數個星期來做本來只需數小時即可完成的事的混亂狀況？你是否見過本來只需做一行修改，結果卻涉及上百個模塊的情況？這種事太常見了。

怎麼會發生這種事？為什麼好代碼會這麼快就變質成糟糕的代碼？理由多得很。我們抱怨需求變化背離了初期設計。我們哀嘆進度太緊張，沒法幹好活。我們把問題歸咎於那些愚蠢的經理、苛求的用戶、沒用的營銷方式和那些電話消毒劑。不過，親愛的呆伯特（Dilbert）[2]，我們是自作自受[3]。我們太不專業了。

這話可不太中聽。怎麼會是自作自受呢？難道不關需求的事？難道不關進度的事？難道不關那些蠢經理和沒用的營銷手段的事？難道他們就不該負點責嗎？

不。經理和營銷人員指望從我們這裡得到必須的信息，然後才能做出承諾和保證；即便他們沒開口問，我們也不該羞於告知自己的想法。用戶指望我們驗證需求是否都在系統中實現了。項目經理指望我們遵守進度。我們與項目的規劃脫不了干係，對失敗負有極大的責任；特別是當失敗與糟糕的代碼有關時尤為如此！

“且慢！”你說。“不聽經理的，我就會被炒魷魚。”多半不會。多數經理想要知道實情，即便他們看起來不喜歡實情。多數經理想要好代碼，即便他們總是痴纏於進度。他們會奮力衛護進度和需求；那是他們該乾的。你則當以同等的熱情衛護代碼。

再說明白些，假使你是位醫生，病人請求你在給他做手術前別洗手，因為那會花太多時間，你會照辦嗎[4]？本該是病人說了算；但醫生卻絕對應該拒絕遵從。為什麼？因為醫生比病人更瞭解疾病和感染的風險。醫生如果按病人說的辦，就是一種不專業的態度（更別說是犯罪了）。

同理，程序員遵從不瞭解混亂風險的經理的意願，也是不專業的做法。

3 迷題

程序員面臨著一種基礎價值謎題。有那麼幾年經驗的開發者都知道，之前的混亂拖了自己的後腿。但開發者們揹負期限的壓力，只好製造混亂。簡言之，他們沒花時間讓自己做得更快！

真正的專業人士明白，這道謎題的第二部分說錯了。製造混亂無助於趕上期限。混亂只會立刻拖慢你，叫你錯過期限。趕上期限的唯一方法——做得快的唯一方法 ——就是始終儘可能保持代碼整潔。

4 整潔代碼的藝術

假設你相信混亂的代碼是禍首，假設你接受做得快的唯一方法是保持代碼整潔的說法，你一定會自問：“我怎麼才能寫出整潔的代碼？”不過，如果你不明白整潔對代碼有何意義，嘗試去寫整潔代碼就毫無所益！

壞消息是寫整潔代碼很像是繪畫。多數人都知道一幅畫是好還是壞。但能分辨優劣並不表示懂得繪畫。能分辨整潔代碼和骯髒代碼，也不意味著會寫整潔代碼！

寫整潔代碼，需要遵循大量的小技巧，貫徹刻苦習得的“整潔感”。這種“代碼感”就是關鍵所在。有些人生而有之。有些人費點勁才能得到。它不僅讓我們看到代碼的優劣，還予我們以借戒規之力化劣為優的攻略。

缺乏“代碼感”的程序員，看混亂是混亂，無處著手。有“代碼感”的程序員能從混亂中看出其他的可能與變化。“代碼感”幫助程序員選出最好的方案，並指導程序員制訂修改行動計劃，按圖索驥。

簡言之，編寫整潔代碼的程序員就像是藝術家，他能用一系列變換把一塊白板變作由優雅代碼構成的系統.

5 什麼是整潔代碼

有多少程序員，就有多少定義。所以我只詢問了一些非常知名且經驗豐富的程序員。

​Bjarne Stroustrup，C++語言發明者，C++ Programming Language（中譯版《C++程序設計語言》）一書作者。

我喜歡優雅和高效的代碼。代碼邏輯應當直截了當，叫缺陷難以隱藏；儘量減少依賴關係，使之便於維護；依據某種分層戰略完善錯誤處理代碼；性能調至最優，省得引誘別人做沒規矩的優化，搞出一堆混亂來。整潔的代碼只做好一件事。

Bjarne用了“優雅”一詞。說得好！我MacBook上的詞典提供瞭如下定義：外表或舉止上令人愉悅的優美和雅觀；令人愉悅的精緻和簡單。注意對“愉悅”一詞的強調。Bjarne顯然認為整潔的代碼讀起來令人愉悅。讀這種代碼，就像見到手工精美的音樂盒或者設計精良的汽車一般，讓你會心一笑。

Bjarne也提到效率——而且兩次提及。這話出自C++發明者之口，或許並不出奇；不過我認為並非是在單純追求速度。被浪費掉的運算週期並不雅觀，並不令人愉悅。留意Bjarne怎麼描述那種不雅觀的結果。他用了“引誘”這個詞。誠哉斯言。糟糕的代碼引發混亂！別人修改糟糕的代碼時，往往會越改越爛。

務實的Dave Thomas和Andy Hunt從另一角度闡述了這種情況。他們提到破窗理論[5]。窗戶破損了的建築讓人覺得似乎無人照管。於是別人也再不關心。他們放任窗戶繼續破損。最終自己也參加破壞活動，在外牆上塗鴉，任垃圾堆積。一扇破損的窗戶開闢了大廈走向傾頹的道路。

Bjarne也提到完善錯誤處理代碼。往深處說就是在細節上花心思。敷衍了事的錯誤處理代碼只是程序員忽視細節的一種表現。此外還有內存洩漏，還有競態條件代碼。還有前後不一致的命名方式。結果就是凸現出整潔代碼對細節的重視。

Bjarne以“整潔的代碼只做好一件事”結束論斷。毋庸置疑，軟件設計的許多原則最終都會歸結為這句警語。有那麼多人發表過類似的言論。糟糕的代碼想做太多事，它意圖混亂、目的含混。整潔的代碼力求集中。每個函數、每個類和每個模塊都全神貫注於一事，完全不受四周細節的干擾和汙染。

​Grady Booch，Object Oriented Analysis and Design with Applications（中譯版《面向對象分析與設計》）一書作者

整潔的代碼簡單直接。整潔的代碼如同優美的散文。整潔的代碼從不隱藏設計者的意圖，充滿了乾淨利落的抽象和直截了當的控制語句。

Grady的觀點與Bjarne的觀點有類似之處，但他從可讀性的角度來定義。我特別喜歡“整潔的代碼如同優美的散文”這種看法。想想你讀過的某本好書。回憶一下，那些文字是如何在腦中形成影像！就像是看了場電影，對吧？還不止！你還看到那些人物，聽到那些聲音，體驗到那些喜怒哀樂。

閱讀整潔的代碼和閱讀Lord of the Rings（中譯版《指環王》）自然不同。不過，仍有可類比之處。如同一本好的小說般，整潔的代碼應當明確地展現出要解決問題的張力。它應當將這種張力推至高潮，以某種顯而易見的方案解決問題和張力，使讀者發出“啊哈！本當如此！”的感嘆。

竊以為Grady所謂“乾淨利落的抽象”（crisp abstraction），乃是絕妙的矛盾修辭法。畢竟crisp幾乎就是“具體”（concrete）的同義詞。我MacBook上的詞典這樣定義crisp一詞：

​“老大”Dave Thomas，OTI公司創始人，Eclipse戰略教父。

整潔的代碼應可由作者之外的開發者閱讀和增補。它應當有單元測試和驗收測試。它使用有意義的命名。它只提供一種而非多種做一件事的途徑。它只有儘量少的依賴關係，而且要明確地定義和提供清晰、儘量少的API。代碼應通過其字面表達含義，因為不同的語言導致並非所有必需信息均可通過代碼自身清晰表達。

Dave老大在可讀性上和Grady持相同觀點，但有一個重要的不同之處。Dave斷言，整潔的代碼便於其他人加以增補。這看似顯而易見，但亦不可過分強調。畢竟易讀的代碼和易修改的代碼之間還是有區別的。

Dave將整潔繫於測試之上！要在十年之前，這會讓人大跌眼鏡。但測試驅動開發（Test Driven Development）已在行業中造成了深遠影響，成為基礎規程之一。Dave說得對。沒有測試的代碼不乾淨。不管它有多優雅，不管有多可讀、多易理解，微乎測試，其不潔亦可知也。

Dave兩次提及“儘量少”。顯然，他推崇小塊的代碼。實際上，從有軟件起人們就在反覆強調這一點。越小越好。

Dave也提到，代碼應在字面上表達其含義。這一觀點源自Knuth的“字面編程”（literate programming）[6]。結論就是應當用人類可讀的方式來寫代碼。

​Michael Feathers，Working Effectively with Legacy Code（中譯版《修改代碼的藝術》）一書作者。

我可以列出我留意到的整潔代碼的所有特點，但其中有一條是根本性的。整潔的代碼總是看起來像是某位特別在意它的人寫的。幾乎沒有改進的餘地。代碼作者什麼都想到了，如果你企圖改進它，總會回到原點，讚歎某人留給你的代碼——全心投入的某人留下的代碼。

一言以蔽之：在意。這就是本書的題旨所在。或許該加個副標題，如何在意代碼。

Michael一針見血。整潔代碼就是作者著力照料的代碼。有人曾花時間讓它保持簡單有序。他們適當地關注到了細節。他們在意過。

Ron Jeffries，Extreme Programming Installed（中譯版《極限編程實施》）以及Extreme Programming Adventures in C#（中譯版《C#極限編程探險》）作者。

Ron初入行就在戰略空軍司令部（Strategic Air Command）編寫Fortran程序，此後幾乎在每種機器上編寫過每種語言的代碼。他的言論值得咀嚼。

近年來，我開始研究貝克的簡單代碼規則，差不多也都琢磨透了。簡單代碼，依其重要順序：

能通過所有測試；

沒有重複代碼；

體現系統中的全部設計理念；

包括儘量少的實體，比如類、方法、函數等。

在以上諸項中，我最在意代碼重複。如果同一段代碼反覆出現，就表示某種想法未在代碼中得到良好的體現。我盡力去找出到底那是什麼，然後再盡力更清晰地表達出來。

在我看來，有意義的命名是體現表達力的一種方式，我往往會修改好幾次才會定下名字來。藉助Eclipse這樣的現代編碼工具，重命名代價極低，所以我無所顧忌。然而，表達力還不只體現在命名上。我也會檢查對象或方法是否想做的事太多。如果對象功能太多，最好是切分為兩個或多個對象。如果方法功能太多，我總是使用抽取手段（Extract Method）重構之，從而得到一個能較為清晰地說明自身功能的方法，以及另外數個說明如何實現這些功能的方法。

消除重複和提高表達力讓我在整潔代碼方面獲益良多，只要銘記這兩點，改進髒代碼時就會大有不同。不過，我時常關注的另一規則就不太好解釋了。

這麼多年下來，我發現所有程序都由極為相似的元素構成。例如“在集合中查找某物”。不管是僱員記錄數據庫還是名-值對哈希表，或者某類條目的數組，我們都會發現自己想要從集合中找到某一特定條目。一旦出現這種情況，我通常會把實現手段封裝到更抽象的方法或類中。這樣做好處多多。

可以先用某種簡單的手段，比如哈希表來實現這一功能，由於對搜索功能的引用指向了我那個小小的抽象，就能隨需應變，修改實現手段。這樣就既能快速前進，又能為未來的修改預留餘地。

另外，該集合抽象常常提醒我留意“真正”在發生的事，避免隨意實現集合行為，因為我真正需要的不過是某種簡單的查找手段。

減少重複代碼，提高表達力，提早構建簡單抽象。這就是我寫整潔代碼的方法。

Ron以寥寥數段文字概括了本書的全部內容。不要重複代碼，只做一件事，表達力，小規模抽象。該有的都有了。

Ward Cunningham，Wiki發明者，eXtreme Programming（極限編程）的創始人之一，Smalltalk語言和麵向對象的思想領袖。所有在意代碼者的教父。

如果每個例程都讓你感到深合己意，那就是整潔代碼。如果代碼讓編程語言看起來像是專為解決那個問題而存在，就可以稱之為漂亮的代碼。

這種說法很Ward。它教你聽了之後就點頭，然後繼續聽下去。如此在理，如此淺顯，絕不故作高深。你大概以為此言深合己意吧。再走近點看看。

“……深合己意”。你最近一次看到深合己意的模塊是什麼時候？模塊多半都繁複難解吧？難道沒有觸犯規則嗎？你不是也曾掙扎著想抓住些從整個系統中散落而出的線索，編織進你在讀的那個模塊嗎？你最近一次讀到某段代碼、並且如同對Ward的說法點頭一般對這段代碼點頭，是什麼時候的事了？

Ward期望你不會為整潔代碼所震驚。你無需花太多力氣。那代碼就是深合你意。它明確、簡單、有力。每個模塊都為下一個模塊做好準備。每個模塊都告訴你下一個模塊會是怎樣的。整潔的程序好到你根本不會注意到它。設計者把它做得像一切其他設計般簡單。

那Ward有關“美”的說法又如何呢？我們都曾面臨語言不是為要解決的問題所設計的困境。但Ward的說法又把球踢回我們這邊。他說，漂亮的代碼讓編程語言像是專為解決那個問題而存在！所以，讓語言變得簡單的責任就在我們身上了！當心，語言是冥頑不化的！是程序員讓語言顯得簡單。

​

我（鮑勃大叔）又是怎麼想的呢？在我眼中整潔代碼是什麼樣的？本書將以詳細到嚇死人的程度告訴你，我和我的同道對整潔代碼的看法。我們會告訴你關於整潔變量名的想法，關於整潔函數的想法，關於整潔類的想法，如此等等。我們視這些觀點為當然，且不為其逆耳而致歉。對我們而言，在職業生涯的這個階段，這些觀點確屬當然，也是我們整潔代碼派的圭旨。

武術家從不認同所謂最好的武術，也不認同所謂絕招。武術大師們常常創建自己的流派，聚徒而授。因此我們才看到格雷西家族在巴西開創並傳授的格雷西柔術（Gracie Jiu Jistu），看到奧山龍峰（Okuyama Ryuho）在東京開創並傳授的八光流柔術（Hakkoryu Jiu Jistu），看到李小龍（Bruce Lee）在美國開創並傳授的截拳道（Jeet Kune Do）。

弟子們沉浸於創始人的授業。他們全心師從某位師傅，排斥其他師傅。弟子有所成就後，可以轉投另一位師傅，擴展自己的知識與技能。有些弟子最終百鍊成鋼，創出新招數，開宗立派。

任何門派都並非絕對正確。不過，身處某一門派時，我們總以其所傳之技為善。歸根結底，練習八光流柔術或截拳道，自有其善法，但這並不能否定其他門派所授之法。

可以把本書看作是對象導師（Object Mentor）[7]整潔代碼派的說明。裡面要傳授的就是我們勤操己藝的方法。如果你遵從這些教誨，你就會如我們一般樂受其益，你將學會如何編寫整潔而專業的代碼。但無論如何也別錯以為我們是“正確的”。其他門派和師傅和我們一樣專業。你有必要也向他們學習。

實際上，書中很多建議都存在爭議。或許你並不完全同意這些建議。你可能會強烈反對其中一些建議。這樣挺好的。我們不能要求做最終權威。另外一方面，書中列出的建議，乃是我們長久苦思、從數十年的從業經驗和無數嘗試與錯誤中得來。無論你同意與否，如果你沒看到或是不尊敬我們的觀點，就真該自己害臊。

小結

藝術書並不保證你讀過之後能成為藝術家，只能告訴你其他藝術家用過的工具、技術和思維過程。本書同樣也不擔保讓你成為好程序員。它不擔保能給你“代碼感”。它所能做的，只是展示好程序員的思維過程，還有他們使用的技巧、技術和工具。

和藝術書一樣，本書也充滿了細節。代碼會很多。你會看到好代碼，也會看到糟糕的代碼。你會看到糟糕的代碼如何轉化為好代碼。你會看到啟發、規條和技巧的列表。你會看到一個又一個例子。但最終結果取決於你自己。

還記得那個關於小提琴家在去表演的路上迷路的老笑話嗎？他在街角攔住一位長者，問他怎麼才能去卡耐基音樂廳（Carnegie Hall）。長者看了看小提琴家，又看了看他手中的琴，說道：“你還得練，孩子，還得練！

《代碼整潔之道》

馬丁 著

軟件質量，不但依賴於架構及項目管理，而且與代碼質量緊密相關。這一點，無論是敏捷開發流派還是傳統開發流派，都不得不承認。《代碼整潔之道》提出一種觀念：代碼質量與其整潔度成正比。乾淨的代碼，既在質量上較為可靠，也為後期維護、升級奠定了良好基礎。作為編程領域的佼佼者，《代碼整潔之道》作者給出了一系列行之有效的整潔代碼操作實踐。這些實踐在《代碼整潔之道》中體現為一條條規則(或稱“啟示”)，並輔以來自現實項目的正、反兩面的範例。只要遵循這些規則，就能編寫出乾淨的代碼，從而有效提升代碼質量。

《代碼整潔之道》閱讀對象為一切有志於改善代碼質量的程序員及技術經理。書中介紹的規則均來自作者多年的實踐經驗，涵蓋從命名到重構的多個編程方面，雖為一“家”之言，然誠有可資借鑑的價值。

《今日互動》

你期待從書中看到什麼？為什麼？截止時間7月27日17時，留言+轉發本活動到朋友圈，小編將抽獎選出2名讀者贈送紙書2本，文末留言點贊最多的自動獲得圖書1本。（參與活動直達微信端https://mp.weixin.qq.com/s/MDitibYbNOBPA28WbLQRLQ）

在“異步圖書”後臺回覆“關注”，即可免費獲得2000門在線視頻課程

點擊https://www.epubit.com/book/detail/18222，購買圖書《代碼整潔之道》

閱讀更多 異步社區 的文章

關鍵字: 市場營銷 藝術 程序員