如何重構一個系統

發現一個很有意思的情況，做系統寫代碼多年了，遇到的需求基本上是在已有的系統上實作，從頭來實作的系統基本上沒有。

1 why

無論是從頭是實作一個系統，還是維護一個系統，當時實作的技術可能是最先進的、規劃的産品邏輯是合理的，随着時間的發展、開發人員的變更、系統的代碼品質會逐漸腐化，加個Feature太麻煩，改個Bug涉及子產品太多-沒有單測不敢随便解，業務方抱怨技術團隊響應太慢。是時候重構系統了。

對于技術團隊來說，重構能力影響着系統對業務團隊的響應速度。很多職位招聘的時候都要求：

● 對已有系統進行重構和優化；

● 對元件的重用、重構有豐富的經驗；

● 能夠熟練運用各種重構方法；

● 察覺實作問題，提出改進（重構）方案；

● 對架構本身的體系有較為深厚的了解和應用經驗，對架構本身有過開發或重構者可優先考慮

……擁有重構能力的技術人員在個人價值方面也有很大的競争力(^o^)/~

2 how

重構系統的時候，技術人員應該考慮對遺留代碼、第三方代碼、開源代碼、最新技術的合理利用，完全從零開始，在時間上、業務複雜度上都是不允許的。

根據個人開發經驗，我認為應該将重構分為：代碼重構、子產品重構、架構重構3個不同的類型。

代碼重構：這個也系統業務關系比較少，更多的是優秀編碼規則的遵循和實作。例如：統一的錯誤異常抛出和處理方案，易于了解的傳回值模型，統一的入參驗證規則，基于設計模式6大原則的編碼，單測用例的補全和維護。這種類型的重構更易實作，并且對現有業務員邏輯的沒有影響。

子產品重構：技術團隊既要滿足日常的需求開發，同時也要做到原有代碼的重構，開發資源肯定是不夠用的，比較可靠的方案是在標明一個和新需求相關的、并且和其他業務子產品耦合度比較低的業務子產品進行重構，重新梳理業務流程和技術實作方案，這部分重構的實作依賴于代碼重構，良好的編碼規範和代碼品質是基石；對相關業務的熟悉度則是骨架。整個流程一直疊代下去完成整個系統的所有的子產品的重構，這個過程中需要技術團隊基于代碼入手，從代碼級思維跳到設計級思維，抽象出目前的設計模型，考慮适應各種場景帶來的可擴充性、可維護性的壓力了。

架構重構：這個是重量級的重構，如果按部就班的由代碼重構->子產品重構，前2個做好後，架構重構就很自然很容易的實作了：識别各種共用業務子產品，抽取作為各種服務的基礎。如果一開始就重新來做，目前業務需求要暫停，同時技術團隊的開發壓力很大，需要大量的加班來減少對業務響應的阻礙。

參考：http://www.programmer.com.cn/4555/