web收银台前端代码重构案例

重构认知：

所谓重构（refactoring） 是这样一个过程： 在不改变代码外在行为的前提下， 对代码做出修改， 以改进程序的内部结构。

存量产品问题：

难以添加新特性：添加1行代码都需要阅读理解相关的几千行代码 存量代码难以理解：培训和维护都异常困难，新员工成长缓慢，某些代码完全依赖于特定的一位老员工，人员依赖风险极大 难以保证产品质量：缺乏有效的自动化测试，添加或修改1行代码都必须手工执行所有的测试用例 接口混乱，组件难以复用：文档缺失、模块内外耦合严重，典型表现为头文件混乱 简单堆砌式实现：各种全局性的控制变量多，并且不断的异常性增加

重构的分类：

小颗粒度重构（函数级、小模块级）【本文重点】 函数级和小模块级的重构应该作为开发人员的一项日常例行工作，在开发过程中只要发现了原有设计实现的不足，随时可以进行。在我司更是应该作为一项基础广泛的群众运动来推广，让重构成为持续改进的动力。小颗粒度重构以开发人员个人为主， committer审核辅导。

大颗粒度重构（架构级、大模块级） 架构级和大模块级重构应该作为一项重要的战役来对待，要做好周密的计划和准备。其成功的关键之一是人力投入，投入的人力贵在精而不在多，也就是必须保证专家的投入。投入的专家可以分为两类：

业务专家：对业务领域、原有实现非常熟悉 软件专家：软件设计、软件重构能力非常强，熟悉领域领先的架构和框架，熟练掌握各种设计模式

web收银台前端代码坏味道识别及重构：

项目通用代码逻辑优化：

通性痛点：

1. 滥用全局变量：如弹框的显示隐藏控制都使用全局变量，而不使用props及emit的方式做父子组件通信。 编码过于随意，其他的开发人员可以随意在毫无关联的地方做控制，代码难以理解维护。 部分不依赖响应式的，通过浏览器缓存来管理；对于非必要的全局变量，通过父子间传值来管理。
2. 结构不良——弹框组件使用混乱：同一个弹框组件如短验输入框，在顶层视图（app.vue）中引入，又在父组件引入。但因为通过全局变量的方式控制显示，导致同时显示2个相同的弹框或错误的弹框。或者同一个业务组件中，需要同时密码输入弹框和短验输入弹框，但是却分布在父组件及更上一层的组件。 控制流混乱。 组件视图当且仅当需要某个子组件时才引入，不要引入后代组件才需要的组件。
3. 结构不良——代码杂糅无分层：template中，存在大量v-if及v-for且里面存在较复杂的逻辑判断。script中存在大量的重复代码，进行数据处理。影响代码阅读。 代码做好逻辑分层：对于通用的数据预处理，在http响应时就可以统一处理。对于个别重要接口的处理，可以根据策略或适配器的重构思路，在响应后即时成自己需要的格式，计算出 自己需要的数据。如各个收银台的支付方式，在下单之后一次性将数据处理成对应场景所需的展示态数据，将分散在各个角落的代码统一整合到数据处理层。
4. 耦合不良——字段或变量作用不单一： 开发为了省事，复用已有的字段或变量。如支付方式中的isDefault本来用于表明是否为默认支付方式，被滥用来标志被用户选择。营销活动里推荐活动、用户选择活动、返券/立减不同活动，其数据格式不一样，却全在一个变量中处理。在不同层级组件中处理得面目全非。 开发人员在修复bug时，尝试从多个数据源获取数据。维护人员自己都不清楚各个数据用途。 拆分出独立含义的字段或变量，并定义对应的数据结构约束变量字段的随意添加删除。重构混乱的业务逻辑逻辑。

基本都属于变量滥用及代码逻辑不清

PC端代码逻辑优化：

重构优化前痛点：

1. cashier.vue主页面代码行数超1000行，所有代码逻辑杂糅到该页面；
2. 冗余重复——页面逻辑重复杂糅: PC端存在个人快捷收银台，个人网银支付，企业网银支付，存在多套大同小异的代码。
3. 耦合不良——发散式变化：对支付方式里数据的处理，在视图层最后需要时，才临时计算，导致数据处理逻辑散落在各个角落。

重构思路：

1. 获取支付方式后，统一对数据做预处理。提前将后续需要的数据提前处理好。
2. 将数据处理函数提取到util中，并按业务场景维度提取service层的方法函数，将各个收银台的核心业务逻辑函数提取到servce。

Mobile端代码逻辑优化：

重构优化前痛点：

1. cashier.vue主页面代码行数超1000行，所有代码逻辑杂糅到该页面；
2. 局部膨胀——页面主要逻辑为支付方式展示及营销活动选择；业务逻辑有明显的分层，但没有提取任何组件。
3. 结构不良——因为没有合理分层，且不愿添加额外的对象管理子数据，存在对响应式对象里的对象或数组进行更改的操作。阅读维护困难。

重构思路：

1. 提取基本的组件PaymentItem.vue及MarketingDialog.vue用于展示单个支付方式及营销活动的展示和交互；再提取出已绑卡、新卡、关联卡、不可用卡列表组件。
2. 对支付方式数据进行预处理，每个支付方式下独立出推荐活动（recMktInfos），全量活动(allMktInfos)的变量，并拓展此前优惠信息对象的结构，统一数据结构。便于页面的渲染和交互时的数据操作。