需求的不斷變更是重構的最根本原因，代碼架構最初的設計也是經過精心的設計，具有良好架構的。但是随着時間的推移、需求的劇增，必須不斷的修改原有的功能、追加新的功能，還免不了有一些缺陷需要修改。為了實作變更，不可避免的要違反最初的設計構架。經過一段時間以後，bug越來越多，越來越難維護，新的需求越來越難實作，最初的代碼構架對新的需求漸漸的失去支援能力，而是成為一種制約（新需求的開發成本會超過開發一個新的軟體的成本）。說白了，不管是devops還是靈活開發，永遠強調的是快速響應（産出）！隻有好的設計及代碼才能做到快速響應！
1. 既然重構那麼重要，那究竟什麼是重構呢？
重構就是通過調整程式代碼，但并不改變程式的功能特征，達到改善軟體的品質、性能，使程式的設計模式和架構更趨合理，更容易被了解，提高軟體的擴充性和維護性。
2. 重構的目标值？
- 持續偏糾和改進軟體設計
- 使代碼更被其他人所了解
- 幫助發現隐藏的代碼缺陷
- 從長遠來看，有助于提高程式設計效率，增加項目進度（進度是品質的敵人，品質是進度的朋友）
3. 怎樣去重構？
代碼重構的方法論，這裡不做論述，有一本《重構改變既有代碼的設計》非常值得一讀。
4. 重構的困境，內建化測試誰來做？
重構依賴測試，依賴自動化，內建化測試。Test-Driven Development(TDD)，是Extreme Programming (XP)--極限程式設計的一個重要組成部分。那問題來了，誰來做，怎麼做？
我的結論是開發人員來做，由開發人員編寫測試帶來的收益，最重要的一點不在于測試本身，而在于它能促進開發、測試以及需求分析人員的交流與溝通。而測試先行的方式也能讓開發者跳出實作的窠臼，而從業務角度去看待問題，從消費者角度去思考接口的設計。
5. 內建化單元測試怎麼做？
說實話，要做到極緻（在jenkins中點釋出時代碼規範、單元測試、內建化測試等各項名額達标釋出成功，釋出失敗把這些項郵件給負責人）。就但內建化測試還真有點複雜，這裡分享一個我之前的一個思路
這裡分享一個我之前寫的mock-plugin-maven ，這裡再拓展一下，要實作內建化測試，其實BDD（行為驅動開發）是個不錯的方案。