再一個交付故事：征服遺留系統
背景
就像曉強在***個故事開篇所介紹的那樣，如今，我們所交付的典型軟件已經變成了由若干個Cloud Native Application所組成的分布式的微服務應用，但是在我們所服務的組織中，仍然存在著類似下面的這種巨大的老舊的單體應用，我們稱之為遺留系統。
有些遺留系統仍然在組織中扮演著重要的角色，持續為客戶提供著價值，而有些則已經成為了組織發展的瓶頸，無法適應業務的快速變化。這個故事便是關于我們是如何幫助客戶有效的維護、提升、最終擺脫這些遺留系統的。
提到遺留系統，我們并不陌生也不缺乏案例。過往的大型項目為我們提供了很多值得分享的經典案例，能夠從這些經驗和總結中感受到在這些項目中所克服的挑戰。這些挑戰分別來自于：
- 如何有效的積累遺留系統的上下文
- 如何對遺留系統進行維護和變更
- 如何能平滑的完成對遺留系統的技術遷移
積累上下文
萬事開頭難，當我們開始任何一項交付工作時，最關鍵的問題便是如何能夠快速建立業務和技術上下文。而當我們開始接手一個遺留系統的時候，這個關鍵問題變得更加復雜和困難。
遺留系統的上下文就和一個沒完成的拼圖一樣，碎片散落一地。有些信息只存在某些人深深的腦海里，有些信息在巨大而且過期的文檔里，難辨真偽。代碼不會撒謊，但是動輒幾百萬行的代碼很容易讓你迷失方向.
在應對這一難題上，我們從以往經驗中形成了一套行之有效的方法。
首先，通過溝通和詢問客戶團隊的業務或技術人員去了解到盡可能多的信息，然后通過閱讀文檔或在可用環境中演示來得到更具象的認識，最終通過閱讀代碼來解除剩下的疑問，完成巨大拼圖中的一部分。
但是在實際操作中確仍然不簡單。往往情況是這樣的，在經過多次溝通和在文檔中查閱信息后，獲得的信息往往和代碼中的無法對應起來，使整個過程需要不斷的反復。我在去年經歷的一次遺留系統改造項目中就有一次類似的經歷，團隊被這個令人沮喪的過程打敗，做出了一些基于已有信息的假設，最終給項目的交付造成了不大不小的風險，團隊付出了很大的代價才保證了項目的順利交付。
在獲得了上下文后，如何保持信息能得到及時的更新并有效的將信息共享給團隊其他人是緊接著需要思考的問題。Specification by Example為我們提供了很好的方式將所有信息有效的管理起來，構建一套和代碼一起管理的可執行的Live Document。但是對于一個遺留系統，這仍然是一個漫長和繁瑣的過程。在這整個信息收集和記錄的過程中，團隊需要展現強大的耐心才能有效的達成目標為后面的工作打下基礎。
開展變更
對于有些遺留系統我們只需要對其持續的監控，保證其能夠正常的提供服務。但是在大多數情況下隨著客戶的業務不斷變化，也會產生對遺留系統進行變更的需求，來迎合這些業務上的變化。那么如何在不破壞遺留系統的前提下修改遺留系統便成了應對遺留系統的第二個挑戰。
用我們所推崇和堅持的一系列敏捷技術實踐可以為遺留系統變更提供一張很好的保護網。
- 在進行對遺留系統的修改工作之前，通過一定的單元測試覆蓋，加上之前我們已經建立好的Live Document，能夠為我們很好的提供質量保證。
- 通過建立針對遺留系統的CI/CD Pipeline可以使我們在修改遺留系統時快速的得到反饋，對變更進行及時的驗證。
- 通過創建Stubs來Mock遺留系統的外部依賴則能幫助我們有效的縮短反饋環，可以大大增強我們對遺留系統進行變更的信心。
這些實踐看起來和我們所交付的其他項目沒有兩樣，但是當你需要為某個老舊語言編寫的遺留系統提供單元測試覆蓋的時候，當你的CI Pipeline需要支持一個老舊的商業中間件的自動化部署的時候，看似普通的技術實踐則會變得困難重重。
這個時候將堅持這些實踐作為原則變得尤為重要。這樣才能為遺留系統的變更提供有效的保障。
技術遷移
當然僅憑耐心和原則是無法征服動輒幾百萬行代碼的龐然大物的。應對遺留系統對技巧有著更高的要求。在這方面，我的ThoughtWorks同事們已經從過去的項目經歷中總結和分享了很多應對遺留系統的技巧。特別是在對遺留系統進行技術遷移的過程中。比如：
- 影響結構圖與特征草圖的使用，幫助我們去梳理程序中各個模塊之間的關系和依賴。
- Branch By Abstraction的使用，使我們可以逐漸的替換將系統中遺留的部分更新并剔除出去。
- Strangler Pattern的使用，讓新老系統在一定的時間段內共存，使遺留系統能夠平滑的遷移到新的技術架構。
- Feature Toggle的使用使我們能在部署后發現異常時快速的切換回老系統，使遷移風險降到了***。
- 針對遺留系統的數據特點建立自定義的數據管道，完成遺留系統數據的遷移。
正是對這些技巧的靈活使用使我們真的做到了“舊的不變，新的創建，一步切換，舊的再見”。
寫在***
遺留系統是個難題，在應對一個巨大的遺留系統時沒有捷徑，同時也沒有神奇的秘籍或令人目眩的黑科技。重要的是，團隊需要意識到在面對一個遺留系統的時候我們需要具備：
- 更強大的耐心 – 去有效的收集和鞏固遺留系統漫長發展過程中遺失的上下文。
- 更堅定的原則 – 去堅持敏捷技術實踐，為遺留系統編織可靠的保護網給遺留系統的變更提供保障。
- 更豐富的技巧 – 去***程度降低遺留系統技術遷移過程中對現有業務的影響，逐步平滑的完成遺留系統的遷移。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
