维基百科:遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序，“属于或与以前的、过时的计算机系统有关” ，但仍在使用中。通常，将系统称为“遗留系统”意味着它可能已经过时或需要更换。
什么样的系统是遗留系统
Martin Fowler说过Let’s face it, all we are doing is writing tomorrow’s legacy software today.这句话说出了残酷的现实，我们团队现在写的每一行代码最后都会变成遗留系统的代码，这也变相的说明每一个研发工程师都脱离不了改造遗留系统的宿命。从Martin Fowler对遗留系统的描述中我们不难看出来，遗留系统并不是单靠系统的第一行代码距离现在的时间来衡量的，还包含了代码的质量、架构设计、DevOps流水线、支持系统等。很多遗留系统的代码质量都非常差，没有单元测试、API自动化测试、UI自动化测试等自动化的质量保障活动；架构设计混乱，各种设计方式、技术交织在一起；没有交付流水线，所有的交付流程仰仗于某几个研发工程师等等问题才是遗留系统需要面对的痛点。
Michael Feathers在他的书《Morking Bfectively with Legacy Code》中给出了遗留系统的定义：没有自动化测试的系统就是遗留系统。虽然这个定义并不是所有人都认同，但是已经足以看出没有自动化测试的遗留系统对于参与修改的开发工程师是一个灾难。那么对于一个遗留系统，并不是每次都可以启动重构大法完成项目的改进，通过弥补自动化测试解决遗留系统变更的痛点也是不失是一个好办法。
没有自动化测试的遗留系统如何弥补
遗留系统弥补自动化测试实践的首要原则就是”让自动化测试那些你修改的代码“。这句话指导我们所有自动化测试的解决方案，包含了单元测试、API自动化测试、UI自动化测试，甚至也覆盖了静态代码扫码（技术债）。
在面对一个没有任何自动化测试的系统的时候，往往束手无策，尤其是面对几百个小时的技术债务的时候。依据上面的首要原则，要完成所有变更部分的技术债务偿还，也就是修改了那个Class，就要修复该类中的技术债务（也就是静态代码扫码的问题）。并针对变更代码完成单元测试的补充，目标可以定的高一些，例如单元测试增量代码行覆盖率为80%（这个指标也并不是通用的，但是更期望于定一个增量代码行覆盖的高指标，这样可以促使快速还清自动化测试缺失的债务）。
在API自动化测试部分，对应代码变更的API要完成APi自动化测试的开发，并加入到DevOps流水线中发挥增量接口覆盖率100%的门禁检查（很多开源的流水线并不支持这个指标，因此要靠二次开发）。UI自动化则是站在主要业务之上，如果流程中有对一个逻辑的代码发生了变更，那么对应的UI自动化测试就要完成开发并交由流水线触发，并且设置100%成功的质量门禁约束制品晋级。
通过如上的办法，逐渐地将有变更、常变更的代码用自动化测试建立起质量保障的门禁。其他的没有发生过变更的代码，可以在需要变更的时候再补充自动化测试，这样既能发挥自动化测试的优越性也不会给制品团队太大的自动化测试的债务压力，最重要的是不会让开发工程师不敢修改遗留系统的代码。
