浅谈代码重构

大家好，我是晨光。从事前端久了，就会发现新技术的迭代速度异常迅速，几年前不成熟的技术，如今也已广泛应用了，想要使用新技术，原有的代码就要做一些技术更迭，用新技术来实现代码重构，有下面几种方式。

1、常见的方式

所有代码推翻重来，新项目，新架构，新的技术实现，逻辑和原来的保持一致。

优点：全部都是新代码，写起来比较爽，宁愿从 0 到 1，不愿基于前人的代码修修改改。

缺点：项目周期长，测试流程长，新需求和技改时间冲突，需要做两份，逻辑同步或追齐，工作量增加

2、组件化重构

对于前端页面，每个模块都可以是一个独立的部分，实际写的代码也是各个模块拆分开来的，所以，可以采用组件化重构。

采用技改的框架，把页面的模块拆分成 npm 的形式，写好一个模块，在原代码中替换，直到最终的模块都写完，整个页面再用新技术搭个框架，把所有的组件再串起来，逻辑部分迁移相对容易。

优点：风险略低，模块迁移，可逐步接入，比一整个页面全量上线成本小些；需求可以不用做两份。

缺点：组件调试起来麻烦，发布成本高

对于试图层，拆分容易些，重构无非就是换一种框架画 UI；逻辑层，大部分都可以复用，可能状态管理的方式会略有差异，但不会影响整体的技改进度。

3、浅谈技改

大部分时候，老板不关心你们代码烂不烂，只要可以运行，功能正常，就无需技改。技改耗时耗力，没有收益，只是让开发代码写起来更爽而已，但也有例外，有些技改也是有收益的。

例如后端的同学，随着应用接口的增加，机器数也随之增加，而且每次发布都会非常痛苦。所以有了 Java 转 GO，上云的技改。目前来看，云函数有很大的优势，大应用逻辑做拆分，需求上线发布快，迭代更快，而且机器使用量也在缩减，降本增效，这类技改，有些必要。

前端的同学，有做多端合并衍生出 BFF 的，也有因为代码太烂整个页面重构的，也有因为通用性高抽离成组件的等等。

4、何时技改

1️⃣ 项目问题太多，老是出故障

2️⃣ 性能不行，页面不够流畅，用户体验差

3️⃣ 代码可读性差，逻辑复杂，维护成本高

技改有意义，但何时技改，需要综合考虑。假如一个很重要的页面，需求迭代多，但老是出故障，逻辑又复杂，维护起来很费劲，那技改就比较有必要，既可以解决陈年老 Bug，还能让代码可读性提高，开发效率也能提升。

还有一个页面，虽然代码烂，但是常年没需求，也没改动，做技改的意义好像就没那么大，如果硬要做，也只是为了做而做。

还有一种情况，就是技改的框架不是很成熟，但需要一个页面试试水，可以找一个重要但非核心的页面，既能尝试新技术，也能有数据来支撑验证。

以上，全文完，有收获记得点个赞呀👍～

#前端