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