1. Clean Code起源
談起Clean Code，大多數的程序員都不陌生，有時我們會將Clean Code也稱之爲代碼整潔之道。
Clean Code的思源源於軟件工程領域的大師級人物 - 羅伯特·馬丁(Robert C. Martin)所著的一本重量級經典圖書《Clean Code》，他在書中提出一種觀念：
代碼質量與其整潔度成正比
乾淨的代碼，既在質量上較爲可靠，也爲後期維護、升級奠定了良好的基礎。
爲了更好地理解這一思想，讓我們來先看這樣一個研究：
寫代碼的時間（Writing） VS. 讀代碼的時間(Reading) ？
大家可以回顧一下，在日常編寫代碼的過程中，有多少時間是花費在寫代碼上？有多少時間是花費在讀已有的代碼上的？
其實這樣一個研究並不難，通過一些編輯器的記錄功能，可以很好地分析程序員的整個開發過程。
這個過程往往是這個樣子的 -
你經常先會寫若干行代碼，然而不一會，你又會刪除它們；接下來你會滑動鼠標滾輪，研究一會代碼的上下文，然後重新寫下幾行代碼；在編寫的過程中，有時又會突然想到，編寫的這段代碼可能又會被sub-class中的方法重寫而被覆蓋掉，因爲你不得不悻悻地刪除剛剛編寫的代碼。。。
相信在編碼過程中，類似的場景任何一個程序員都不會陌生，我們總是會在不斷地寫代碼，同時又會不斷地使用delete鍵刪除剛剛寫好的代碼。
研究表明，程序員花費在讀代碼上的時間通常要10倍於真正編寫代碼上的時間，也即Writing vs. Reading的比例大概是1:10。
因此可見，如若想持續保證開發團隊的效率，那麼確保程序代碼一以貫之的整潔，乾淨，易讀，易維護是非常重要的。
2. 什麼是Clean Code
在談Clean Code的一般原則之前，讓我們看看大神們是如何理解這一概念的：
- “Clean code does one thing well.” --- Bjarne Stroustrup （Inventor of C++）
- “Clean code is simple and direct. Clean code reads like well-written prose.” --- Grady Booch （Pioneer of OO and UML）
- “Clean code can be read, and enhanced by a developer other than its original author.” --- Dave Thomas （Godfather of the Eclipse Strategy）
- “Clean code always looks like it was written by someone who cares.” --- Michael Feathers（Author of “Working effectively with legacy code”）
從上面的描述中，不難看出大家對Clean Code這一思想的喜愛，如果稍微文藝點，我們可以說“Clean Code就是心懷愛意地去編程”，讓你的程序單純、簡單、美好，當他人讀你的程序時，能感覺到“你對這個世界的善意”。
3. Clean Code的一般性原則
Clean Code是一種編程思想，涵蓋了很多的方面，本文提取了一些通用的原則供各位參考。
3.1 命名
變量命名：變量名要能揭示變量的功能和含義。
類名和方法名：類名通常要是名詞，方法名使用動詞，屬性名使用名詞。
避免含糊不清的命名：例如Company，CompanyData, CompanyInfo，類似的命名讓人無法從名稱上明白變量間的差別與含義。
避免含義不清的詞彙：例如utility，processer, helper，這樣的詞所描述的方法或class往往會變成一個雜貨鋪。
對於某一概念，選取一個特定的詞：例如對於讀取這一個概念，我們統一口徑使用GET，例如get_name(), get_production_date()；而不要變成千人千面，例如get_name(), fetch_production_date()，read_customer()。
名字要是可讀的：不要使用那些奇奇怪怪的縮寫詞，例如get_khzsu( )這樣的命名會讓讀你代碼的人不斷內心WTK...
使用常量，不要留下魔法數字/字符：魔法數字和字符會讓讀你程序的人崩潰的。。。
通用的命名規範：無論是使用Java, JS, C++, C# etc，在你的團隊中一定要有明確的命格規範，並嚴格遵守。
3.2 註釋
如果可以用命名來表明含義，則不要用註釋；
如果可以用清晰的代碼邏輯來表明含義，則無需冗餘的註釋；
使用Git等工具進行版本管理的標明，而非在程序中通過註釋來區分版本；
註釋要是清晰明確的，不要寫含糊不清的註釋；
不要用註釋區分段落，如果你的代碼過長，考慮進行進一步的封裝；
如果你的代碼無法做到自我解釋，那麼留下一個註釋，則會是一個明智的選擇。
3.3 函數
一個函數/方法只做一件事
函數的參數要儘可能地少
函數體不要過長
函數邏輯不要有多層的循環
函數邏輯要避免多層的分支嵌套
使用異常，避免使用error Codes作爲返回參數
3.4 檢查
對代碼做靜態語法檢查
每一段代碼都要有對應的單元測試代碼
團隊內部的pair programming
release前，做代碼review
4 小結
Clean Code是一種編程的思想和習慣，慢慢改變free style的編程風格，讓你的code變得對着世界充滿善意，這也將會是一個不斷學習積累、不斷規範的過程，對於個人而言，它會讓你變得更加“專業”且富有“工匠精神”；對團隊而言，形成Clean Code的氛圍和規範能很好地保證產品質量，並極大提升團隊的運行效率。
Clean Code是一個“不積跬步無以至千里”的過程。每天都變得規範一點點，做增量的積累，量變就會引發質變。
