“我們就是一群程式碼猴子，上躥下跳，自以為領略了程式設計的真諦。可惜當我們抓著幾個酸桃子，得意洋洋坐到樹枝上，卻對自己造成的混亂熟視無睹。那堆“可以執行”的亂麻程式，就在我們的眼皮底下慢慢腐壞。”

——《程式碼整潔之道》作者 RobertC.Martin，於SD West 2007技術大會

一、系列文章前言

敲完上面這段文字的時候，心裡在想，一個剛踏入程式設計生涯的新人，要經歷多少的淬鍊，才能領略到Bob大叔所謂的程式設計的真諦。

有人說，這個過程會很漫長，大概至少是在讀完N本程式設計領域的經典著作，並經過大量的思考與實踐之後。

而寫這個系列的起因，正是因為最近閒暇時一直在閱讀一些之前一直想看的經典著作，並有將閱讀過程中一些思考和總結記錄下來。為了不枉費這些閱讀、思考與總結的過程，決定將這些零散的內容整理成文，沉澱下來。過些年後再回首，也許會覺得當時的一些思考，彌足珍貴。

這個系列的文章，不僅僅是讀書筆記，而是對一本書核心內容的全新演繹，內容解刨，與重組。希望自己的這些文字，能對各位想進一步瞭解這些經典著作的讀者們有所幫助。

二、《程式碼整潔之道》其書

《程式碼整潔之道》（《Clean Code》）是幾乎每一個對程式設計境界有追求、有志於改善程式碼質量的程式設計者，都應該閱讀的一本好書。

這本書提出了一個觀點：程式碼質量與其整潔度成正比，乾淨的程式碼，既在質量上可靠，也為後期維護、升級奠定了良好基礎。

書中介紹的規則均來自作者多年的實踐經驗，涵蓋從命名到重構的多個程式設計方面，雖為一“家”之言，然誠有可資借鑑的價值。

 

三、本文涉及知識點思維導圖

先放出這篇文章所涉及內容知識點的一張思維導圖，就開始正文。大家若是疲於閱讀文章正文，直接看這張圖，也是可以Get到本文的主要知識點的大概。

 

四、糟糕程式碼，是如何產生的

最初的問題來了，我們都不喜歡壞程式碼，為何壞程式碼還總會產生？

拋開程式設計者本身技藝的問題，答案也許是想要快點完成任務，專案進度趕著時間，或許我們只是不耐煩再繼續做這個需求，渴望它能早點結束。

很多時候，會有一堆事情壓著你去完成，你覺得自己需要趕緊弄完手上的東西，好接著做下一件工作，所以，為了走捷徑，為了特定實現功能而強加的糟糕的程式碼，就悄悄地誕生了。我們都曾經瞟一眼自己親手造成的混亂，決定棄之不顧，走向新的一天，等有朝一日再來清理。

然而中國古訓有云，“明日復明日，明日何其多”，勒布朗（LeBlanc）法則也表示，“稍後等於永不。”你會發現，因為各種各樣的原因，很多時候你根本都不會（沒時間）去整理之前的程式碼。所以，正如本書作者Robert C.Martin（Uncle Bob），在SD West 2007技術大會上所說的，“那堆“可以執行”的亂麻程式，就在我們的眼皮底下慢慢腐壞。”

我們知道，壞程式碼會汙染環境，最後會壞掉整個專案。保持整潔的習慣，發現髒程式碼就要及時糾正。花時間保持程式碼程式碼整潔，不但有關效率，還有關專案的生存。

五、為什麼好程式碼會很快變質？

為什麼好程式碼會很快變質？一般情況下，需求一直在變更、需求變化違背了初期設計、進度太緊是導致好程式碼變質的誘因。

多數的產品經理想要好的程式碼，即便他們總是痴纏於進度，他們會奮力的維護進度和需求。而程式設計師們則當以同等的熱情捍衛程式碼的整潔性和可擴充套件性。

舉個栗子，如果你是醫生，病人在請求給給他們做手術前別洗手，因為那會花太多時間，你會照辦嗎？本該是病人說了算，但醫生卻絕對應該拒絕遵從。為什麼？因為醫生比病人更瞭解疾病個感染的風險。醫生如果按病人說的辦，就是一種不專業的態度。

同理，程式設計師遵從不瞭解混亂程式碼風險的產品經理（策劃）的意願，都是不專業的做法。

六、程式設計師的基礎價值謎題

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

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

七、大師們眼中的整潔程式碼

到底什麼是整潔的程式碼？有多少程式設計師，就有多少定義。 “大師級程式設計師把系統當故事來講，而不是當做程式來寫”。就讓我們一起看看經驗豐富的大師級程式們都是如何定義整潔程式碼的。

Bjarne Stroustrup ,C++語言之父， The C++ Programming Language（中譯版《C++程式設計語言》）一書作者：

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

Grady Booch,Object Orient Analysis and Design with Application(中譯版《面向物件程式分析與設計》) 一書作者：

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

Michael Feathers,Working Effectively withLegacy programming(中譯版《修改程式碼的藝術》)一書的作者：

“整潔的程式碼總是看起來想是某位特別在意它的人寫的，幾乎沒有改進的餘地，程式碼作者署名都想到了，如果你企圖改進它，總會回到原點，讚歎某人留給你的程式碼——全心投入到某人留下的程式碼。”

Ron Jeffries,Extreme Programming Installed（中譯版《極限程式設計實施》）以及Extreme Programming Adventures in （C#中譯版《C#極限程式設計探險》）作者：

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

八、編寫程式碼的難度，取決於周邊程式碼的閱讀難度

編寫程式碼的難度，取決於周邊程式碼的閱讀難度。何出此言？因為各種實踐與統計表明，在專案裡開發新功能的過程中，閱讀之前程式碼與書寫新的程式碼，花費的時間比例超過10:1，新寫程式碼時，我們一直在讀舊程式碼。既然比例如此之高，我們就應該讓讀的過程變得輕鬆，即便那會使得編寫過程更難。

所以說，編寫程式碼的難度，取決於周邊程式碼的閱讀難度，想要快速實現需求，想要快速完成任務，想要輕鬆的寫程式碼，先讓你書寫的程式碼整潔易讀吧。

九、讓程式碼比你來時更乾淨

我們知道，光把程式碼寫好可不夠，必須時時保持程式碼整潔，我們都見過程式碼隨著時間的流逝而腐壞。我們應該更積極地阻止腐壞的發生。

借用美國童子軍的一條簡單的軍規，應用到我們的專業領域：

“讓營地比你來時更乾淨。”

那麼可以同樣對程式設計領域這樣說：

“讓程式碼比你來時更乾淨。”

也就是說，如果我們每次簽入時，程式碼都比簽出時乾淨，那麼程式碼就不會腐壞。這就是我們需要遵從的程式碼整潔之道。

十、本文涉及知識點提煉整理

文章開頭部分已經用思維導圖的方式展現了本文的知識點，這邊再貼出一個文字列表版，方便大家整理：

1.編寫程式碼的難度，取決於周邊程式碼的閱讀難度。想要快速實現需求，想要快速完成任務，想要輕鬆的寫程式碼，請先讓你書寫的程式碼整潔易讀。

2.保持整潔的習慣，發現髒程式碼就要及時糾正。花時間保持程式碼程式碼整潔，這不但有關效率，還有關專案的生存。

3.程式設計師遵從不瞭解混亂風險的產品經理(策劃)的意願，都是不專業的做法。

4. 讓程式碼比你來時更乾淨：如果每次簽入時，程式碼都比簽出時乾淨，那麼程式碼就不會腐壞。

5.趕上期限的唯一方法，做得更快的唯一方法，就是始終儘可能保持程式碼的整潔。

本文就此結束。

下篇文章，我們將繼續《程式碼整潔之道》的精讀與演繹，探討更多的內容。

With Best Wishes.