“我們就是一羣代碼猴子，上躥下跳，自以爲領略了編程的真諦。可惜當我們抓着幾個酸桃子，得意洋洋坐到樹枝上，卻對自己造成的混亂熟視無睹。那堆“可以運行”的亂麻程序，就在我們的眼皮底下慢慢腐壞。”
——《代碼整潔之道》作者 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. 趕上期限的唯一方法，做得更快的唯一方法，就是始終儘可能保持代碼的整潔。
本文就此結束。
下篇文章，我們將繼續《代碼整潔之道》的精讀與演繹，探討更多的內容。
Best Wish~
