我与重构的不解之缘

背景

电商平台，交易环节必不可少。如正向交易流程中的购物车、下单页、收银台等；逆向交易的退款、仲裁等。从用户角度看，用户通过业务多样性的层层吸引来到交易环节，自然会很希望完成交易的流程也拥有绝佳的体验；从公司业务的角度，我们需要给交易环节提供高效、高稳定的支撑。

现状问题

交易环节经历一个长时间的迭代演变，回过头看，存在以下问题：

• 点状分布，无法可控

  每个交易页面的业务逻辑都很个体化，形成了点，但没有考虑上下游的应用情况，无法感知交易链路上下游环节问题，导致无法串成线，组成面。当业务场景逐渐增多时，只能每个点修修补补，为了兼容功能，交互会逐渐不流畅，项目维护成本也随之增高。

• 冗余代码逻辑较多

  业务发展过程中，有很多阶段性的试错，后续被遗忘，出现断层遗留。在做需求迭代时，很容易被潜在逻辑坑一把。并且，代码冗余，必定会在性能上有折损。

• 注释文档缺失

  依靠人的记忆和扒代码，确认应用范围，定位问题和维护迭代，均有效率损失

• 资源无法共享

  随着公共规范的建设成型，交易团队使用的 React 技术栈与大团队使用 Vue 技术栈不同。很多公共能力无法复用，增加了研发成本；团队的沉淀，也无法反哺公共能力。

无论从业务的快速支撑，还是技术变现来看，以上问题都会造成人效和系统稳定性上的损失。

考虑到我司业务的未来增势，交易能够更好地支撑住业务。我们需要化被动为主动： 重构迫在眉睫

如何重构

曾经，我以为确定重构的项目后，接下来准备工作：

1. 简单过线上流程，大致了解结构

2. 粗略的过一遍原有的工程代码

3. 与产品聊一下历史逻辑

然后，就可以确定技术方案，歘歘歘的写完代码和文档，就完事了。

但开发过程的坎坷和上线后的返工，让我意识到这样的重构还不够。

作 为项目重构的发起者，其角色不仅仅是一个前端开发者。 TA 是产品，是设计师，是测试，更是一个用户。

以重构购物车项目为例，记录下重构的一些 心得 ：

• 前期充分收集信息

1. 产出 PRD：通过熟悉工程代码和借助 PM/RD/QA 等认知，梳理出需覆盖的页面及页面详尽的功能，产出 PRD。下面是我重构购物车时候整理的产品功能图，做好这一步，会让重构事半功倍。

• 页面流程图

• 基础页面

• 梳理购物车功能点

1. 确认交互细节：根据 PRD 原型跑通线上所有流程，整理细节交互。有些特殊逻辑、情景，模拟困难，找测试同学一起配合，尽可能还原应用场景。

• 购物车截图

• 凑单页截图

  购物车

• 项目目标同步

  这次重构不仅是换个语言再实现一遍功能，是在用户体验、日后维护效率、项目质量上都要有相应的提升以及目标。

• 技术方案设计

  重构，不求快，求稳，求极致

  在做技术方案时，不仅考虑用已知能力去解决问题，可以抱着 目标结果最优化 ，尝试引入新技术方式解决问题。虽然会带来一定的时间成本，但值得。

  输出业务功能框架和流程图：

1. 项目基础结构图

2. 流程图

3. 功能模块拆分设计

• 购物车交互 UI 图

• 凑单页交互 UI 图

• 开发日报开发过程中每天要发日报，跟产品、测试同步进度阶段风险同步。

• 定期发起 Code Review 及时发现并解决问题。

整体的重构流程可以梳理成：

以上，是不完全的重构心得。

总结

重构的目的是为了以后新加功能时更容易，让新功能可以尽快上线，代码的结构清晰，让代码变得可读、可维护、可扩，实际是在为以后做准备。

重构之路任重而道远。在后续的项目重构中，我会继续总结提炼一些方式，持续完善，让重构收益最大化。

每天进步一点点，质变从关注 大转转 FE 开始。