前兩天參加了公司組織的一個培訓，主題是“如何寫出好的代碼” ，剛看到這個主題，第一反應是又不知道是哪個培訓機構來忽悠錢的！老大安排了，就去聽聽唄。
說實在的，課程內容沒有什么新鮮的東西，就是講講如何發現代碼的壞味道，如何重構函數，如何修改遺留系統的代碼。這些東西從本科到研究生到實習到正式工作，也不知道看過多少聽過多少了，話說本科的課程設計也和代碼重構相關，私底下重構和設計模式方面的書也沒少看，感覺應該沒啥好培訓的，不過兩天的課程聽完，打心眼里覺得來對了，意猶未盡！
課程結束了，感覺需要把這兩天課程的內容回顧總結一下，加深一下印象。
關於代碼質量。這是一個永遠縈繞在程序員心頭的問題，特別是在敏捷團隊，code quality更是一個時常聽到的詞語，靜態掃描，單元測試，持續集成平台上永遠少不了這些東西，感覺有了這些工具，能看到一些報告，就對代碼質量有交代了。其實呢，發現實際根本不是那么回事，規則流程有了，工具平台有了，代碼質量並沒有提高，反而，因為維護UT占了大量的時間，代碼寫的更隨意，更不規范了。培訓老師說了一句話挺對的“代碼重構是個良心活”，一段代碼很爛，不重構能work，重構好了，沒人知道，重構出了問題，反而會引來各種抱怨，誰去干這吃力不討好的事兒，系統中沒用的老代碼都不想刪，何況去動正在運行着的代碼呢。所以說，要想提搞代碼質量，靠程序員的良心是不太行得通的，特別是交付壓力很大的情況下，就是有這個良心也只能昧着良心check in了。那怎么辦，要靠manager，只有manager關注這塊兒，才真的能觸動代碼質量的提升，不求manager去review代碼，manager哪怕是盯一下靜態掃描工具產生的報告，稍微找負責人談談話，代碼質量就能上去，敏捷搞得manager們只看User Story完成的情況，只看能不能持續交付產品了，選擇性忽略了代碼質量。當然了，程序員也不是一點責任都沒有，程序員寫clean code是職業素養，是一種習慣，很多時候，我們從剛開始就沒有能夠養成這種良好的習慣，現在要改變也很困難，所以程序員要培養編程價值觀，要改變對寫代碼的認識，養成好的習慣。
再說說敏捷開發，這個不知道從什么時候從外企傳到私企，從大企業傳到初創公司改變傳統軟件工程的模式，我覺得真心是雞肋，至少在中國的公司中是不能充分發揮它的價值的。敏捷開發作為一種為迎合當今快速變化的市場的開發模式，面向的是市場，而軟件工程是有工程過程規律的，既然是一項工程，就要按部就班的搞，就得有規划，就設計，有實現，有驗收，還要有工匠精神，對細節的打磨，一個環節也不能少，不會因為用了敏捷，就能神奇的縮短時間，歷史證明，多快好省是不可能的，偷工減料，還能又多又好么！那為啥外國公司要搞敏捷呢，依我看，是因為外國公司和咱國內情況不一樣，美國公司啥個情況，就拿我們公司總部，在硅谷，據B1回來的同事說那兒的工作狀態：每周最多上四天班，周一下午才來，周五下午不見了，四天里怎么工作呢，上午咖啡下午茶，吃完午飯打個盹，把大部分臟活累活外包到中國印度，自己留着核心的慢慢磨，或者做做創新。這個狀態下，敏捷起來確實能提高效率，因為有大把的時間可以擠出來。而國內的，本來就處在滿負荷運轉了，再搞敏捷，需求不斷改，UT，TA各個sprint都要跟上，還有功夫去關注代碼質量么？中央為什么要提中國特色，情況不一樣，發展階段不一樣，生拉硬套別人的不好使。
扯遠了，拉回來。
關於代碼的壞味道。什么是好的代碼？沒人說得清楚，但我們能指出什么是壞的代碼，《重構---改善既有代碼的設計》這本書開始講的就是這個，比培訓課程里講得更好更全。只要沒有壞味道的代碼，就是好的代碼，問題是如何聞出代碼中的壞味道，有一些量化的規定，比如，函數長度不能超過50行，參數不能超過7個，嵌套不能多於3層，圈復雜度不能大於10，不能出現重復的代碼等。有了這些明確的標准，只要會數數，就一定能發現代碼中的壞味道。當然了，數學再好也未必就能數的出壞味道，還得有節操。
關於高質量函數。到底為什么要寫函數？封裝變化，單一職責，隱藏細節，避免重復代碼，提高可移植性等，太多理由了，以至於程序員出於本能就會說“這個地方寫個函數處理一下”。當然了，本能是一個從刻意到隨意的過程，想寫出高質量的函數，剛開始也要刻意為之。創建函數三原則：單一抽象層次原則，單一職責原則，函數短小原則。
- 單一抽象層次原則：讓一個方法中的所有操作處於相同的抽象層。比如描述業務流程的public方法，可以羅列調用幾個私有的分步方法，只顯示流程大體步驟。這樣把程序划分成幾個處於同一層次的方法，自然的產生多個包含許多小方法的程序，每個方法只包含少量代碼了。
- 單一職責原則：函數應該做一件事情，做好這件事，只做這件事。這個原則更多的是針對助手函數，對於描述業務流程的頂層方法，很難做到一函數一件事情。有時候總是喜歡命名一些函數actionAndaction，其實就是懶得去抽開，當然也有為了省掉一個循環，在一個循環里做了兩件事情，對於循環，看數據集大小，如果分成兩個循環並不會太影響性能，抽成兩個函數，代碼會更清晰。
- 函數短小原則：函數越短，越不會出現嵌套過深，功能復雜等情況。
函數10個一：
- 每個變量只用於單一用途。
- 每一行代碼只表達一件事。
- 一個循環只做一件事。
- 每個函數語句應該遵守單一抽象層次原則。
- 代碼組織的一次只做一件事情。
- 一種變化導致的修改應該僅僅修改一處。
- 圈復雜度小於一十。
- 函數第一原則短小。
- 單一職責。
- 寫代碼時要有一顆謙卑的心
關於修改系統遺留的代碼。這是個頭疼的問題，特別是大公司的程序員，很多人剛入職就是從維護老代碼開始，原代碼的作者早就離職了，有文檔的不多，有用的注釋也不多，只能靠自己理解，而當需要改代碼的時候，就犯愁了，不敢動。很多時候，程序員就會選擇往老代碼里塞新代碼：加個判斷，多寫個分支，順着原來的代碼結構完成新的功能。可是這很容易把老代碼變的更糟，怎么保證不要讓老代碼變的更糟呢，要對老代碼進行隔離，可以采用新生方法，新生類，外包裝方法調用老代碼，外覆蓋類等方式，這些在《修改代碼的藝術》里講得很詳細。要時時提醒自己，拒絕軟件的退化。