其他_业务重构 - zen0822/interview GitHub Wiki

一、你为什么不敢发代码？

通过代码还原当时完整的产品逻辑太难了

没有自测用例

没有测试同学跟进

没有稳定发布方案

二、寻求组织保障

要形成一个大的规划去看待

三、划分重构页面优先级

你通过细致的研究发现，这些页面中，有 77 个页面是用户使用较多的页面，也是相对比较复杂的页面，剩下的 100 个页面，大部分是给开发用的增删改查页面，用户的使用频率不高。于是你做了如下划分：优先级划分好优先级以后，就要对不同优先级的页面使用不同的稳定发布策略。

复杂高频页面：重兵压上，细致还原原始需求，抠代码，拉测试同学一起整理测试用例，按照测试用例自测，测试同学回归所有功能。但其实这部分页面中，也可以分为两种页面：
- 编辑页面：这样的页面是风险最高的页面，一旦因为后端接口没有做完整的数据校验，就会编辑出脏数据，或者错误的数据被保存，导致线上运行异常，这种后果将是不堪设想的，即使非常短的时间内回滚，也会造成难以挽回的故障，因此必须要像新需求一样测试到位。
- 展示页面：这样的页面不会影响运行时，不会产生脏数据，是风险相对低一点点的页面，本着不麻烦合作方的原则，毕竟资源有限，可以让测试帮你出完整的用例，然后你自己自测，或者多找几个同学帮你自测。
高频简单页面：自测，当然最好是能绑架几个经常用这个功能的开发，来帮你点点，但是自己测总是会有可能会有遗漏，因此就需要下面的步骤来保证了。
低频运维页面：选择性重构，因为很多页面基本上不会有迭代，且使用频率较低，基本上不需要重构，即使是有新的需求，也可以在做新需求的时候顺便重构下，以为并不能占用太多时间。

将页面划分完毕后，你会发现重构的工作量降低了很多，因为本着「无需求，勿变更」的原则，很多页面都可以不需要重构。且上述重构完的页面都必须做灰度发布，关于前端页面的灰度发布后面会聊到。

四、单测

根据侧重点写单测

五、测试用例

你在的团队，一直测试资源都不是充足，测试用例似乎一直都是一种可遇不可求的东西，尤其是在敏捷开发的趋势下，产品功能变动快，很少有测试会一直去维护那个最初的测试用例，往往是写过用过就再也找不到了。但测试用例在重构这个场景下，真的非常重要，他解决的核心问题是把测试同学拉到重构的质量保障中，一起梳理老的逻辑。

这份宝贵的测试用例，可以成为你自测的依据，也可以为你提供对于同一个功能的不同视角，如果你通过代码看到的是实现细节的逻辑，那测试看到的就是整个链路的流程图。很多中后台系统都有管理态和运行态之分，管理态，前端是非常熟悉的，但是运行态，测试往往更加熟悉。

六、自测

拿到测试用例，你就可以自测了，但是这里有个坑，就是如果你完全依赖测试同学给你的测试用例。只要保证测试用例验证通过就行了，这种想法会出大问题，因为负责这块功能的测试可能是个新手，可能并不是一直负责这块功能的测试，他们的测试用例可能只是浮于表面的。所以你需要把通过代码考古发现的测试用例里没有的逻辑，暴露给测试同学，并补充到测试用例里。并且如果发现有一些看不懂的逻辑，就应该搞懂他，那些你不懂的死角，往往上线后就会有大问题，不要心存侥幸。

自测非常重要，但是往往你会觉得开发完了，就算是把这个事做完了，然后就去忙别的事了，并没有好好的自测，心想还有测试呢，等他们提问题，我再改吧。这是一种很普遍的程序员心理，其实很难避免，毕竟事情有很多。这个时候你可以找同组的开发同学帮你点一点，先解决那些显而易见的问题，也算是一个认真负责的程序员了，不要让测试同学给你提太多低级 bug。

七、回归测试

能有测试同学帮你做功能的回归测试真是一件可遇而不可求的事，一定要珍惜，拿出你的大块时间配合好。这其中最重要的就是多交流，测试同学也不一定知道所有的逻辑，在做回归测试的时候，就需要开发和测试反复核对每个逻辑死角，弄清楚，才敢上线。

当然，能够有测试帮你回归的功能都是极易引起故障的功能，这里就有一个技巧就是如何拉测试参与你的重构中来。像这样重要的功能如果测试知道里面的逻辑，你可以怀着请教的心态去问对方，如果对方并不了解，那你就可以讲给他听，一个负责任的测试，应该都非常想了解自己负责系统的重要模块的来龙去脉。

八、灰度发布

即使你做了再多的测试，都有可能有没有考虑到的遗漏点，这个时候灰度就非常重要了，灰度就必须要有灰度工具才行。重构一般是以页面或者区块为粒度按照人来进行的。所以你的灰度工具必须要包含这些功能：

配置用户或者用户组
配置老路由和新路由
配置灰度状态提示
新老页面的自动打点

灰度配置页面，新老动态路由的参数需要保持一致，这样才能把参数传递下去。

九、全量上线

全量上线并不是灰度所有人，而是真正下线老的页面，并删除老的代码，只有到这一步才算重构完成了。

终结

经历千难万险，你终于把重构好的页面上线了，经历了这个过程，感慨良多，只求以后再也不要做重构了，好好做需求不香吗？后头看看整个过程，要想重构的页面上线，不仅要下苦功夫，还要克服人性的一些弱点，要做到这几点：

Double Check：让其他人参与进来，多一个人就能帮你发现更多问题。重构面前，不要相信自己，相信伙伴。
逻辑无死角：不要还有不懂的代码，不清楚的逻辑，按照程序员的第六感，不确定的都会出大问题。
集中注意力：重构不能碎片化进行，要集中大块时间来做，并一做到底，不然过个几天，你自己的代码都会不认识。
一跟到底：开发完成不是重点，全量上线，并下掉老的页面才是结束。

重构方法（方法论）

定规范，升产品，优代码，稳发布

规范标准

合作规范

【项目】项目需求流程机制建设：例会制度，工作流制度，评审制度，需求迭代制度，工单处理规范。
【后端】前后端合作规范：接口，接口文档规范
【设计】前端与 UI 的合作：交互设计文档
【测试】前端与测试的合作规范：冒烟用例，测试用例，bug分类流转。

内部规范

需求技术文档机制
发布规范
Git使用规范
CR 机制

产品升级

关键模块的流程优化
下线没有用的产品模块
帮助系统建设
体验监控
技术改造

应用级别

【迁移】按照新的仓库划分，迁移代码，或者抽离组件
【重写】技术栈的升级（jquery -> react）
【重新架构】按照微前端的架构，重新架构当前应用
【搭建】部分较为简单的运维页面考虑使用低代码搭建平台来处理，比如我们团队的 AIMake

路由级别

【重构】按照路由级别做已有代码的重构
【重写】按照路由，先将 jQuery 代码转为 React，然后切换路由

组件级别

【桥接】对于有些需要在 jQuery 上做迭代的紧急需求，使用桥接的方式，接入 React 组件。

稳定发布

【灰度发布】按照用户，做路由或者应用维度的灰度发布，由微前端框架做支持。
【单元测试】非 UI 的单元测试。
【监控】灰度流量监控。

重构流程

狠下心来 -> 考古 -> 流程图 -> 评审 -> 分粒度 -> 定技术栈 -> 建立防腐层 -> 应用编码策略 -> 灰度发布 -> 回滚 -> 复盘

解析

【狠下心来】一个老项目，不论是技术栈升级还是重构都是一个工作量大，细节多，且容易心态崩溃的事情，所以建立顽强而坚定的信心是非常重要的，尤其是做到底，做完的心态，以及无死角梳理，不留坑编码的意识。
【考古】老项目的改造必然会经历考古的过程，考古就是通过梳理代码逻辑，询问相关知情人的方式，了解业务，了解编码逻辑。但也往往会遇到一些三无项目，无文档，无注释，无人知。这种项目除了死磕也没啥别的办法，但是非常要注意的一点，就是要直面恐惧，看到一堆乱七八糟自己不懂的代码，内心的恐惧感会暴涨，但是其实只要画个5分钟，梳理下恐惧感就能降低70%，不信你试试。你只是在恐惧开始而已。
【流程图】边梳理边画图，不仅可以整理思路，还能沉淀记忆。
【评审】流程图画完了，一定要找相关人，给他们讲一遍，不仅能让自己印象深刻，去除死角，还往往能唤起相关人的记忆，帮你补充很多不知道的点。
【分粒度】按照项目的实际情况，看看这个项目是按照应用，路由，还是组件粒度来做重构。
【定技术栈】虽然我们中后台工作台，是使用 redux+react 的技术栈，但是有的简单项目并不需要 redux ，那就可以不用，有些项目需要使用 AIMake 拖拽，那就借力 AIMake，有些项目中组件适合抽离物料组件，这一步一定带着自己的思考和判断，不能一概而论。
【建立防腐层】防腐层是新老代码的中间的隔离层，例如在 jQuery 里写 React 代码就需要一个防腐层做隔离和桥接。当然防腐层只针对重构的中间状态，他是一个过渡方案，一个重构完的项目不应该有防腐层的存在。
【应用编码策略】现在就要开始写代码了，不同场景下你要选择不同的编码策略，具体的编码策略在上面有讲到，其中最重要的就是重构的策略，重构之下还会有很多种具体的方法，比如大文件拆分，函数拆分，语义化变量命名，加注释，装饰器，适当使用设计模式等。
【灰度发布】路由级别及以上的重构需要使用灰度发布的方式，以保证上线的稳定。灰度发布部分的功能将由微前端框架提供 API 支持。灰度发布是一个「部分发布」->「观察数据」->「全量发布」的过程，因此发布前要确定白名单，可能是用户维度，App 维度，业务身份维度等，其次要有监控打点，这块借力 UTT （团队内部的体验监控系统）的能力，最后就是全量发布，全量发布完了还是要观察数据，稳定运行一段时间以后，一定要把老的代码清理掉。
【回滚】灰度发布一定要具备回滚机制，这个也由框架提供。
【复盘】整个治理过程会形成一个治理记录的文档，复盘以此为基准，做复盘，可以以复盘会的形式，或者就是沉淀一个文档发群里，大家瞻仰下。

重构原则

上述流程是一个相对完整的标准流程，对于不同的项目或者场景可以适当减少步骤，不要钻牛角尖，上述更大的作用是提醒。
做治理是一个沉淀的过程，沉淀业务和技术能力。
没有业务需求或者一年内都不迭代的项目不需要做重构，但需要做迁移和隔离。
迁移和重构策略优先于重写。

重构关键点

业务价值
需求吞吐量提升
用户体验提升
缺陷类的工单量降低
无故障

以上是我们在动手做重构前的心法，贯穿整个重构过程中，希望对大家有一定的指导作用。