开篇词｜你现在所写的每一行代码，都是未来的遗留系统

姚琪琳

Thoughtworks 资深咨询师

你好，我是姚琪琳，来自Thoughtworks，很高兴在极客时间与你相遇。

先做个自我介绍，我做过程序员、架构师、技术负责人、技术教练、咨询师，角色一直在变化，但幸运的是始终可以有机会写写代码。业余时间也喜欢翻译，曾经翻译过大大小小十来本技术书籍。

这15年的职业生涯，虽然我尝试了种种工作，但总结起来我大部分的时间都在和遗留系统打交道。既有开发历史已经接近20年的系统，也有刚上线没几年的系统，当然也有开发了十来年，但看上去十分美好的、所谓的“遗留”系统。

在这个深坑中摸爬滚打了多年之后，我在遗留系统开发、治理和改造的过程中积累了大量的一手经验，现在我决定把我和团队的经验分享出来，帮助深陷在遗留系统的泥潭中无法自拔的你。

你可能会说，你当前所在的项目上并没有遗留系统，所有的系统都生机勃勃、一片祥和。不过，根据这些年和遗留系统打交道的经验，我基本可以告诉你，表面的祥和之下，可能暗藏波涛。

你现在所写的每一行代码，都是未来的遗留系统

我的同事，重构和微服务的缔造者，软件开发领域的泰斗，Martin Fowler曾经说过这样一句话：

Let’s face it, all we are doing is writing tomorrow’s legacy software today.

是的，可以毫不夸张地说，你现在所写的每一行代码，都是未来的遗留系统。

这听上去有点让人沮丧，但却是血淋淋的事实。每一种技术的诞生和流行，都有它的时代背景，当这个背景不存在时，也就失去了它生存的土壤。因此你现在所纠结的每一项技术选型，到五年以后都会过时成为遗留产物。

曾经作为行业标准的IOE，现在人人唯恐避之不及；风靡一时的SOA，也最终被微服务所取代；而如果以后云服务进一步发展，大型服务的部署和演进不再是瓶颈，单体会不会重新流行？谁知道呢。

看到这里，你还会觉得遗留系统跟自己没关系吗？即使你现在没有工作在遗留系统上，你也很快就要工作在它上面了。

而随着技术的发展，被遗留系统左右的可不仅仅是开发者个人，还有你所在的企业。我想你一定听说过数字化转型！那些曾经为企业立下汗马功劳的IT系统（也就是遗留系统），此刻反而成为了数字化转型的绊脚石。这是为什么呢？

概括来说就是，IT能力支撑不了企业的市场需求，技术跟不上业务。一个简单的流程更改，都需要很久才能上线；新的数字渠道来临时，系统更是无法支持。不仅如此，有些系统甚至连最基本的可用性都无法满足，动不动就打不开、报错，甚至无法完成业务，用户体验也非常差。面对这样的痛点，系统现代化势在必行。

有太多在遗留系统上折腾的案例，改造的过程声势浩大，结果却令人扼腕。有的开启专项，抽调精英，大刀阔斧地进行整改；有的则干脆重写，企图替换原有系统。但这些行动大多都以失败而告终：有的改造完了仍然无法满足业务，新写的系统也好不到哪去，只不过是又一个遗留系统罢了。

在亲眼目睹了这些惨案之后，我愈发觉得有必要把我的经验分享给你和你的组织了。

你的系统真的不是遗留系统吗？

也许看到这里你还是感觉遗留系统和你无关。要么觉得我手上的系统才两三年，算不上遗留系统，要么立志“让我维护遗留系统就辞职”。

对于第一种想法，你敢打包票自己的系统不是遗留系统吗？很多人以为存在时间很长的就是遗留系统，但这其实是个误区。

时间长短并不能作为衡量遗留系统的标准。有些系统虽然刚开发不久，但你工作起来还是有各种不爽，比如：

代码质量一言难尽，改个需求或做维护经常加班，让你恨不得推翻重写；
架构混乱，模块之间职责不明，一个需求需要修改四五个服务；
CI/CD运转不畅，经常莫名其妙地挂掉，每次升级、上线都一拖再拖；
团队结构不稳定，人员变动频繁；大家都在拼命开发新需求，没人关心技术债；
……

如果以上问题你都自信满满，那我就要拿出杀手锏了。

你的代码有测试吗？你平时开发新需求时会写测试吗？你在修改bug时会补测试吗？经过这样的灵魂三问，你还有自信坚持说自己的系统不是遗留系统吗？

《修改代码的艺术》一书的作者Michael Feathers说过，“没有测试的代码都是遗留代码”。在我们越来越强调软件系统质量内建的今天，仍然有很多系统甚至很多刚刚开发的新系统，由于各种原因不写测试。有的说工期太紧，没时间写；有的说系统原来就没测试，我新加的这么几行代码没必要写。其实每种借口都禁不起推敲，都是在为自己不会写测试来打马虎眼。

软件系统本身就是一个不断熵增的过程，代码逐渐从有序变得无序。如果没有测试的严防死守，熵增的过程就会慢慢加快，代码很快就会变得混乱不堪。

前段时间在硅谷有个新闻，一位华裔开发人员受不了同事不写单元测试，所以愤然离开了这家在国内赫赫有名的大厂。这家大厂的做法和国内的很多互联网公司一样，用大量的昂贵的人工测试，去替代廉价的自动化测试。不是说这样不可行，但问题是它的投入产出比非常低，并且十分低效的。而且是把软件开发这个智力劳动，当成了体力劳动密集型的工作。在我看来，这不但是对软件工作者的嘲讽和亵渎，而且无视了熵增定律，迟早要付出代价。

至于第二种想法“让我维护遗留系统就辞职”。如果你是公司的CTO或者架构师，你还会这么想吗？

技术之路走到后来，你需要更深的技术与业务洞察，更丰富的理论和实战经验。

比如我在代码现代化部分介绍的代码重构，难道你平时写代码不重构吗？显然不是，重构已经成为了开发人员必备的甚至是融入血液的技能。不会重构，怎么好意思跟人打招呼。

再比如在架构现代化部分介绍的抽象分支模式，不也正是我们在日常开发时会频繁使用的模式吗？每当我们提取一个接口来隔离某个变化方向，其实就是一个抽象分支。想想看，你是不是早就习惯了一个接口加一个Impl类的结构了呢（当然，我并不推荐盲目使用接口 + Impl类的结构）？

我的这些经验之谈，并不仅适用于遗留系统开发。像三个原则和四个现代化中的各种模式，其实都是开发新系统常常要用到的。

课程安排

谈了这么多，无非就是表达一个观点：作为工程师，我们比想象中距离遗留系统更近。与其逃避躲闪，不如把它作为我们技术进阶的磨刀石和垫脚石。

在这个专栏里，我会先给你介绍一下我心中的遗留系统现代化的定义。然后按照我最喜欢的技术书籍之一《敏捷软件开发：原则、模式和实践》那样，将遗留系统现代化的各种知识总结为原则、模式和实践。

你一定会好奇为什么叫遗留系统“现代化”，而不是业界常说的“改造”。我其实是有意回避了这个词，因为这个词“重过程”、“轻结果”。我见过太多遗留系统改造之后并没有什么变化，甚至越改越糟。这也是我总结遗留系统现代化三原则的原因。只有遵循这些原则，才能有的放矢，才不会偏离方向。

这三个原则分别是以降低认知负载为前提、以假设驱动为指引、以增量演进为手段。

它们是大多数遗留系统改造项目中容易忽视的部分。很多系统的改造都只针对局部问题，缺乏全局的认知和系统的视角。

比如重构代码是为了什么？只是为了提升可读性吗？拆分模块是为了什么？只是为了架构整洁吗？为什么耗时一年的改造上线之后因为bug太多而不得不被叫停，最后不了了之？相信在学完原则篇后，你能找到答案。

而模式则包含很多了，它们有的来源于网络上或书上，我在实际工作中使用之后感觉受益匪浅，于是拿出来夹带着我自己的理解展示给你。像Michael Feathers提出的接缝模式、Martin Fowler提出的扩张-收缩模式、Eric Evans提出的气泡上下文模式等等。这些大师总结的模式，我用起来的感觉就是两个字：真香。

这些模式，有的则来自于我和同事在实战一线处理完各种疑难杂症后，总结出来的套路，它们适合去解决不同种类的问题。比如为遗留代码添加测试的决策表模式，以及为了更好地持续集成而使用的七步提交法。即使你不在遗留系统上工作，这些知识也能丰富你的工具箱，使你成为解决问题的高手。