屠杀者模式下的旧系统改造与联调(一)

小Z最近两周一直在进行一个旧系统的改造，业务主要涉及非标的交易，是整个交易环节的一部分，包含项目的申请、审核以及成交结果录入等等。本次改造的目标是与新开发的结算支付系统进行对接与联调。

原有交易系统为.NET编写，新开发的结算支付系统为JAVA编写，双方之间采取WebAPI的方式进行通讯。交易系统原先开发时采用了MVC的模式，存在一个很大的写法问题是虽然采取了MVC的模式，但是没有构建出服务层，所有的服务端业务逻辑全部集中在Controller层，并且还存在相当一部分的前端页面包含了业务逻辑，并且由于是三年前的架构模式，所以也并没有进行前后端分离。整个系统中的代码，基本上都是在每个Action中，现有那么一段 DbContext db = new DbContext()，然后大量的业务逻辑散布在各个Action中。

与其他外部系统对接时，有的采取了WebService的通讯方式，有的采取了DbFirst，直接连接到外部系统所使用的数据库。由于异常设计的不完善，联调时发生报错现象，异常很难跟踪。

参与本系统的开发人员、测试人员、实施人员都已离职，外部系统的操作主要事项留下的资料和文档不齐全。

本月底会对系统进行检查，留给小Z的工期为一个月，并且熟悉.NET、JAVA和业务系统的人选只有小Z一人，短时间内别人帮不上忙。

以上是小Z面对改造时的环境限制。针对要完成这项任务，小Z进行了如下工作：

1.时刻询问离职人员关于遗留系统的开发和测试经验，以及外部系统的操作、联调要点，逐步确认需要改造的代码在哪几个关键类，以及各个功能达成后数据应该展现的状态。

2.由于.NET VS2017 企业版能够快速查到各个方法的引用，所以小Z还是能够比较方便的查询到各个待改造方法的引用。小Z针对各个方法改造采取代码拷贝生成带后缀Refactor的方法（原先考虑生成一种新的方法，最顶层的方法调用重构的新方法，由于每个方法都有几百行的代码量，而且由于代码控制的不规范，大量的代码呈现的是被注释状态，所以小Z并没有采取这个解决方案），逐步替换调用。

3.小Z新增了两个项目，NewXXX和NewXXXUnitTest，前者包含与结算支付系统的对接新构造的业务逻辑，后者是针对前者的单元测试。小Z发现单元测试代码非常重要，因为对于每个Action都包含了几百行的方法以及前后端耦合的程序代码，如果没有单元测试，那么每次进行界面录入而后调试是非常低效和高成本的解决方案。有了单元测试，可以直接关注一个单一工作单元是否能够如预期进行联调，这是加速试错的快速通道。

4.小Z采取屠杀者模式，逐步替换掉各个数据的接入，从业务流程上看数据的流向为：原有结算数据通过DBContext进入原有的结算数据库，通过改造数据流向，逐步通过新结算系统提供的WebAPI将数据存放到新结算系统。不断调试、不断修正、小步快跑、逐步完善，是小Z能够坚持到现在并从目前成果来看能够得到客户认可的必要条件和手段。

5.心态及时调整。从整个技术层面来看，进行一个架构落后、混乱的泥球般的程序改造、对接，不是一项让人觉得愉快的工作。这时候要及时调整心态，积极进行重构，发现问题，解决问题。从目前的结果来看，小Z通过接触这几个系统，能够摸清楚原先企业级系统集成环境下的各个系统直接的工作逻辑关系，这可以说是为之后的整个交易平台的重构积累了一定的经验。

6.目前改造成果已经得到了客户的一定认可，小Z这周末还要花时间去处理演示过程中的不足和剩余的流程改造、遗留的与外部系统的对接问题。

小Z在整个系统检查完后，还会进行一次复盘。

TO BE CONTINUED......