遗留系统的自动化策略

维基百科:遗留系统是一种旧的方法、旧的技术、旧的计算机系统或应用程序，“属于或与以前的、过时的计算机系统有关” ，但仍在使用中。通常，将系统称为“遗留系统”意味着它可能已经过时或需要更换。

什么样的系统是遗留系统

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》中给出了遗留系统的定义：没有自动化测试的系统就是遗留系统。虽然这个定义并不是所有人都认同，但是已经足以看出没有自动化测试的遗留系统对于参与修改的开发工程师是一个灾难。那么对于一个遗留系统，并不是每次都可以启动重构大法完成项目的改进，通过弥补自动化测试解决遗留系统变更的痛点也是不失是一个好办法。

没有自动化测试的遗留系统如何弥补

遗留系统弥补自动化测试实践的首要原则就是”让自动化测试那些你修改的代码“。这句话指导我们所有