前端项目重构的深度思考和复盘 _前端

一. 背景介绍1. 我们为什么要做项目重构项目重构是每一家稳定发展的互联企业的必经之路, 就像一个产品的诞生, 会经历产品试错和产品迭代一样, 随着业务或新技术的不断发展, 已有架构已无法满足更多业务扩展的需求, 所以只有通过重构来让产品“进化”, 才能跟上飞速发展的时代浪潮.

文章插图
图片
这里我结合自己的实际经验总结一下项目重构的几个原因:
1. 技术因素技术因素主要有如下几个方面:

早期技术团队在技术选型上的误判(常发生于MVP类型的产品快速上线导致的技术调研不够充分)
新老技术框架的更替(比如从 jquery 迁移到 vue/react)
技术团队交接出现的断层(老技术团队的架构设计更不上新技术团队的发展, 出现架构上的“平替”)
技术架构升级(比如随着业务发展, 由传统的MPA应用转为基于微前端模式的SPA应用)
安全,性能,代码质量等原因导致的技术重构

2. 产品因素

产品形态调整(比如由纯PC应用转为响应式应用, 或者从H5到支持跨端)
产品业务调整(非常常见的重构理由之一)
产品指标调整(如兼容性, 性能指标等导致的代码重构)

上面是我列出来的比较典型的重构场景, 也是我们未来在设计产品技术架构之前需要考虑的方面. 为了提高自己设计的架构稳定性, 我们需要提前和产品沟通明确, 以降低后期重构和维护成本.
最后总结几条架构设计的经验:

能做规范的一定要严格做好规范
在设计架构之前, 一定要充分理解业务场景, 明确产品的技术交付指标
架构设计以可溯源为基本要求
不要盲目追求最好的方案, 以局部最优解为工程设计理念

3.做项目重构之前, 需要有哪些准备当然做项目重构也是有技术门槛的,不是所有程序员都能做好重构工作, 建议大家具备如下几种技术能力:

对项目所使用的框架语言有相对深入的理解和掌握
有一定的前端工程化经验(如webpack, vite, gulp, nodejs, babel, AST等有一定的研究)
熟悉常用的web性能优化方案
熟悉常见的设计模式和前端编码规范
熟悉前端主流的技术框架的设计原理和工程设计思想

接下来我们一起看看常见的几种项目重构场景及其重构方向.
二. 不同类型项目重构的方法论1. 业务系统自身的重构业务系统自身的重构一般可以包含如下几个方面:

业务代码优化

业务代码优化主要是针对一些核心业务代码, 进行流程上, 逻辑上的重构, 让它更具可读性和维护性, 同时保证业务操作的兼容性, 具体方案如下:

复杂业务逻辑需要编写注释
代码中访问性属性提供兼容逻辑(常见的比如访问对象属性, a.b.c, 如果a,b为非对象则整段代码将报错)
代码结构优化(比如冗长的if else 或者“回调地狱” 可以采用适配器模式或者es6+语法来优化)
方法参数调优(一个函数有多个参数, 可以使用参数对象来提高可读性,降低使用偏差)
业务代码性能优化(复杂后台系统比如低代码类产品, 前端需要处理很多数据和逻辑, 此时可以用合适的数据结构和算法优化js计算)
函数式编程思想优化业务函数(可选)
业务代码进行单元测试, 提高代码质量(可选)
代码规范

早期可能由某名研发单独负责的项目, 对代码规范和格式要求不是很高, 但是需要考虑后期团队扩容带来的协作开发问题, 这个时候如果没有统一的规范, 不同研发小伙伴可能写出的代码千奇百怪, 导致后期维护成本巨大, 尤其是涉及到需要维护他人代码时. 所以我们重构的另一个目标就是降低代码理解成本, 保证项目代码在阅读时就像同一个写出来的, 这样对后期逻辑复用, 组件解耦, 问题定位以及业务代码维护将非常有帮助.