概述
在之前的文章技术经理成长复盘-发现团队的瓶颈中提到，需要洞察出团队里需要有什么重要的事情要做，当时分析的结果是，需要先搞重构，把这个事情做了，将来才能提高团队的产出。当时搞重构是非常困难的，有点天空中的飞机换引擎的感觉，具体有如下几个难点：
- 需要重构的功能模块一直还有业务需求，这个对开发和测试人员都是挑战，因为重构的功能如果还没有全量上线，中间就得一直在新旧代码里同时写业务需求，测试人员则每次上线都得两边一起测试,这里也就涉及到一些人力资源的问题；
- 重构的核心功能不能出事，如果有故障，必须一分钟内切回到旧流程；
- 重构的核心功能业务复杂，很容易梳理遗漏；
既然困难点不少，重构负责人就必须对重构这个事情的价值有比较好的认知，不然一遇到困难，就会退缩的。当时团队的实际情况，我在技术经理成长复盘-发现团队的瓶颈提到过，不重构的话，团队的整体产出将会越来越低，后续别说快速交付业务需求了，连响应业务需求都成问题了。另外不尽快重构的话，还有如下几个问题：
- 会成为后续公司进行数字化的拦路虎，因为团队负责的是公司最核心的业务，不重构完，做数字化会困难重重；
- 技术栈不能一体化，运维的同事得同时维护
PHP和JAVA应用，无法很好的做统一化发版、监控，很容易出事；- 系统出了事，永远只能找固定的几个
PHP开发来定位；
好了，说了这么多，下面可以具体讲讲当时重构发生的一些事情了。
列好重构计划并与上司沟通
像PHP转JAVA这种大事情，是一定需要上司的支持的，因为你需要占用一定的人力去做重构的事情，也就意味着部分组员无法承担业务需求开发，那么产品经理肯定是有意见的，而测试那块就更加不用说了，直接加大了他们的测试工作量，而且还可能给他们惹事呢，比如说重构的功能出故障了。那么当产品经理和测试有意见，而自己搞不定的时候，需要上司去协调处理。
比较好的做法是，当上司同意你做这件事情的时候，需要再开个会议，拉上产品经理、测试经理、PMO，将信息和重构计划同频一下，方便后续重构项目的推动。如果他们意见很大的话，连你的上司都搞不定，那就只能将问题上升到更上一层，由大BOSS去拍板。
当时我这边的重构计划，是分三个里程碑：
- 下单、拉起支付、支付回调，这几个模块是最核心最难弄也是最重要的模块，平时大部分的业务需求也都会改动到这块，因此得先动刀，尽快上线，尽快把影响团队接需求吞吐量的地方消灭掉；
- 其他核心模块，重要，但不是最紧急的；
- 非核心模块,主要是一些功能简单的模块。
有了计划，有了人，其他职能团队也都协调好后，就可以开干了。
艰难的下单重构
下单接口的开发和测试时间，其实都不长，还算顺利，但是上线过程确极其艰难，总共折腾9次，灰度了一个多月，才真正的把整个下单接口全量(所有下单请求都全部走JAVA接口)了，后来我分析了一下，有如下几个原因：
- 测试
case有疏漏；- 下单接口业务复杂度超乎想象,很容易漏掉场景和踩到坑；
- 中间有业务需求。
在测试阶段，我们当时的做法是，根据列举好的case，先用JAVA接口下单，然后用同样的商品，用老接口下单，然后进行数据对比，如果新老订单数据能完全匹配上的话，说明新接口的逻辑没问题。但是很遗憾，我们的case漏了不少场景，导致每次刚一灰度线上流量，没过多久，要么接口报错，要么写的数据不对，只能切换回老接口，来来回回折腾了很多次，而每次上线都需要测试和运维的支持,有好几次还让他们在星期六日支持呢，到了后面测试人员和运维，也开始都有意见了。运维的观点是，别老上线，对生产环境得有敬畏之心，测试的观点是，上不上测试说了算。但是作为重构负责人，我是通通不管这些的，因为没有按照计划走，我们说好这个星期要达到什么目标，就必须达到。而产品经理则时不时过来问，全量了没？哎，压力山大。
有网友可能会问，第一次上线失败后，就应该赶紧重新完整梳理一下测试case，但是我想说，那段旧的代码真的不想再看了，真没心情，另外公司也没人可以尽量的将整个下单接口穷举出所有case。不过，当时是有按照用户灰度的，只要一出现问题，能立刻切换回去，对线上的用户影响很小。因此就是遇到一个问题修复一个，折腾了一个月，最终全量。
顺丰顺水的支付回调重构
拉起支付的接口虽然是核心接口，但是业务逻辑不算复杂，上线后，折腾了4次就全量了。这里我想重点说一下最难搞的支付回调接口，虽然难度最大，但却是三个核心接口中，上线最顺利的。
公司是搞茶饮行业的，用户的订单给了钱，支付回调回来后，是有大量的业务逻辑需要去执行的，像打印杯贴小票、跟会员、门店、商品系统交互、跟财务系统对接、订单状态扭转等等。
虽然复杂，但是基于之前下单接口9次才全量上线的教训，支付回调接口特别的强调需要做好几件事情：
- 找个非常细心的开发人员，在重构的过程中，梳理出支付回调的业务场景；
- 邀请了公司里业务最熟悉的测试人员，基于开发列的业务场景
case，写测试用例，尽量确保完整和准确；- 基于测试用例，用同样的商品走新旧逻辑的支付回调，对比打印出来的小票和杯贴(公司是有线下店业务的)，必须一模一样；
- 实时监控,只要有一个报错信息，立刻告警，先于业务方发现问题。
在靠谱的开发和测试的合作下，有了一份非常完整的测试用例，功能测试、回归测试、线上测试都是基于这份测试用例，用了两个星期时间，接口就灰度完毕，全量上线了，且中间基本没出现问题。
跟着业务项目上线的功能
像上面提到的下单、拉起支付和支付回调的重构，都是无法跟着业务项目上线的，因为这些接口上线后都需要灰度，且灰度时间也不短，业务项目的话是不可能上线后还接受灰度的。但是对于一些不需要灰度的重构模块，则可以跟着业务项目上线，这其实一种非常好的方式，既可以做业务需求，给产品经理一个交代，又可以节省测试资源，因为测试人员只需要测试一次，就可以把业务功能和重构的东西一起上上去，提高了效率。
自测的功能
如果测试资源非常紧张的话，业务项目又非常赶，测试人员不愿意带着重构功能上线，那么可以采用如下的方式：
- 完全由开发人员自测后上线，当然这个需要选择细心、代码质量高、熟悉业务的开发人员去做；
- 开发人员自测，测试人员走完主流程后就上线，降低对测试资源的使用。
像最近，有10多个PHP定时任务，我就是让其中一个组员，全部自测后上线，没有动用任何测试资源，上线后一点问题都没有。当然选人很重要，像这种开发自测上线的，最好选择细心、代码质量高、熟悉业务的人来搞。
测试资源不足的话，还有一种办法，就是让开发自测，然后在回归环境，让测试人员过一下主流程即可。不过要提醒测试人员，如果是过主流程的话，一定要认认真真详详细细的过，而不是点击两下界面，数据能写入能展示就完事了，要认真的观察数据是否正确。
总结
本文提到了做重构的价值以及难点，同时也介绍了上线灰度、跟着业务项目上线、自测上线 等重构手法，帮助推动重构。另外要提到一点的是，如果你是重构的负责人，把重构这个事情做成的欲望必须是最强的，不然面对中间过程中出现的困难，绝对会打退堂鼓的。
目前的话，自己团队负责的重构任务基本完毕了，足足搞了大半年，虽然困难重重，但是重构这个技术项目，对公司对团队对个人都是有好处的，有这个，也就值了。
欢迎关注本专栏
感谢。
