今天想跟大家聊聊遺留系統，首先，看一下這張圖

這是一家銀行的核心應用系統模塊之間的交互圖，我想沒有一個人愿意工作在這樣的系統上吧？

架構混亂，模塊之間職責不明，一個需求就要需要修改四五個服務，這就是遺留系統，留給我們的問題。

遺留系統與架構

一個軟件架構的作用，是要解決多個業務模塊之間的協作問題。但如果架構混亂，多個模塊之間往復調用，數據也是隨意訪問，模塊之間的邊界就會變得模糊，數據所有權也會變得含糊。試想一下，如果一張表被10個模塊訪問，誰能說得清這張表到底屬于哪個模塊呢？

系統之所以成為遺留系統的本質之一，就是架構的混亂。

綜合來看，代碼和架構的質量差，會導致遺留系統的維護成本相當高昂。

這里的維護就包括：新需求的添加、線上Bug的修改，以及為了維護系統運行所需投入的軟硬件和人力等。

IEEE曾報道過，2010年以來，全世界在IT產品和服務上的支出達到了35萬億美元。其中四分之三用于運營和維護現有的IT系統，至少有2.5萬億用于嘗試替換舊系統，其中差不多三分之一的資金都打了水漂。企業在遺留系統上的投入巨大，卻沒能得到相稱的回報。很多資金只是用來維持系統的現狀，卻不能讓它們變得更好。

遺留系統架構與安全隱患

代碼和架構的落后還會導致系統在合規和安全方面的問題

去年我國正式施行了《中華人民共和國數據安全法》（即中國的GDPR），明確規定了軟件系統的數據安全規范。如果不能依法進行系統的整改，將面臨法律的制裁。

而在遺留系統開始構建的時候，可能就沒有考慮太多的安全性。隨著新的攻擊手段越來越豐富，遺留系統的安全性越來越脆弱，企業也很難對此投資去專門改善安全性。

遺留系統如何「改造或重構」

曾經的我也遇到過遺留系統，相當痛苦，每天為毫無頭緒的代碼和混亂不堪的架構發愁，新需求來了根本不知道從何改起。改造和替換又是高風險操作，應該遵循哪些改造原則？重構還是重寫，如何選擇？

后來我在搜索解決辦法時，看到了一段Thoughtworks資深咨詢師「姚琪琳」分享重構遺留系統方法，給我啟發挺大，大約 4 分鐘，這里分享給大家。

簡單來說，首先，你要先梳理遺留系統的根本問題，找到切入口

其次，全面地了解改造過程，知其然，也知其所以然，就像這張圖。

將遺留系統模塊進行 6 步拆分，即：：①假設驅動 → ②明確度量 → ③確定架構目標 → ④制定演進進度 → ⑤按迭代增量演進 → ⑥驗證

「姚琪琳」有 10 多年的軟件開發、設計和架構經驗。尤其擅長遺留系統現代化、整潔代碼和重構等，參與翻譯或審校多本技術書籍，包括《領域特定語言》《.NET 性能優化》《深入理解 C#》等。

最近他專門寫了個專欄《遺留系統現代化實戰》，我第一時間就買了，不得不說，真香！

深入剖析了遺留系統的特點和問題，詳解遺留系統現代化的原則、模式和最佳實踐，并從代碼、架構、DevOps 和團隊現代化 4 大方向，解決遺留系統治理的疑難雜癥，帶你走出遺留系統的泥潭。

現在剛剛上線，用我的優惠口令xitong666，到手僅需￥69。

或者你可以直接購買極客時間的超級會員，首月 6 元，就能免費看這個課

想永久擁有，還是想學習一段時間，看自己選擇。

再簡單介紹下內容，他將遺留系統分成了 4 個篇章：

• 基礎篇：為什么要對遺留系統“現代化”

• 原則篇：以降低認知負載為前提、以假設驅動為指引、以增量演進為手段

• 模式篇：20+ 各經典模式，以及來自一線實戰總結的實用模式，幫你分而治之。具體的不說了，自己看圖，非常清晰。

• 實戰篇：將帶著你一起對一個典型的遺留系統進行現代化

有多干貨，看看下面的專欄目錄

也許，你當前所在的項目上并沒有遺留系統，所有的系統都生機勃勃、一片祥和。不過表面的祥和之下，可能暗藏波濤。

技術可以流行一時，但終將被淘汰，而方法論卻可以像陳年老酒一樣愈久彌香。也許你正在癡迷于新技術，但，新≠好，只有掌握了解決問題的方法，才能不懼任何問題。而不是把新技術當個錘子，看什么問題都是釘子。

掃碼試讀

遺留系統怎么辦？將改造進行到底！