最近讀了關於重構的這本書，突然有個想法，code不是搬磚而是一種藝術，如何寫出有藝術感的程式碼？那就是去研究設計模式和重構。你可以學習很多技術像java的常見特性，框架的技術spring aop原理，但是我認為其實這些都是招式，只有設計模式和重構才是真正的內容，才真正讓你的code有了藝術感。所以要成為一個程式設計藝術家必須精通設計模式和重構。
重構原則：
1. 重構是啥？
不改變軟體功能，提供可讀性和降低修改成本
2. 為何需要重構，重構能產生哪些價值？
a) 重構改進軟體設計，重構就像是在整理程式碼，越難看出程式碼所代表的設計意圖，就越難保護其中設計，於是設計就消失的越快。經常性的重構可以讓程式碼維持該有的形態。
b) 重構使軟體更容易理解， 便於其他人和自己閱讀，便於理解原有程式碼的設計
c) 重構幫助找出bug
d) 重構提高程式設計速度，良好的設計才能做到快速開發。如果沒有良好的設計或許某一段時間你的進展迅速，但是惡劣的設計很快會讓你的速度慢下來。
3. 何時重構
a) 新增功能時重構 ，重構能讓你更好的理解自己和別人的程式碼也就越越方便的新增程式碼，如果程式碼的設計無法方便的讓我新增我的特性那麼需要重構。
b) 修補錯誤時重構，如果收到一份錯誤報告，這就是需要重構的訊號，因為顯然程式碼還不夠清晰，沒有清晰到讓你一眼看出bug。
c) 複審程式碼時重構，重構別人的程式碼可以得到最直觀的理解。
4. 怎麼對專案經理說
受進度驅動的經理需要我們儘快完成，至於怎麼完成，那就是我自己的事情，我認為最快的方式是重構，所以我就重構。
6. 重構與設計
仍然做預先設計，但是不必一定找出正確的解決方案。重構讓日後的修改成本不再高昂。
7. 重構與效能
開發時不對效能投以必要的關注，直至到效能優化階段，通常只需要改動一小段程式碼就可以極大的提高效能，因為90%的效能問題都在10%的程式碼邏輯處。
壞程式碼的味道
1. 重複程式碼 (Duplicated Code)
2. 過長的程式碼 (Long Method)
3. 過大的類 (Large Class)
4. 過長的引數列表 (Long Parameter List)
5. 發散式變化，一個類多個維度變化（Divergent Change)
6. 霰彈式修改，一個變化設計多個類（Shotgun Surgery)
7. 依戀情節，對別的類的興趣高過自己類（Feature Envy)
解決：把當前方法移動到另一個類中
8. 資料泥團，多個類的欄位同時出現，函式有相同的入參(Data Clumps) （如thirdpartOrderId 和source)
解決：為這些欄位建立一個新的物件
9. 基本型別偏執 喜歡基本型別多過物件 (Primitive Obsession)
10.Switch Statement
11.平行繼承，為一個類增加子類必須為另一個類增加子類（Parallel Inheritance Hierarchies)
12.冗餘類，當前沒有作用的類（Lazy Class)
13.誇誇其談未來性，過度事前設計（Speculative Generality）
過度抽象，很多抽象類和鉤子方法，可以在將來發現程式碼冗餘再做抽象。
14.物件的臨時變數，只為特殊情況而設（Temporary Field)
例項內的部分變數只為特殊情況存在，這樣會給人疑惑，建議重新定義一個新的物件儲存這些臨時變數。
15.過度耦合的訊息鏈，客戶端程式碼和查詢物件高耦合（Message Chains)
16.中間人，類大半的方法都委託給中間人（Middle Man)
17.狎暱關係，兩個類過度關注對方的private部分（Inapproriate Intimacy)
18.異曲同工的類(Alternative Classes With Different Interface)
19.不完美的類庫，為類庫增加新的行為（Incomplete Library Class)
20.純稚的資料類（Data Class)
21.被拒絕的遺贈，繼承無用的屬性和方法（Refused Bequest)
22. 過多的註釋，過多的註釋往往需要重構程式碼（Comments)
a) 過多的註釋往往說明程式碼很糟糕
b) 如果你不知道該做什麼，這才是註釋的良好運用時機
c) 此外，註釋還可以用來標記你並無十足把握的區域
自動化單元測試
a) 使用自動化測試工具 如junit
b) 每當收到bug報告，為自己新增新的單元測試
c) 測試最可能出錯的程式碼，不用面面俱到