這一系列的重構知識總結自馬丁福勒的《重構 改善既有**的設計》一書。
為什麼要重構？
因為乙個專案往往不只乙個人在寫，其他人也會來讀寫你的**，有些人甚至自己寫的**幾個月之後就看不懂當初自己寫的是什麼了。
重構的目的：
改進軟體的設計，使軟體更易理解，容易找出bug，在後期要新增新功能時，提高程式設計速度，重構後的**更易調優。
重構的時機：
一般在新增新功能前，如果不太好新增，則先重構在新增。
看**時，如果發現可以重構的地方也可以重構，
有時，重構是個比較繁雜的工作，那麼可以分多次重構，就是「營地至少要比自己來的時候更乾淨」
很多專案不會安排重構的時間，但是會安排**複審的時間，這也是乙個適合重構的時機。
重構的挑戰：
重構會拖慢專案進度？其實重構是乙個另專案先慢後快的過程，如果專案的**結構清晰，易於理解，那麼後面新增新功能或調優就會很快。
想重構卻沒許可權？專案最好在版本控制軟體上開源，大家一起寫。
每個人寫自己的一部分，如果你改了乙個介面，別人那可能會出錯？應用版本控制軟體，持續整合，一般每人每天都要提交一次，而且關於修改介面，後面的重構手法中詳細說明如何修改。
缺乏測試？寫自測試程式，現在的編輯器都很容易測試，如果是專案本身不好測試，就尋找"gap"，將專案分成多個易測試的程式，此外很多編輯器中都支援安全的自動化重構。
其他：
簡單設計：不要寫乙個 想當然的靈活的系統，而是先寫乙個易修改的簡單的系統來滿足將來的需求。
先寫出乙個可調優的程式，再調優，對於大專案，要使用度量工具。
重構的結伴流程是：審視-修改-測試-提交到branch-推送到master
NO1重構感想
經過了長達乙個月的編碼，終於完成了no1的重構開發，雖然還有一些隱含的邏輯上的一些問題。經過這次開發，讓我感觸頗多。首先，我們一定要善於學習。大家都知道學習的好處，但是在實踐中都得到這個結論和聽別人說完全是兩碼事情。舉個例子，假如說，我想要獲得乙個標籤的innerhtml屬性，以前我都是這麼寫的。a...
4 3 重構查詢方式
設計查詢的時候乙個需要考慮的重要問題是，是否需要將乙個複雜的查詢分成許多簡單的查詢。mysql內部每秒能夠掃瞄記憶體中上百萬行資料，相比之下，mysql響應資料給客戶端就慢的多了。所以，有時候將乙個大的查詢分解為多個小查詢是有必要的。4.3.1 切分查詢 乙個大查詢如果一次性執行的話，可能一次鎖住很...
《重構》 2 重構原則 讀書筆記
1 重構不只是整理 而是一種更搞笑且受控的 整理技術。2 但必須對軟體 可受觀察之外部行為 只造成很小變化，或甚至不造成變化。與之形成對比的是 效能優化 和重構一樣，效能優化通常不會改變元件的行為，只會改變其內部結構。但是兩者出發點不同 效能優化往往使 較難理解，但為了得到所需的效能你不得不那麼做。...