代码重构！

了一堆人。

商户相当不满，后来是部门的公关出面，才将事情平息下来，经理那边也因为这个事情，拉我们到办公室批了一顿。

技术负责人也压力山大。我们几个人，在会议室里讨论了很久，***大家都觉得如果要比较好的杜绝此类的问题，除了要加强各种测试等措施外，还有一个，就是要重构现有的代码。

因为这个系统是最核心的业务系统之一，而且几经易手，当时的代码已经变得极难维护，里面各种if else 的分支，还有长达一千行一个的函数，注释不全，文档也不足，要想长期的维护下去，这个技术债是非偿还不可了。

大家面面相觑，虽然知道重构是***的解决方案，但大家都不想搞呀。

后来，我考虑到，初来这里还是要做些事情才能得到大家认可的，就硬着头皮，把重构的这个任务给接了下来。

确定重构的范围

接下这个任务后，我和项目组的成员就开始分析这个系统。

发现这个系统的业务流程很长，涉及到几十个子系统(微服务)，还依赖几个外部门的服务。如果全部重构下来，估计一年都做不完，而且风险极大，重构一年的系统，然后再上线，谁敢呀，而且到那时，说不定黄花菜都凉了。

觉得这样肯定不行。

我们就重新梳理了一遍，把整个系统划分成了三个部分，我们发现中间部分的修改最频繁，出问题的频率也***，就决定先重构中间流程部分的代码。

项目规划部分，我们对项目进行了分期，中间部分的重构作为***期，其他两部分可以作为二期，三期项目来做。一个是可以极大地减少压力，使得的事情更加容易把握，另一个是间隔一段时间有产出也能给团队带来信心。

设计好验证的方式

当确认好重构的范围后，接下来的事情，就是要考虑如何来验证重构后的代码了。

这个是重构代码最重要的一个部分，如果没办法验证重构代码的正确性，你是不敢上线的，就算硬上了，也会睡不好觉。

一般重构代码的验证，可以采用测试代码，测试用例覆盖的方法。(这部分可以参考 《重构》)。但我们发现，我们要重构的这个部分，不能采用这种方式来验证。

因为业务逻辑很复杂，而且涉及到太多的外围系统，一个是测试用例很难覆盖全面，另外一个是没有办法可以很好的隔离外部系统的依赖。

我们分析了整个系统，发现这个系统的功能是，接受商户过来一个请求，然后进行各种权限，角色等的判断，再根据各个参数去各个依赖系统拉取数据，***组装出一个新的包，再把这个新的包发送到隔壁部门的下游系统。

后来，我们想了双流程验证的方案。

我们将重构部分的代码，全部封装起来，然后提供一个新的接口，一个请求进来后，我们分别执行旧的业务逻辑，也将请求发给新接口。在流程的***，我们将新旧流程构造出的字段，进行逐个字段的对比。新流程只验证正确性，不做实际的输出。

为了保证验证的效果，验证要在线上进行，所以还要再结合后面的灰度流程。

尽一切努力，搞清重构代码的逻辑

当我们确定好验证方式后，接下来就是正式的工作了，重构代码。重写代码本身是不难的，但遇到的麻烦是，几乎没有文档，注释也很少，通过看代码只是搞懂了百分之五十左右的逻辑，还有一大部分的逻辑，无法理清楚。

（编辑：大同站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!