如何重構代碼-重構計劃

　　上一篇已經闡述了重構的思路和方法，這裡主要闡述下裡面提到的重構計劃。

    首先，瞭解一個待重構的老項目

    項目名稱A，某公司重點項目，已經正式上線運行幾年了，公司業務遍布全球，很多國家都有辦事處或研發部門，也就需要使用該系統。並且隨著公司的不斷髮展，商務程序也在不斷地完善和變化。

    技術上，項目是CS架構的，支援線上和離線兩種操作方式，對於線上方式，資料訪問是直連伺服器上的Oracle資料庫，離線的資料訪問是串連本地的Access資料庫；對於本機資料庫，系統提供WebService來實現本機資料的同步。

    目前項目代碼的規模已經達到100多萬行，負責項目開發和維護是由同一個團對來承擔，其中的開發和設計人員有10人，這些是項目的基本情況。

    項目存在的問題：

    1、維護工作量很大，這佔用了差不多40%左右的時間，這主要是因為易用性差造成的，不過由於在以前的代碼中把太多的邏輯放在UI層上，在業務複雜和介面都複雜的情況下根本不敢去修改，這就導致無法改善易用性。

    2、開發BUG很難減少，特別是做一些變更任務的時候，往往簡單的修改會牽涉出很多BUG，這是由於項目代碼混亂，複製的代碼隨處可見，導致變更分析很難做到全面。

    3、代碼複用度低，導致每個版本的開發時間都比較長，而且，每次的版本開發都導致代碼規模的暴增。

    4、從業務上說項目已經成熟，公司希望將項目產品化起來，並且在內部真正實現組件化（根據業務模組來劃分模組，並像搭具木一塊快速的組合與拆分）的架構方式。

    現有架構：

    項目在架構上根據業務劃分成了幾個子模組，下面是提取出來的三個模組，同時也表示出了模組之間的關係。

       

    在每個子模組中根據傳統的三層模式來劃分，不過層之間業務資料的體現都是以DataTable為核心。

    

    瞭解完上述這些後，不知道大家都有什麼想法？反正對於我來說，這個過程現在想想都鬱悶，從進入項目開始算起，花了三個月的時間才提出了最終的重構計劃！

    1、在存在的問題、現有的架構、重構時間（1個半月的開發時間）和項目風險幾方面的綜合考慮制定了新的架構

     

   （看到上面這幅圖後，有些人可能會坐不住了，覺得很平常化，沒有任何高深或有新意的東西，就連基本的設計原則還都不符合，為什麼不加入設計模式，例如：層次之間的利用介面隔離，資料操作類上可以使用原廠模式等等，其實這些並不是沒有想過，去掉的理由很簡單：初步重構老項目不要去理想化，它的首要目的是解決現有存在的問題，對於理想化的東西我們放到以後的持續重構中去實現。）

     2、選擇重構的代碼，100多萬的代碼不可能在一個半月內都完成重構，所以如何選擇是個很重要的事情，上面三個模組中，銷售模組的使用度最高，其中使用者的問題反饋基本佔了80%，代碼規模處於平均階段，綜合這些考慮選擇這塊進行重構。那麼其他模組怎麼辦？！採用當後期模組內有需求變更的時候，對於變更的內容採用新的架構來做，這樣一步一步地達到目標。

     3、對選擇模組的UI層，讓BA、UI工程師和使用者重新設計介面流程。

     4、對模組內部代碼的變動制定詳細的執行步驟，例如：先從業務層開始在類中新增對象屬性和相關方法，接著利用屬性消除DataTable，最後抽出UI層的商務規則等，並且要清楚工作之間的依賴程度，要做出串列和並行的任務，例如：上述步驟是需要串列的，而基礎組件模組的重構是可以並行的，這樣做是保證你對整個重構過程有很好的控制。

     5、接下來進入實質的編碼階段了。有個注意的地方，最好安排兩個設計人員每天對修改的代碼進行代碼走查，以確保明天不要重構今天的代碼。

 

     就這樣團隊整整辛苦了一個半月後，終於完成了重構！雖然現在的代碼依然存在很多問題，但是至少我們讓一直困擾的問題消失了，也許又會出現新的問題，為了避免這種情況，引入了敏捷開發中的過程-對於每個版本的持續重構！