大家好，我是程式設計師陶朱公。
前言
今天跟大家聊一下關於程式碼重構的話題。
話說，很多程式設計師對自己寫的程式碼平時很隨心所欲(各種魔法變數，一個方法幾十上百行程式碼，還有各種讓人崩潰的變數或方法命名)。
當有一天讓他維護他人的程式碼，他就會抓狂，很容易激發他體內重構的癮。（大多數程式設計師審閱完別人程式碼後，先會忍不住吐槽一番，然後會忍不住想重構一把， ）
在我看來，重構本身是一件值得肯定的事，但有個前提，一定不能影響原先業務功能！
不能因為重構了之後，原來好好的功能反而出問題了，甚至還影響了其他功能，那你這不是重構，是製造問題者。
這裡我分享三個關於重構的小技巧，希望日後小夥伴能謹慎的對待“重構”這件事，避免因為重構導致線上事故發生。
重構三技巧
一、結構化你的程式碼
大家看下下面截圖assembleOffer這個方法，一個方法內部有很多段程式碼，比如1.核心商品資訊程式碼片段，2.產品屬性資訊片段等等。
這樣的方法，因為內部需要執行很多件事情，統一完成後，這個大方法才算真正完成。
那麼現在問題來了，幾十、上百行程式碼都集中在一個大方法內部，這樣的方法顯得太過混亂，最終導致”爆炸“的情況發生，以後維護成本也會成倍增加。
那如果你能用結構化思維梳理一下你的程式碼，然後重新組織如下：
將一個大方法內部的程式碼拆分成多個有明確意義的小方法，然後將它們組裝在一起，這樣的方法就會清晰很多，以後維護起來也會很方便，甚至有一定的複用性。
二、單測
重構完後，一定一定要記得單測。可千萬別過分自信，覺得說自己沒修改多少多少程式碼，然後就強制釋出上線。
這種因為輕視或過分自信，在不自測的情況下，強制上線的生產事故，這兩年還少嗎。
所以經過充分的單測，才能保障你寫的程式碼質量穩健。
最後，如果有條件，我建議你用賬號登陸你的應用，去使用一下你重構後的功能，看它是否表現正常，就當全鏈路驗證了。
關於釋出，這裡提醒一下：如果你此次改動內容比較多，比如新增了資料庫表的欄位、新增了配置中心新的選項等，建議大家提前準備一份釋出計劃，大致內容如下：
釋出前，每執行完一項，就標註一下Done。這樣一路下去，直到最後一項任務的完成。
這樣能幫助你因為釋出的內容過多，避免丟三落四的情況，最終導致釋出失敗，需要二次釋出。
最後成功釋出後，一定記得仔細按照剛我跟大家說的，驗證一下你釋出的功能。當然也要留意一下其他功能特別是主流功能的日誌，觀察是否正常列印，千萬別因你的釋出影響到了其他功能。
三、對修改關閉，對新增開放
大家如果在重構的時候，面對被修改的程式碼，其多個地方引用，這個時候一定要小心了，很有可能你改了某一處，但影響了其他功能程式碼。
這裡我有一個建議：不要去修改這種被多個地方引用的程式碼，你可以新增一個方法：比如過載一個新方法，供你這次的功能呼叫。然後你在這段新方法內部去重構，這樣你的更改，一定不會影響其他功能。
寫到最後
↓推薦關注↓
