未雨綢繆，聊聊舊系統升級改造那些事兒

本文是老系統升級改造的第三篇文章，主要談老系統改造過程當中如何制定規範以及防範技術風險。點擊連接，閱讀前兩篇文章：

洞若觀火，聊聊舊系統升級改造那些事兒

量力而行，聊聊舊系統升級改造那些事兒

老話說的好，不以規矩，無以成方圓。在項目開發過程中須要規範，在系統升級改造的過程當中，規範的制定更加劇要，由於他不只僅關乎最終的代碼質量，更事關項目的成敗。在項目初期試驗pilot階段，就須要制定好代碼改造的相關規範，在w項目當中咱們從如下幾步完成項目關鍵規範的制定與完善。

首先，詳細記錄操做步驟，作好詳細的按步驟操做的文檔，利於後續全面鋪開的狀況下高效的培訓新加入團隊的人員。在此期間，收集代碼修改的規範，詳細指明每一類文件，每一種代碼其對應的改動點，其依據是什麼，應該如何修改，註釋應該怎樣添加，如何命名，統一使用怎樣的代碼格式。

這一步若是作得好，能夠爲開發代碼轉換工具提供轉換模板，使得代碼修改能部分自動化，下降手動修改的過程當中的錯誤率，提升項目開發效率，不過此類工具化轉換是須要原有代碼具有足夠多標準可識別固定模式的源代碼，好比COBOL，RPG等有着嚴格格式的代碼，比較適用於工具快速處理。

固然，舊系統代碼有着足夠多的可識別關鍵字也是能夠作到工具化處理的，這就須要工具開發工程師找到足夠多的能夠識別的模式，經過模板去轉換，若是是工具不能修改的代碼，須要手動修改的，必定要使用工具添加相關注釋註明此處須要手動修改，以便於後續檢查遺漏和修改的結果，並且須要給出詳細的手工修改指導手冊，明確各類不一樣狀況須要如何修改，嚴格執行規範化操做。並隨着項目的進展狀況及時對新發現的改修點作出及時更新，維護好最新的修改手冊，確保沒有遺漏。

其後，測試的數據規範化。採集原始數據，瞭解原有業務邏輯，並記錄下原有系統的輸入輸出數據，甚至進行詳細的截屏，以記錄每一步操做對應的頁面及數據變化，以便後續驗證改造後系統在數據上是否與原有系統一致。

在測試標準化數據準備好後，就能夠充分利用自動化測試工具來檢查輔助程序驗證改修的正確性，減小手工測試的漫長週期。尤爲是在程序年代久遠，文檔缺失，根據程序代碼分析數據處理邏輯又費時且容易出錯的時候，經過對程序執行先後數據變化的記錄，從而開發自動化測試腳本是保證改造先後數據正確性的有效手段，進而保證代碼移植升級過程當中及時發現程序修改的漏洞。

最後，嚴格執行指定的規範，不容許一絲一毫的例外。在W項目裏面，日方規範要求極爲苛刻，文檔格式，代碼註釋這些都鉅細無遺，更爲甚者，連Excel文檔關閉前光標都必須第一sheet頁的第一格，更不要說頁面字符的位置都必需要與設計規範要求一致，不能偏離一個像素，他們都能拿尺子在屏幕上量。對方在檢查此類規範時更是嚴格，有絲絕不同都予以指出，並要求及時改正。雖然咱們沒必要要求細緻到如此程度，但對於完美的追求且不可放棄。

經過以上規範的制定和嚴格的執行，力求將改動點標記好後，通過全部人手動修改後的代碼達到與目標平臺要求一致，同時保留完善的轉換文檔可供後續維護的員工使用。對於舊系統的改造而言，規範比新系統構建的時候更加劇要，由於沒人知道你沒有根據標準修改的代碼會帶來怎樣的bug，尤爲是在測試的時候，debug尤爲不易，會花費數倍的時間去調查。好比在w項目裏面，由於他的IDE當時debug很是不便，出了問題只能靠輸出日誌來查看，因爲程序分支太多，爲了調查一個字段的數據出錯，還得寫一個小工具來給代碼添加幾十上百條log輸出，來找哪一行代碼出錯。如能精心維護好代碼規範，確保每一個改動都能遵循，必將爲項目的順利完成打下堅實的基礎。

未雨綢繆—儘早攻克技術難點，作好技術儲備，防範技術風險

不管是從頭構建項目仍是項目升級改造，咱們首先面臨的問題就是技術選型。通往北京的路千條萬條，那一種交通工具最方便，又是那一條路最適合你呢？

這樣的狀況下，技術選型和預研就很重要，可是每每不是在項目籌備階段纔開始作技術調研。而是在架構師平常的生活中就不斷的閱讀，瞭解不一樣新技術發展方向，瞭解各類各樣工具，各類各樣的技術解決方案，不一樣方案，技術間的差別，各自的優缺點；人的精力是有限的，雖不求將全部的技術都詳盡掌握，但大量的閱讀能夠開闊眼界，當你碰到問題的時候就能夠有足夠多的選擇，就有方向，有的放矢，而不是無頭蒼蠅。

因此咱們講未雨綢繆，就是把工做作到前面，儘早解決技術難點，就能快一步推動方案驗證。這須要架構師在對整個系統所創建的運行環境，有着清晰的認識，對於使用到的架構理念有着深入理解。所謂一千我的心中有一千個哈姆雷特，好比前幾年流行SOA，若是對其沒有足夠的認識，僅僅是作了幾個web service就號稱本身是SOA架構就未免有些名存實亡，由於SOA是一套體系，從服務粒度的劃分，到服務部署，註冊，管理，部署運維都須要一系列的相關技術去支撐，並非開發了幾個web service就是SOA了，所以在對概念不清晰的時候，只知其一;不知其二就急吼吼的採用，每每最後結果是畫虎不成反類犬。

也正如，如今流行的微服務架構，不少人還說微服務就是API接口嘛。其實這裏存在一個誤區，微服務的理念在於，將一體化系統進行細粒度劃分，各自完成獨立的功能，自成體系，各自根據自身的業務發展自行演進，從開發，測試，部署和運維也自行負責，將本來緊耦合的變成鬆耦合，它的從而組成一個完整的生態系統來完成整個應用服務。而不是說個人應用全是restful 接口就是微服務了。

在行動以前理解好概念，分析清楚業務，理清業務將來發展與現狀直接的差別，從而選擇合適的架構，框架以及相應的技術去作pilot，技術方案在獲得驗證事後再從邊緣功能開始作起，積累經驗，攻克技術難點，而後再推而廣之。任何工做不可能一蹴而就，所以系統升級改造過程當中更須要遵循這樣的一個按部就班的過程，經過這個過程去排除各類技術風險，防範在這個過程當中由於技術風險帶來的數據丟失等問題，對於數據一致性要求更高的系統，還要作兩手準備，新老系統有時候還須要並行運做一段時間，一旦新系統有問題能很快切換到老系統上完成業務處理，以保證整個業務運行的可靠性。

在技術選型當中，忌諱的就是盲目使用未經市場普遍檢驗的開源軟件，一味求新求快，必須結合自身實際狀況，業務需求來採用相關軟件，儘量採用成熟穩定，且有足夠技術支持的組件來構建自身的系統。以文件存儲系統爲例，我關注了某分佈式開源文件系統，持續跟蹤和測試了進一年時間纔將其集成到系統當中，做爲圖片的存儲，並搭配Thumbor成爲一個小小的圖片文件存儲處理系統，一年以來也一直運行良好，但後面斷斷續續出現丟失文件的問題，查下來大都是文件莫名丟失，因爲數量不多，就讓業務人員補上了，並未有足夠的警戒。

後面居然出現了大規模的圖片丟失問題，一查文件狀態顯示已刪除，咱們緊急聯繫做者，跟他一塊兒用了一週嘗試解決問題，最終也未能恢復數據，最後只能將備份圖片所有遷移至阿里雲OSS上。這個事情就是告誡了咱們在選擇相關軟件系統的時候，必定要注意其成熟度，應用的廣度，是否是通過了市場的檢驗，再根據業務的實際狀況來使用。

如今雲服務愈來愈多，日益豐富了架構師們的選擇，在選擇雲服務的時候，雖然給咱們帶來了各類各樣的好處，但任然須要有足夠的風險意識，仔細考量其成本，可靠性，以及目前自身的業務需求，是否是與當前的須要所匹配，再行決定。在自建系統與雲服務之間有個成本平衡點，若是採用雲服務這個成本越過了自身運行此類系統的運維成本，那麼咱們選擇雲服務就較爲理想，反之不是那麼迫切，且自身資源足夠的時候，有足夠的能力去維護的話仍是建議謹慎使用雲。仍是那句話，架構中的技術選擇都是因時而動，量力而爲，越早掃清方案當中的障礙，那麼在下一步的過程當中就少一分風險。

做者介紹

王巍，漣拓網絡架構師，先後就任於Achievo、IBM、HP，關注前沿技術，分佈式系統架構，組件化系統開發，機器學習和大數據，如今創業公司負責系統架構，樂於與你們一塊兒聊聊架構。