引言
为什么优化或重构？
优化或重构不一定必要的。也不一定是好的选择。每一次代码提交都意味着开发资源和测试资源的重新占用。优化或重构后的系统，短期内也不一定比之前更稳定、问题更少。那么为什么还会选择优化或重构呢？
- 业务逻辑过于陈旧。无人知晓其中隐藏的逻辑，导致代码质量无法保证。
- 某些项目存在大量的高耦合、重复的代码、项目结构混乱。导致开发成本高、维护成本高。
- 解决旧逻辑无法扩展新需求的问题等等。
优化和重构的目的
基于经历过3家公司的代码问题的共性。为了提高开发效率、降低维护成本、减少开发时的烦恼和心智负担。
在职的过程中都进行过不同程度的项目重构，也有过不同程度的架构优化。以下是一些经验和建议。
优化和重构的步骤
优化和重构是否有必要？
所有的技术思考都应该为业务落地而进行。首先要明确业务需求，然后再考虑是否需要进行优化或重构。
- 不优化或重构，新的业务需求是否好实现？
- 不优化或重构，短期内可预见的问题有哪些？
- 优化或重构的成本是否可承受？
- 优化或重构的影响范围？
优化或重构的范围
当决定要优化或重构后。那么要优先确定优化或重构的边界。总不可能一整个系统推倒重来。如何确定优化或重构的范围呢？
- 明确目标。如果目标过远，则需要分解为多个小目标。
- 确定每个小目标的影响范围。
- 进行成本评估。
- 根据影响范围和成本评估，确定每个小目标的优先级。
实践
多个定制项目基于公共模版复用
背景
前前前司有大量的定制项目。定制项目的开发流程大多是基于主营项目复制。然后进行删减和调整。
问题
- 开发效率低。主营项目过于庞大，且对于新人而言。需要花费大量时间了解主营项目的业务逻辑才好进行删减和调整。
- 心智负担高。新人需要花费大量时间了解主营项目的业务逻辑，并在新项目中进行重复的开发。
- 开发成本高。定制项目存在大量的定制逻辑，然后要嵌入到主营项目的旧逻辑中。
- 项目结构混乱。主营项目复杂且经手多人， 删减和排查问题困难。
优化思路
为什么要基于主营项目进行复制？
为了解决登录、用户、订单、柜子管理等基础模块的复用。
新的方案
有了这个思路，可以考虑抽离一个公共模版。然后基于这个模版进行定制开发。
新的问题
开发团队小、项目多且上线时间短。没有足够的资源进行公共模版的抽离。
临时解决方案
在一个相对比较的小的定制项目上。对项目结构进行统一的规范，把公共模块尽可能的抽离出来。后续项目基于该项目进行定制。
契机
后续接到一个开发时间相对充裕的项目。此时再将公共模版抽离出来，并将一些常用的定制项进行配置化。
优化结果
- 开发效率提升。基础模版无需再基于主营项目进行复制删减。
- 开发成本降低。公共模版抽离出来后，定制项目只需要关注自己的业务逻辑。
项目结构优化和资源优化
背景
前前司有一个一期的后台管理项目。后续二期项目转接到我们团队来负责。
问题
- 项目结构混乱。除了登录信息是打通的之外，其他不同的模块都有各自的结构规划， 开发时想复用一些逻辑和方案时，需要花费大量的时间进行查找。
- 代码重复度高。复用功能时，需要拷贝大量的重复代码。
- 项目人力资源不足。之前一期前端开发人员多，开发时间也充裕。二期前端开发人员只有两个。
- 打包产物过大。项目无用的静态资源过多。
优化思路
- 项目结构优化。将项目结构进行规整，方便协同。
- 对需要复用的重复代码进行抽离。例如搜索组件、分页组件、表格组件、定制的表单组件、请求封装、公共字典数据等。
- 对不需要的静态资源进行排查和删除。
- 对体积过大的静态资源放入项目的OSS中。
优化结果
- 需求吞吐量提升。二期需求比一期需求多，但开发时间更短。
- 资源产物优化。静态资源减少，打包产物减小。
拥抱配置
背景
前司作为大型的金融软件系统服务提供商，有大量的基于ExtJS的旧管理页面需要重构。
问题
- 页面数量多。页面数量多，但实际页面操作重复度高。
- 页面操作不统一。技术陈旧，开发和需求对技术理解不一致，导致页面操作不统一。
- 人力资源不足。前端开发人员少，以前都是由后端人员兼职开发ExtJS的页面。
优化思路
- 页面操作统一。将页面操作统一到一个平台上，使用统一的表单、表格、搜索、分页等组件。
- 页面技术统一。使用统一的技术栈，umi+antd+formily.js等。
- 制定和推动前后端接口规范。将管理页面开发配置化。
优化结果
- 页面开发无需重复大量的JS代码。围绕三个配置项进行开发， 搜索配置项、表格配置项、行数据表单配置项。
- 前后端接口规范化。前后端接口规范化，前后端开发人员可以更好的协作。