1，什么是重構？
在不改變軟件可觀察行為的前提下，使用一些重構的手法，提高代碼可讀性。
換句話說，在保持軟件可用的前提下，修改代碼使得更加容易被理解。
2，為什么重構？
為了后續的代碼維護和修改，易讀是重構的核心價值。
除此之外，重構隨之帶來的好處有：
- 找到bug
- 提高編程速度（在代碼量累計到一定程度時，重構過的代碼會更加易於添加新功能）
3，什么時候重構？
-
添加新功能之前重構
添加新功能最快的方法往往是先修改現有代碼，使新功能容易被加入。
-
使代碼更易理解時重構
-
順便重構（修復bug，添加新功能）
-
代碼復審（code review）時重構
總而言之：重構的門檻遠遠沒有想象中那么高，重構是對既有代碼的修改，也許我們在無意識中就已經做了這樣的工作，一方面繼續保持良好的編程習慣，另一方面學習更加成體系的重構手法。
就如同重構的定義，在可用的前提下，提高重構的技術。
什么時候不應該重構？
對於一段凌亂的代碼，如果不需要修改它，就不需要重構。
只有當你需要理解其工作原理時，重構才變得有價值。
如果重寫比重構更加容易，那就不需要重構了。（判斷）
4，重構會遇到哪些問題？
“畢竟生活里很少有晴空萬里的好事”
——Martin Fowler
延緩新功能開發
先添加新功能再重構，還是先重構再添加新功能，這不是一個對錯的問題，而是一個取舍的分叉口。
Martin Fowler的回答醍醐灌頂，作為程序員往往對代碼庫的整潔有着極高的追求，以技術去驅動重構沒有錯，但現實世界往往取決於經濟。
“重構的意義不在於把代碼庫打磨的閃閃發光，而是純粹經濟角度出發的考量。”
“重構應該總是由經濟利益驅動。”
除了重構之外，現在的團隊開發，前后端分離等等，不僅是技術發展的必然結果，同時也是經濟化必然的結果。同樣的場景，是否重構更多取決於經濟條件。
代碼所有權成為重構阻力
修改函數聲明和調用可能也會遭遇聲明者無法修改調用者代碼的權限問題。
Martin Fowler推薦的是團隊代碼所有制。對於跨團隊的兼容，可以采用類似GitHub上開源的模型。
(在強代碼所有制和混亂修改的折中)
分支合並問題
在隔離的分支上工作的越久，需要完成的集成工作就越困難。
持續集成（CI：Continuous Integration）：也稱基於主干開發。為了避免彼此分支差異過大，每個團隊成員每天至少向主線集成一次。
使用CI的代價：必須使用相關的實踐保持主線的健康狀態。
快速的自測試
建立一套完備的測試套件，並且需要快速運行。
准備這套測試套件的代價很高，但收益也是可觀的：
- 使重構可行性變得更大
- 使添加新功能更加安全
- bug排查更加迅速，容易
遺留代碼
重構可以很好的理解遺留系統，但同時又是十分危險的。
再次推書了，hhh《修改代碼的藝術》：運用重構手法創造出接縫，在接縫處插入測試。（當然，具有一定風險）
數據庫
flower先生的同事發明了一套漸進式數據庫設計和數據庫重構的方法.......
（看書就好像布置家庭作業一樣。。。難頂）
5，重構與性能優化
重構：使代碼更易讀
性能優化：使代碼運行速度更快
先寫出可調優的軟件（重構），然后對其調優達到足夠的速度（性能優化）。
關於性能優化：現狀——大半時間都花在了一小段代碼上。
使用一個度量工具監控程序的運行，找出性能熱點的一小段代碼集中調優。
6，自動化重構
Intellij IDEA可以自動重構的......（說明我對這個工具的利用程度還不夠高）