用现代化的开发方法和思维，打跑遗留系统“拦路虎”

嘉宾 | 姚琪琳

编辑 | 严强

随着技术的不断升级进步，系统也需要逐步升级换代，而遗留系统就像是一只只“拦路虎”，阻挡着转型之路。

要想治理遗留系统，就要弄清楚遗留系统到底是什么。但对于遗留系统的定义，可谓是众说纷纭。到底什么样的系统才会被称为是遗留系统？在治理遗留系统之前，我们需要做哪些准备工作？我们又如何在不影响业务的同时，以更安全、更高效、更低成本的方式将这些遗留系统进行改造，使之更好地支持业务的拓展，适应技术的发展方向？

基于以上问题，我们邀请了 Thoughtworks 数字化转型与运营部门资深咨询师姚琪琳老师来分享关于遗留系统现代化的实践经验，希望能够给你带来启发。同时姚琪琳老师也在 QCon+ 案例研习社【遗留系统怎么办？将改造进行的到底！】专题，带来了「遗留系统现代化的原则、模式与实践」的分享，欢迎收看！

以下是对姚琪琳老师的专访：

InfoQ：你最近在负责什么样的工作呢？

姚琪琳：我现在的身份是技术教练和技术顾问，主要帮助客户解决一些软件技术方面的问题，包括但不限于代码重构、架构治理、DDD 改造、微服务改造、敏捷转型、人才赋能等等。最近的话，是帮助一家企业对他们的遗留系统进行现代化。有意思的是，我从入行到现在，几乎一直都在跟各种遗留系统打交道，可以说已经被“虐”习惯了。

InfoQ：对于遗留系统，有不同的定义，从个人角度，你认为什么样的系统才会被称为是遗留系统呢？

姚琪琳：这是个好问题，我们在治理遗留系统的时候，一定要先搞明白什么是遗留系统，什么不是。对于遗留系统，维基百科的定义是“一种使用旧的方法和技术的、过时的，却仍旧在使用的计算机系统。”Garnter 的定义是“基于过时技术但对日常运营至关重要的信息系统。”从这些定义可以看出来，“技术陈旧、过时、重要、仍在使用”这些就是遗留系统的特点。

维基百科中对遗留系统的定义

“技术陈旧”和“过时”这两个词语不言而喻，符合绝大多数人对遗留系统的认知。但“重要”和“仍在使用”就比较有意思了，它们说明了遗留系统对于企业运营的重要作用。假设一下，一个没人使用的旧报表系统是遗留系统吗？如果按照上述定义，它就不是，因为它不是“仍在使用”和“对日常运营至关重要”。所以遗留系统的定义隐含了一个信息就是，企业很难无视它，如果它本身很庞大、很复杂，也很难被替代。

InfoQ：面对一个遗留系统，我们该如何入手去改造它呢？在开始之前有哪些注意点？

姚琪琳：其实我比较反对用遗留系统“改造”这个词来描述遗留系统的治理工作，因为改造不一定能改好，如果方法不对，很可能越改越糟糕。我见过很多遗留系统，改之后和改之前相比并没有特别大的差别。也有很多改了一半改不动了，只能不了了之。

我习惯使用的是“遗留系统现代化”这个名词。因为“现代化”意味着你的目标是现代的，那么无论从代码、架构还是各种技术上，都要引入现代化的东西。但这并不意味着什么都要用最新的，新的不一定适合你的系统和团队能力，一定要量力而行。

所以我说的现代化是指现代化的开发方法和架构思维。比如在写生产代码时要添加测试，在做架构选型时要注重认知负载，搭建 DevOps 平台来实现持续集成等等。

当然，在开始一个遗留系统现代化项目时，也有很多技术之外的事情要做。首先就是要明确现代化的目标，并制定度量指标，然后以假设驱动的方式来进行验证。很多遗留系统改造的项目在一开始都比较盲目，是为了改而改。比如，将单体拆分为微服务，只是觉得微服务是流行的系统架构，但并没有想过它给整个系统带来的好处是什么，以及如何评价这个好处。所以等改完上线之后，只要没有大的 bug 就算验收了。

但实际上，这会给业务方带来非常糟糕的体验，下次再想“合作”来治理系统，就难上加难了。如果可以在改之前就明确有业务意义的度量指标，每次迭代上线时都监控这些指标，并随时展示给业务方看，就能自然而然地得到他们的认同和支持。

其次，在项目开始之前，还要跟业务方、运营方沟通好，尽量不要在这期间上线新的需求。因为改进和新需求同时做的难度非常大，会凭空增加很多工作量，加大改进的风险。

InfoQ：你印象最深的一次遗留系统改造的实践是什么？为什么令你印象最深刻？

姚琪琳：印象最深的与其说是遗留系统改造，不如说是如何避免一个运转良好的系统成为遗留系统。这其中用到的技能和知识与遗留系统的现代化差不多，但客户的心态却完全不一样。

如果客户的诉求就是治理遗留系统，那我们的大多数举措都会得到支持。但如果客户是想做一个软件，他就会更多地关注我们交付的价值，而不是如何对代码和架构进行维护。然而这部分工作又是十分重要的，否则就是在通往遗留系统的道路上一去不返。

客户的态度决定了我们被赋予的资源，包括时间、人力等等。如何在有限的资源下守护住代码和架构，是对一个架构师最大的考验。

InfoQ：在这过程中遇到了哪些困难？你是通过怎样的努力解决的，有哪些沉淀和启发？

姚琪琳：困难有很多。比如我上面提到的，如果客户想要做单体架构的拆分，他们就会给你时间和人员去做这件事，但如果你是在一个单体架构的项目上做软件交付，想说服客户去做架构的治理是很难的，有时候只能挤时间做。

我曾参与的一个项目有一次终于说服了客户去做架构拆分，但是资源十分有限，只有 80 个人天左右。这对于一个有点规模的单体来说是远远不够的。但少总比没有强，于是团队成员撸起袖子就开干了。然而过程很艰辛，效果却并不理想，以至于以后再和客户去聊类似的问题时，都会吃闭门羹。

吃一堑，长一智。在认真复盘后我们发现，一味地从技术方面去和客户谈判是徒劳的，要从业务出发，去告诉客户技术改进可以给业务带来的价值。比如，如果把系统忙季较常使用的服务剥离出来独立部署和演进，就可以在忙季对这个服务进行扩容，从而更好地支撑业务。同时单个服务的扩容比整个单体的扩容需要的资源更少，也更省钱。再比如，我们抽出两个人专门做两周的部署流水线的优化，可以将代码提交到部署上线的时间缩短 20%，提升业务的敏捷性。当我们拿出的不是技术方案而是价值时，客户的态度自然也就缓和了。

当然这一切都不容易，因为指标的度量都无法准确地估算。

虽然我说的这些是与客户相关的，但其实这和与业务方、运营方的沟通是一样的。大多数软件项目所面临的问题其实都不是技术问题，而是人的问题、利益的问题和价值的问题。

InfoQ：业内有哪些优秀的实践和工具能帮助我们更好地改造遗留系统呢？

姚琪琳：其实一个系统之所以成为遗留系统，就是因为从一开始没有引入现代化的开发方法和思维模式，或者一开始引入了，但没有随技术的进化而跟着演进，没有与时俱进。

我们要做的，就是重新引入这些优秀的实践。比如一个遗留系统没有测试，那我们就引入测试；如果业务都位于前端的 JSP，那我们就把 JSP 中的 Java 代码移动到后端，进行前后端的分离；如果模块之间职责不清，那就和业务人员一起讨论，用 DDD 的方式重新划分上下文；如果项目中没有 CI/CD，我们就引入 CI/CD……自动化测试、前后端分离、DDD、部署流水线……这些都是现代化的开发方法，把它们循序渐进地引入到遗留系统中，那么遗留系统的现代化也就完成了。

提到工具，其实有很多代码分析、模块分析的工具可以帮助我们发现系统中的问题。比如可能所有项目都已经有的 Sonar，它是一个十分优秀的代码分析工具，可以帮助我们发现代码中的很多潜在问题。但恐怕大多数项目都只是引入了这个工具而已，至于是否有计划去改进 Sonar 扫描出来的问题，可能不提也罢。

依赖分析工具包括 Backstage、Aplas、Honeycom、Systems 等，它们可以帮助我们建立一张遗留系统的地图，这样就可以快速知道一个业务是由哪些模块组成的。

InfoQ：当下你都在关注哪些新的技术热点和趋势？

姚琪琳：这个问题有点难住我了，因为我突然发现自己近期关注的热点和趋势都跟“技术”不沾边。我最近关注的是 Cynefin、Team Topologies、Domain Storytelling、元宇宙和认知心理学。

Cynefin 是一个认知框架，它将问题划分为 Clear、Complicated、Complex 和 Chaotic 几个区域，每个区域有不同的应对方式。这个框架对我们这种问题解决者特别有用，它可以让我先将问题归类，再选择应对策略。

还是拿遗留系统来说，如果单纯是技术问题，它就位于 Complicated 域，应对策略是引入专家，进行分析和分解，将繁杂问题分解为很多 Clear 的简单问题。我以前一直都是这么认为的，但直到后来我发现，遗留系统现代化不是一个纯粹的技术问题，它里面包含开发人员、业务人员、测试人员、架构师等各种角色。这些人带来的不确定性，使这个问题变成了一个 Complex 问题。那应对方案就变成了先试验，找出一个可以探索的方向，然后再摸着石头过河。因此，这个先定位问题，再寻找解决方案的框架，让我少走了很多弯路。

Team Topologies 翻译过来是团队拓扑学，我特意在后面多了一个“学”字，因为我认为它未来很可能成为与敏捷齐名的软件开发方法论。虽然它看上去很浅显，只是包含了四种团队结构和三种协作方式，但实际上它提出的 team first 的思想，是远远领先于业内的。这个概念的两位缔造者出了一本同名的书，中文版叫《高效能团队模式》，感兴趣的同学可以看看。

长久以来在大型软件系统的建模领域，似乎就只有 Event Storming 这一种方法，而近年冒出来的 Domain Storytelling 填补了这一空白。它通过讲故事的方法来为领域进行建模，十分有意思。

元宇宙是最近非常火的一个热点，它对我的吸引力就在于这个重命名操作。如果还叫虚拟世界或其他名字，我可能还不会感冒。但是元宇宙这个名字太好了，它给了我无限的遐想。它把这个概念从游戏、社交等有限的场景中跳出来，赋予了无限广阔的可能。仅仅是医疗领域，我就能想到借助于体感衣的远程问诊、模拟手术以提高成功率等等很多使用场景，可以极大地改变人们的生活。

对于认知心理学的关注源自 Team Topologies 中提出的认知负载，这本是认知心理学的概念，我就顺着看了一些认知心理学的书，然后就产生了极大的兴趣。还有一个原因就是我需要辅导五年级女儿的学习，对于如何记忆知识、如何学习知识的好奇，也让我找到了认知心理学。

InfoQ：最后，你是如何走上这条职业道路的呢？和大家分享一些你的成长与进阶经验吧！

姚琪琳：这个说起来我也算是半路出家吧，本科和研究生拿的都是管理学的学位，接触编程的时间也比较晚，不像很多大牛在小学时就开始参加竞赛。我甚至连大学时唯一和编程有关的课程的大作业都是请学长帮我做的。但就是那一次，学长一边跟我聊天，一边就做完了一个系统，谈笑风生且剑指如飞。“这简直太酷了，我也要像他一样”的想法就应运而生了。

再后来就跟很多人一样，从程序员到架构师，就一路走来了。

最后，和对遗留系统感兴趣的小伙伴分享一些心得体会吧。其实我想说的是，没有人会对遗留系统感兴趣，没有人愿意工作在遗留系统上。但是，就像我的同事，重构和微服务的缔造者，软件开发领域的泰斗，Martin Fowler 说过的那样：Let's face it, all we are doing is writing tomorrow's legacy software today.

你今天写的每一行代码，明天都会变为遗留系统。所以你即使没有工作在遗留系统上，也即将工作在它上面了。

因此，你应该调整好心态，积极面对，多喝热水……

嘉宾介绍

姚琪琳 Thoughtworks 数字化转型与运营 资深咨询师

Thoughtworks 资深咨询师，技术书籍译者。拥有超过十年的软件开发、设计和架构经验。近年来在企业遗留系统现代化、领域驱动设计、敏捷软件开发、整洁代码和重构等方面持续精进，并通过理论指导、实战演练等方式为企业研发团队赋能。参与翻译或审校多本技术书籍，包括《领域特定语言》、《.NET 性能优化》、《深入理解 C#》等。