点击上方 前端瓶子君，关注公众号
回复算法，加入前端编程面试算法每日一题群
来源：ES2049 / 黑石
https://juejin.cn/post/6951373058544730125
将页面划分完毕后，你会发现重构的工作量降低了很多，因为本着「无需求，勿变更」的原则，很多页面都可以不需要重构。且上述重构完的页面都必须做灰度发布。
四、单测
前端不太喜欢写单测，你大概总结了一下，主要有下面几方面的原因：
你发现前端不喜欢写单测，有各种各样的原因，但是当你重构那些复杂页面，尤其是 jQuery 技术栈重构为 React 技术栈的时候，单测真的非常有用。 比如这里有一个编辑页面，包含两部分：基本信息和运行逻辑，在重构运行逻辑时候，你首先要保证的是重构过后的页面在保存的时候，保存的数据结构必须跟之前的接口参数必须一致，所以在重构运行逻辑这个组件的时候就会有很多数据转换逻辑。
可以看到为了保证你的新组件不影响保持原有功能，就要保证原始数据通过新组件的一顿操作最终保留了原来的结构，此时你就可以写单测来保证这个过程。
describe('utils', () => {
it('流程图：转换为提交的数据 transformForm', () => {
const result = transformForm(canvasData);
expect(result).toEqual(settingData);
});
it('流程图：转换为需要的数据 parseRuleSetData', () => {
const [result] = parseRuleSetData(settingData, rules);
expect(result).toEqual(canvasData);
});
it('流程图：反复转换 transformForm - parseRuleSetData', () => {
const [result] = parseRuleSetData(visualSettings, rulesData);
const newResult = transformForm(result);
expect(newResult).toEqual(visualSettings);
});
});
复制代码
前端单元测试写起来复杂，其实只是 UI 的单测复杂而已，如果你把代码做好了足够的拆分，拆出更多函数，更多 hooks ，单测就是轻而易举了。
五、测试用例
你在的团队，一直测试资源都不是充足，测试用例似乎一直都是一种可遇不可求的东西，尤其是在敏捷开发的趋势下，产品功能变动快，很少有测试会一直去维护那个最初的测试用例，往往是写过用过就再也找不到了。但测试用例在重构这个场景下，真的非常重要，他解决的核心问题是把测试同学拉到重构的质量保障中，一起梳理老的逻辑。这份宝贵的测试用例，可以成为你自测的依据，也可以为你提供对于同一个功能的不同视角，如果你通过代码看到的是实现细节的逻辑，那测试看到的就是整个链路的流程图。很多中后台系统都有管理态和运行态之分，管理态，前端是非常熟悉的，但是运行态，测试往往更加熟悉。
六、自测
拿到测试用例，你就可以自测了，但是这里有个坑，就是如果你完全依赖测试同学给你的测试用例。只要保证测试用例验证通过就行了，这种想法会出大问题，因为负责这块功能的测试可能是个新手，可能并不是一直负责这块功能的测试，他们的测试用例可能只是浮于表面的。所以你需要把通过代码考古发现的测试用例里没有的逻辑，暴露给测试同学，并补充到测试用例里。并且如果发现有一些看不懂的逻辑，就应该搞懂他，那些你不懂的死角，往往上线后就会有大问题，不要心存侥幸。自测非常重要，但是往往你会觉得开发完了，就算是把这个事做完了，然后就去忙别的事了，并没有好好的自测，心想还有测试呢，等他们提问题，我再改吧。这是一种很普遍的程序员心理，其实很难避免，毕竟事情有很多。这个时候你可以找同组的开发同学帮你点一点，先解决那些显而易见的问题，也算是一个认真负责的程序员了，不要让测试同学给你提太多低级 bug。
七、回归测试
能有测试同学帮你做功能的回归测试真是一件可遇而不可求的事，一定要珍惜，拿出你的大块时间配合好。这其中最重要的就是多交流，测试同学也不一定知道所有的逻辑，在做回归测试的时候，就需要开发和测试反复核对每个逻辑死角，弄清楚，才敢上线。当然，能够有测试帮你回归的功能都是极易引起故障的功能，这里就有一个技巧就是如何拉测试参与你的重构中来。像这样重要的功能如果测试知道里面的逻辑，你可以怀着请教的心态去问对方，如果对方并不了解，那你就可以讲给他听，一个负责任的测试，应该都非常想了解自己负责系统的重要模块的来龙去脉。
八、灰度发布
即使你做了再多的测试，都有可能有没有考虑到的遗漏点，这个时候灰度就非常重要了，灰度就必须要有灰度工具才行。重构一般是以页面或者区块为粒度按照人来进行的。所以你的灰度工具必须要包含这些功能：
灰度配置页面，新老动态路由的参数需要保持一致，这样才能把参数传递下去。 展示灰度提示，并提供一个快速「返回旧版」的按钮，为了更快速解决问题，可以给出开发者联系方式。
当用户访问老路由的时候，按照灰度配置验证当前用户是否在灰度中，如果在灰度中，则立即跳转到新的路由，并显示灰度提示。如果重构的是页面中的区块，则可以提供灰度命中的方法，在页面调用区块的部分做判断。
灰度策略可以按照以下用户级别分布进行：
发布后，注意观察打点数据：
打点的时候需要注意，要按照动态路由来打点，并分成命中灰度的，点击使用旧版的，不在灰度内的三个维度来看数据，同时每天调整灰度用户，这样就能保证页面是有人用的。如果有很多用户使用了返回旧版的功能，那你就得找找这些用户了解下情况了，到底是有 bug 还是交互不舒服，一对一的解决用户问题，在反复去优化你的页面，慢慢扩大用户灰度范围，直到老的路由访问数据 PV 为 0。
九、全量上线
全量上线并不是灰度所有人，而是真正下线老的页面，并删除老的代码，只有到这一步才算重构完成了。
十、总结
经历千难万险，你终于把重构好的页面上线了，经历了这个过程，感慨良多，只求以后再也不要做重构了，好好做需求不香吗？后头看看整个过程，要想重构的页面上线，不仅要下苦功夫，还要克服人性的一些弱点，要做到这几点：
致敬每一位重构路上的勇士。
最后
本文分享自微信公众号 - 前端瓶子君（pinzi_com）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。