架构-遗留系统的重灾区

今天想跟大家聊聊遗留系统，首先，看一下这张图

这是一家银行的核心应用系统模块之间的交互图，我想没有一个人愿意工作在这样的系统上吧？

架构混乱，模块之间职责不明，一个需求就要需要修改四五个服务，这就是遗留系统，留给我们的问题。

遗留系统与架构

一个软件架构的作用，是要解决多个业务模块之间的协作问题。但如果架构混乱，多个模块之间往复调用，数据也是随意访问，模块之间的边界就会变得模糊，数据所有权也会变得含糊。试想一下，如果一张表被10个模块访问，谁能说得清这张表到底属于哪个模块呢？

系统之所以成为遗留系统的本质之一，就是架构的混乱。

综合来看，代码和架构的质量差，会导致遗留系统的维护成本相当高昂。

这里的维护就包括：新需求的添加、线上Bug的修改，以及为了维护系统运行所需投入的软硬件和人力等。

IEEE曾报道过，2010年以来，全世界在IT产品和服务上的支出达到了35万亿美元。其中四分之三用于运营和维护现有的IT系统，至少有2.5万亿用于尝试替换旧系统，其中差不多三分之一的资金都打了水漂。企业在遗留系统上的投入巨大，却没能得到相称的回报。很多资金只是用来维持系统的现状，却不能让它们变得更好。

遗留系统架构与安全隐患

代码和架构的落后还会导致系统在合规和安全方面的问题

去年我国正式施行了《中华人民共和国数据安全法》（即中国的GDPR），明确规定了软件系统的数据安全规范。如果不能依法进行系统的整改，将面临法律的制裁。

而在遗留系统开始构建的时候，可能就没有考虑太多的安全性。随着新的攻击手段越来越丰富，遗留系统的安全性越来越脆弱，企业也很难对此投资去专门改善安全性。

遗留系统如何「改造或重构」

曾经的我也遇到过遗留系统，相当痛苦，每天为毫无头绪的代码和混乱不堪的架构发愁，新需求来了根本不知道从何改起。改造和替换又是高风险操作，应该遵循哪些改造原则？重构还是重写，如何选择？

后来我在搜索解决办法时，看到了一段 Thoughtworks资深咨询师「姚琪琳」分享重构遗留系统方法，给我启发挺大，大约 4 分钟，这里分享给大家。

简单来说，首先，你要先梳理遗留系统的根本问题，找到切入口

其次，全面地了解改造过程，知其然，也知其所以然，就像这张图。

将遗留系统模块进行 6 步拆分，即：：①假设驱动 → ②明确度量 → ③确定架构目标 → ④制定演进进度 → ⑤按迭代增量演进 → ⑥验证

「姚琪琳」有 10 多年的软件开发、设计和架构经验。尤其擅长遗留系统现代化、整洁代码和重构等，参与翻译或审校多本技术书籍，包括《领域特定语言》《.NET 性能优化》《深入理解 C#》等。

最近他专门写了个专栏《遗留系统现代化实战》，我第一时间就买了，不得不说，真香！

深入剖析了遗留系统的特点和问题，详解遗留系统现代化的原则、模式和最佳实践，并从代码、架构、DevOps 和团队现代化 4 大方向，解决遗留系统治理的疑难杂症，带你走出遗留系统的泥潭。

再简单介绍下内容，他将遗留系统分成了 4 个篇章：

• 基础篇：为什么要对遗留系统“现代化”
• 原则篇：以降低认知负载为前提、以假设驱动为指引、以增量演进为手段
• 模式篇：20+ 各经典模式，以及来自一线实战总结的实用模式，帮你分而治之。具体的不说了，自己看图，非常清晰。

• 实战篇：将带着你一起对一个典型的遗留系统进行现代化