超大規模IT軟體專案重構經驗與實踐
大東家 xiaohelong2005@126.com
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++代碼工程上來說，核心思想是業務驅動的模式，通過極限編程，業務版本迭代，前期以流程貫通為目的進行，自頂向下業務理解，自下而上實施相結合的模式進行，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/250252.html
標籤：其他