重構不完全指南！
首發公眾號《andyqian》,期待你的關注！
前言
程式設計師在職業生涯中，不可避免的就是接手老專案，重構歷史專案。事實證明，不論是老專案還是新專案都會遇到這種情況，不信你去看看一週前自己寫的程式碼，是不是有很大的改進空間？對於新入行的朋友們也要做好準備，以後也或多或少會面對這樣的情況。在面對這樣的情況時，不管你接手前是多麼不願意，接手後怎麼破口大罵，甚至有過無數次想放棄的念頭。但問題始終擺在那，始終需要面對。在最近一段時間裡，一直在進行專案重構方面的工作，專案不大，但在重構過程中，依然有一些感受，想借此機會分享出來。不過，現在去看看已經重構過的程式碼，依然有很大的改進空間。
在介紹重構方法之前，下面幾個原則是非常重要的，甚至在重構時都是需要時刻緊記。否則在重構過程中，一定會讓你十分痛苦，甚至會多幾次想放棄的念頭。
-
以最小單元為重構點。也就是說：不要一上來看這不順眼，看那也不順眼，改了一通，到最後專案都執行不起來。
-
對於重構後的方法，功能點，一定要驗證通過後再重構下一個。該寫的單元測試一個也不能少。
-
對外提供的介面，無論是Rest介面還是RPC介面，用冗餘的方式進行重構，意思是說：對已經對外提供的介面，在保證正確的前提下，內部怎麼重構都可以，但不要修改對外的資料結構。或者採用升級介面版本的形式，將老介面標記為過時，老介面與新介面並存執行的形式。
理清流程
之所以將其放至首位，因為我覺得這是在動程式碼之前最重要的步驟。理清楚這個服務的職責，主要流程，關鍵步驟，關鍵狀態的轉換是非常重要的。如果之前有設計文件描述了這些內容就再好不過了。我們只需要對照著設計文件先對系統有個巨集觀的印象，再對照著文件與程式碼進行一步步檢視一遍，這一遍並不需要很仔細，最主要是對涉及到的物件，資料流向有初步印象即可。如果沒有任何文件，或者文件已經和程式碼完全不匹配時，我們也只能硬著頭皮通過程式碼來還原文件了。這時我們可以先通過程式碼的執行流程，畫時序圖理清楚服務內部互動的方式，可以通過畫類圖理清楚類與類之間的關係，可以通過畫流程圖來理清楚資料的走向。讓比較具體的程式碼形式轉換為更抽象化的文件形式。首先我必須承認，這是一個非常痛苦的過程，但這算的上是一個有效的辦法。同時這也是我做的不夠的地方，接到任務後一心想著鑽進程式碼改這改那，卻忽視了這最重要的步驟。
找出壞味道
通過上一步，對我們需要重構的專案基本有了清晰的輪廓。到這一步，我們最主要的職責是找出事件入口並體驗。這裡指的事件是指暴露形式，如：Rest介面，RPC服務，定時任務等形式。我們只有體驗了流程，才能找出程式碼中的壞味道。如果對專案完全不熟悉或者一知半解的強烈推薦用debug的模式一步一步看看程式碼的執行過程，避免發生重構後造成服務不可用的慘案。這時如果遇到覺得需要重構的點，可以先記錄下來，直到debug完成後。這時記錄下來的點，就是你需要重構的地方。如果你發現，重構完這些點都足以重新寫了，那麼，剛才的那一遍debug對你理解流程以及注意事項是有幫助的。
剔除壞味道
完成前兩步後，我們都應該對流程，資料流向都非常熟悉了。現在來修改程式碼再合適不過，但在修改前，我依然建議大家用冗餘的方式進行修改。也就是說：此時我們還不要急著刪除原來的程式碼，建議重新起一個單獨新的內部方法，進行編寫，單元測試，在入口修改為重構後的方法，再進行整合測試，驗證，直至上線。重構程式碼線上驗證通過後，再刪除老程式碼也未嘗不可。我們在軟體開發時，崇尚“小步快跑，快速迭代”的迭代思維，同樣的，我建議重構也應該是這樣的，不建議修改了非常多或全部重構完成再進行驗證，這樣無論驗證時間還是驗證範圍都是不可接受的。
驗證
寫單元測試是一個神奇而無味的工作，神奇在於它能挖掘出很多低階，甚至想抽自己巴掌的錯誤，無味在於大家認為這是一項毫無技術難度的苦差事。殊不知在重構專案時，單元測試也發揮了及其重要的作用，我們可以通過單元測試來熟悉專案，熟悉流程，熟悉每一個方法，熟悉每個資料的走向。在重構完成後，我們也應該編寫單元測試進行驗證，在程式碼修改後，我們也應該對單元測試進行修改，進行驗證，保證程式碼與單元測試是一一對應且同步的。
當然，重構過程中，除了單元測試外，也需要自己進行功能性測試，更需要測試同學的功能測試，邊界測試，效能測試等等。總之，重構過程，是一個合作的過程。
最後
其實不論重構專案，還是入職新公司熟悉專案，都可以使用上面的方法進行實踐。通過上面這些步驟，基本上能對專案加深影響，能夠讓自己對專案有個更深層次的理解。現在回顧看看自己前一個月，前一週的程式碼都有很多需要修改，值得精進的地方。嗯，程式碼需要迭代，系統需要重構，你我也需精進！
嗯，嘮叨了這麼多，也算是對最近重構工作的覆盤吧！
相關閱讀:
《軟體之路》
掃碼關注，一起進步
個人部落格: http:/