本文是老系統升級改造的第三篇文章，主要談老系統改造過程中如何制定規範以及防範技術風險。點擊鏈接，閱讀前兩篇文章：
老話說的好，不以規矩，無以成方圓。在項目開發過程當中需要規範，在系統升級改造的過程中，規範的制定更加重要，因爲他不僅僅關乎最終的代碼質量，更事關項目的成敗。在項目初期試驗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，關注前沿技術，分佈式系統架構，組件化系統開發，機器學習和大數據，現在創業公司負責系統架構，樂於與大家一起聊聊架構。