背景和問題

在客戶諮詢過程的時候，客戶的小安正好在做一個升級工具的重構，後來他找到我（錢安川），希望顧問能夠指導一下。我簡單瞭解了一下10萬行以下C++程式碼，聽起來業務流程也比較清晰，所以我就答應了，準備帶著大家一顯身手。

我用了2天瞭解業務，3天瞭解了程式碼框架，發現升級工具面臨的問題比我想象的複雜得多：

• 程式碼混亂，到處都是全域性資料和靜態類
• 升級業務流程比較簡單，但是硬編碼了很多批量操作和非同步時間控制
• 程式碼中有很多的hack，導致到處是坑和地雷（我們後面的升級工具開發證明了這一點）
• VC6的環境，沒有測試框架支援

除了升級工具的問題之外，升級工具主開發人員小安，有根深蒂固的面向過程開發經驗，沒有任何面向物件開發經驗，排斥面向物件。他所謂的重構就是隻要把大函式變成小函式，把大類拆成小類就完成重構了。

面對這種現狀，我發現這不僅僅只是一個簡單重構的問題。如果要完全重構好升級工具，必須要重寫基礎架構，也就等於說重新把升級工具重做一遍。這必須要立項，是一個大專案，因為大家的技術水平都比較差，所以風險也很大。所以，我毅然的決定放棄重構升級工具這個目標。我的思路轉變為更多地是把人能力培養出來，顧問可以提意見，給出解決方案，但重構本身不是顧問的工作。

於是我們就把重構範圍縮小在:

一個升級工具的
一個載入功能的
一個CodeSever模組的
一個類CServerLoadMng的
一個叫MakeMmlCmdLine的函式

目標是提升大家用TDD方法重構遺留系統的能力。

重構方法

1. 梳理業務流程
2. 識別痛點
1)報文處理 2) 執行時間 3) 任務控制和中斷 。。。
3. 識別業務領域物件
4. 引入測試框架
5. 指導種子重構。有兩個開發人員一起結對，進行重構開發。我會做在旁邊指導，先保證程式碼可以工作，然後提出建議，讓他們重構

大概2周左右，重構任務結束了。之後我還總結了一篇文章：如何收拾我們的客廳——遺留系統的重構。

經驗和教訓

• 學會放棄。我及時的放棄了重構整個工具的想法，後來證明是很明智的。因為如果遺留系統的架構有問題，如果要重構，就等於把系統再寫一遍。這樣是有很多的工作量和風險的。這不是顧問的工作範疇。顧問更多是把自己的方法和經驗教導給大家。具體的事情，必須由大家來做。
• 重構有風險，工作需謹慎。我們把重構縮小在一個很小的範圍，就是一個MakeMmlCmdLine的函式。新的程式碼放在一個獨立的類檔案，這樣和遺留系統很好的隔離開，並且測試更方便。