我著重說一下程式碼重構，我建議將重構提前到編碼時就重構。當然編碼完成成後也需要重構，但那時重構就要顧慮更多了。

首寫，寫單元測試（ut），在第一個public函式完成時，就寫單元測試程式碼。這時單元測試可以推動你做如下重構，1 去除不必要的引用，如c/c++中的include 標頭檔案，因為寫ut要寫makefile檔案，多一個引用，會多複雜一分。2 去耦合，耦合太大沒法測試 3 功能分層，一個函式跨多個層沒法測試 4 重新思考函式定位，定位不好，不符合正交性的函式難以測試。

其次，程式碼自查，1 將大的函式拆分為小的函式，最好看看小函式是否可以操象成一個通用函式。2 注意名稱，看有沒有名實不符的。 3 將魔術資料用只讀變數，列舉，宏替換 4 關注一下函式，變數的可見範圍。能用private的，不要用protected. 5 注意可讀性。 看看有沒有表達不明確，明瞭的地方，如有些if條件中有多條判斷條件，看看能不能寫成一個函式。 6 繼承的類可否換成組合。

再次，在實現幾個功能後，回頭看看有沒有相同或相似的邏輯，若有，抽象出來。

注意，在程式碼完成後的重構一定要小心，前提是對程式碼非常瞭解，然後小步重構，每重構一步，驗證一下，沒問題，將程式碼簽入程式碼庫，再重構下一步。一定要保證修改的程式碼能回退回去。就因為這些問題，我比較喜歡編碼時重構。還有，經過測試人員測試又沒有自動化測試的支援，建議不要重構了。

看著大夥都寫的這麼複雜，我也忍不住來回答一下。

如何進行程式碼重構，其實是一個你自己知識儲存的問題。所以接下來我就告訴你，有哪些知識可以學習，來提升自己重構的能力。

其實所謂的重構，也就是形成良好的程式碼模式。而在軟體開發這個領域，早就已經形成很完備的知識體系。具體來講就是體系結構模式，設計模式和慣用法。教材請參見張友生編寫的《軟體體系結構原理、方法與實踐》。

當然這只是一本大學入門的教材，學了之後，還需要看一些更具有實踐性的書籍，推薦《程式碼之美》、《重構——改善既有程式碼的設計》。把這些知識都學會之後，重構程式碼，肯定不是問題。

重構是極其考驗功底的一件事，比能寫要求高很多。

就從程式碼行數10W+（不算一些口水行的）數量來說。

1.如果這個專案本來就是你帶的，最好是把重構工作做在無形當中，就是邊做邊重構，從大重構變成小重構，現在很多專案迭代週期很短，以周或是二週為週期在發版本，本質上也不允許你做大重構。

2.如果專案是別人留下來，你接著做的，你想做小重構，可能都有一定的困難，因為即有程式碼已經在了，這沒得選，建議做好幾件事

a.瞭解業務，你要知道這些程式碼是做啥事的。

b.找使用量最大的模組開始重構（當然使用量大的，但複雜度低的更好)

d.很強的分析能力，日誌能力，不要一上來就憑想的來重構，把邏輯畫清楚，用日誌來驗證是不是真有這些東西，不要放過細節，機器不會犯錯，人才會，一般有不太正常的日誌列印，就是有問題的跡象。

3.做好自動化測試機制，邊重構邊測。

4.對使用的語言有極致的理解，但儘可能使用最簡單最通用的部份，重構後要更清晰，很多重構，是基於語言特性來寫的。

首先得明確程式碼為何要進行重構，一切毫無目標的行為本身無法產生激勵，不能產生價值，那持續推進的動力就會大打折扣。

那麼，如果我們因為遺留系統的程式碼已經無法滿足現有的產品需求，亦或是遺留程式碼已經疏於維護，無法滿足最低的產品需求，這時的重構顯得刻不容緩了。

既然要重構，首先得了解遺留系統的架構模式，瞭解各個元件的介面，如何協調運作的。如果有詳盡的技術文件，當然幫忙不少；如果缺失的話，只能一方面透過諮詢老員工來了解遺留系統的情況，另一方面透過逆向工程等技術手段來還原系統框架。

下一步，在瞭解了系統架構模式，運作機理的情況下，進一步試執行各個use case，瞭解主要的功能特性，更需要了解遺留系統的缺陷和不足並一一記錄。

那麼我們在開始重構的時候，可以有兩條思路：一種屬於推倒重來，這種從0開始搭建的方式，時間和人力成本較高，但架構清晰，技術緊跟時代步伐，不用有太多對遺留系統的鼓勵；另一種方式屬於漸進式，在遺留系統的基礎上先進行修補，彌補現有缺陷和不足，對能夠重構的模組儘量進行松耦合的原子化拆分，避免產生過多依賴，這樣可以有一個新舊系統的平穩過渡。

建議對於不同專案，取樣不同的策略，兩手要抓，兩條腿走路。

正如Martin Flower在《重構》中有一句經典的話："任何一個傻瓜都能寫出計算機可以理解的程式，只有寫出人類容易理解的程式才是優秀的程式設計師。"，這也道出了重構的意義和價值。

最後，還推薦看看Bradley Irby寫的《Reengineering》,中文譯名《軟體再工程》，書中對架構、思想、重構的邏輯都進行了深入的闡述，可以從原理、方法論再到實際程式碼實現有個比較清晰的基礎認識。

重構本來就是一門實戰性技術，只有多參與專案中的程式碼重新設計，勤思考，多動手，才能真正掌握要點和價值點。