超大規模IT軟件項目重構經驗與實踐
1.爲什麼要重構？
一個項目需要重構，一般情況是因爲這個項目可維護性差，或者其功能要擴展已無法適應當下的需要。一方比如，支持新的模型擴展；另一方面，面對雲化時代，無法從單機升級至並行抑或是分佈式雲計算支持。
而我們碰到的就是這樣一個程序，程序以VC6+MFC構建，代碼規模在100多萬行至200萬行之間，單機程序，根據功能不同分爲不同功能方向的子軟件構成。站在這個工程所處的時代而言，客觀來講，程序架構設計合理，結構清晰，但這個當時的模式主流更多的是C++模式的應用，而無法站在應用或者模塊化的角度進行組織；另一層面，由於程序在數據量大規模模擬時，出於對運行效率和規模的當下需求，原有架構模式必須模塊化、並行化方能支持當下業務擴展；第三個層面，代碼過於老舊，用的組件已然找不到資料，特別是數據等；第四個層面，代碼的註釋極少，只有一個固定的作者對其代碼類做了解釋，再一個就是基本上沒有文檔（注：在進行了較長一段時間後，拿了一些幫助手冊等，對概念理解層面有一定幫助；最後一個層面，代碼已經經歷了較長時間的更改（包括界面翻譯），中間也幾經轉手易人，這在概念的統一以及可以確定性的標準方面，對我們造成了一定的影響。
2.重構準備工作
面對一堆代碼，從Java習慣轉到C++習慣光從語言上切換，就需要克服內心恐懼。面前這一堆代碼，就如處於濃霧中，思緒萬千，不知從何下手，內心感覺到一陣恐懼。但是我有信心，有能力搞定他，正如以前經歷過的幾個大項目（與本項目不同）一樣，憑藉着自我的肯定與堅定的信心，這就開幹了(注：在這個方面，過往吹過的牛都實現了，只是容易白頭髮)。
另外，這是一個全新的領域，需要在較短時間內，補充專業名詞、系統原理等概念進行全方位的學習理解，下了幾本專業領域的書籍與相關論文，不得不說明的是，在這種壓力下的學習真的很有效率。
人力構成主要有開發團隊，以及專家團隊，雖然我們對工程實施很有經驗也有自信，但相應的專業領域，這些特定行業內的頂級專家團隊對我們最後的成功起到了決定性作用。當然，這個過程，也是需要磨合成本的。
雖然成功是必然的，但不得不承認，成功也是有偶爾，這個偶爾就在於團隊！（相對抽象，但仔細來講，就是這一整個TEAM的整體輸出能力，工作協調能力，通俗的講，就如結婚，兩口子搭的話，幸福一生；如果不搭，痛不欲生。）。所以，很慶幸，這樣一個班子達到當前的效果，有如當前做訂單可視化一般感同身受。
有了信心，有了自我肯定，有了一個金牌TEAM，這就硬着頭皮上了。自頂向下，梳理項目代碼依純關係、梳理類的繼承關係，找到對象的相互引用（調用）的關係圖，繪製出項目依賴包的關係、定位出被引用最多的函數和類，這一切磨難，在忐忑中前行。
3.壓力與機會，核心路線探索
最初想將VC6的工程放到VS2019上編譯，以方便調試，但出於對C++工程的熟悉程序，幾經嘗試均沒有效果，只能保持現狀，用VC6進行編譯調試，用VS2019進行代碼閱讀與定位（這個問題，在後麪糰隊對代碼熟悉後，由C++經驗多工程師重組了工程文件得以解決）。
3.1. 第一次嘗試
這個時段，對相關概念已不再像最初那麼陌生，出於項目本身是可以執行的，想通過直接將原有代碼進行打包對外提供API的模式。通過一定時間的嘗試，這種方式無法應對寫API對內部狀態的控制，也無法做到並行處理；當然，如果只是讀，不需要改變狀態，這種辦法就是可行的，因此只能另謀他路。
此時，時間已用到三個月，離任務目標時間僅剩7個月。
3.2. 第二次嘗試
此時就得反思，該如何切入？？？
還好，當我事有所思時，我一般在入睡前思考了幾天（這也不好，激動處，易致失眠），終於確定了核心思路。即基於原有軟件可以運行的模式，通過原有軟件生成可以打通流程的文檔，用這個文檔驅動整個研發、測試以及結果校驗流程，抓住核心要點，去掉複雜度，等核心流程打通，確定可行性以及可並行研發時，再通過加人和版本迭代方式快速大面積鋪開。對，就這麼幹(失眠了，唉)。
如何下手呢？嗯，團隊相當給力，通過這個文檔將代碼業務梳理了一遍，對，就是湖南人的精神霸蠻一行一行打日誌，打斷點，終於相流程相關的業務代碼、關鍵事件與活動梳理出來了。對，這就是業務驅動開發，只能這樣，才能從迷霧中尋找到可以衝出來的路線。這一步走對了！！！
這一下，此刻又面臨一個決策問題，如何最快的方式移植代碼。可以做的選擇有：
一、通過自己對業務的理解，重新做架構，只從原有代碼中搬移核心融合算法；
二、通過對原有系統類的梳理，通過壓縮層級和模塊化拆分最小程度改動代碼，最大程度利用原有代碼，同時兼顧了架構。
考慮到第一種方式，最後即使移植成功，擔心結果不被專家團認可，所以就傾向於第二種模式（第二種模式，中間也挫折，傻乎乎的嘗試改變原有命名方式，後面迴歸到盡最大程度不改折騰了一個月）。時間一天一天過去，直到有一天和專家團進行了“和平友好的、激烈的、口乾舌燥的意見交流”閉門會議，達成了採取第一種方式（這個我個人也是最初想選的，只是團隊內部討論擔心結果不認同，所以沒選擇，即這麼激烈、友好的又甲方爸爸認可這種結果，那不正合我意麼）。
此時，時間還剩下三個月（加上下一年的一個月，共四個月，這個時間點，團隊成員的理想人選還在尋尋覓覓中，實話實說，大家心裏慌得一P）
3.3. 第三次嘗試
通過理想人員的加持，路線的多方認同，前面雖然走了彎路，但也看了更多的風景，有更多的經驗，信心倍增，但時間卻很緊。
唯有犧牲多壯志，敢叫日月換新天。此刻的弟兄們，心中有夢想，眼中有亮光，對，幹就完了，一天當兩天用。
雖然還有一堆TODO，但流程已然貫通，靴子落地，這一刻，兄弟們激動了。我猜專家團也跟我們一樣，會很激動地拭一溼潤的眼眶。
4. 寫在最後
對於具備挑戰的未知事件，如 果不能退縮的情況下，幹就完了，管他。
成功，更多的是一種偶然事件；但成功只要堅定信念，秉持着不服就乾的精神又會成爲一種必然事件。
一個困難的事情，要搞定它需要有堅定的信心，喫苦耐勞的定圖片，相互協調的團隊以及資源的支持，這幾個要素缺一不可。
回到本次大規模C++代碼工程上來說，核心思想是業務驅動的模式，通過極限編程，業務版本迭代，前期以流程貫通爲目的進行。自頂向下業務理解，自下而上實施相結合的模式進行。