你的前端项目可能需要重构了

什么是重构

我们开发惯指的重构，一般都是指技术重构。简单点说就是基于项目进行代码层面的重构。推倒了重新来，老房子扒掉重新造，肯定是有钱了想让自己更舒适，程序代码推倒了重新写，还不是因为代码质量经过长年累月需求迭代，祖传代码越来越难维护，更别说在这个基础上去老树开花，开发一些新功能。（代码太烂，遗留的坑太多，就是程序的拓展性和维护性不好呗画外音，前浪们留下的一堆堆精华 💩 ，需要后狼们一铲一铲地拍在 🏖 上……）

那么问题来了，你的项目到底需不需要重构呢

考虑到项目重构带来的人力、时间、项目风险等因素，在商业项目中，推倒重来是一个风险高，收益低，吃力不太讨好的事情。而且，推翻之前的项目重做，也不定会写出比以前更好的代码。那为什么还要重构呢，或许我们从业务和团队角度分析能得到一些答案。

业务角度分析

---

1. 业务转型了，基于原有业务做得系统自然成了前朝遗老，不招人稀罕了，别说重构，废弃都是有可能的。
2. 业务体量变化，原先的技术架构可能对于百人内的团队，性能上瓶颈不明显，但是随着业务体量的上涨，对于产品性能、扩展性、稳定性的要求越来越高，会推动当前产品迭代及重构的需求

团队角度分析

---

1. 当前技术方案的问题：当前方案是否影响团队开发效率，项目技术方案是否比较陈旧，难以维护，是否存在家属架构及依赖包过于老旧的问题。如果你的项目依赖文件人家官方都已经不维护了，而且官方文档也给出了相关替换方案，那你的项目确实该进行升级、迭代，甚至是换一套新的技术栈进行重构了。
2. 当前项目的代码本身的问题：代码是否基于团队规范标准开发，代码是否有较好的拓展性、健壮性和可维护性。项目代码经过长期迭代，多人轮换，没有规范标准的情况下，代码会变得越来越难维护，一个文件动辄千八百行代码，不用驼峰，不用清晰语义命名，不写代码注释，分分钟逼死强逼症，这样的代码，加个新功能，都要反反复复的翻以前的代码，即使改好了，还有可能因为，之前项目代码不够健壮，报出来其他奇奇怪怪的问题。

那前端开发在项目重构中能干点啥呢

1. 无用的三方库看着不碍眼吗，删掉啊
2. 一些三方库只用了一两次，自写功能成本也不是很高，留着干啥
3. 删除无用变量|无用import 文件
4. 删除用不到的逻辑，精简、抽分通用逻辑
5. 拆分大文件，动辄千八百行的代码文件，不抽分，后期只会越来越多，后期维护成本越来越高，重构代价也越来越大
6. 减少全局样式，采用 css modules 做样式隔离，避免绞尽脑计想命名，也避免跟某个组件库样式冲突
7. 代码结构重构，优化项目工程目录结构，项目迭代下来，会有很多重复的文件目录结构，应该从项目整体角度考虑，合理划分目录结构
8. 代码命名、模块抽分、合理注释总得加一下吧
9. 一些无用的，当时测试用的 console，debugger 看到就删掉呗
10. 做一些必要的依赖升级，项目依赖包一直在升级，为了项目长期稳定的使用依赖包的一些能力，必要的依赖包升级还是有必要的

重构时应该注意哪些问题呢

1. 首先，很认真的问下自己，问下团队相关成员，这个项目是真的需要重构吗，软件迭代是必需的，但是重构真的不是必要的，必要打碎了，重新来过，不一定比之前做的更好
2. 重构时，你要对重构的项目有必要的理解，知道当初这个功能实现的初衷，才能保证重构后的版本，不会有其他不好的影响，建议重构过程中，多看之前的逻辑实现，多问当时参与的人，相关的产品经理、开发，甚至是测试，了解到被注释掉的代码，是否是没用了，真没用了，再扔掉，否则，一刀切，很可能，后期你还得补回来
3. 重构的目的要清楚，你是重构一个组件，一个模块，还是整个系统，整个系统推倒重来，对于任何公司来说都是一个慎重的事情，比较好的做法是，渐进式的重构，把系统切成相互独立的小块，一点一点迭代，可以作为日常迭代，也可以做成专项迭代，看业务需求
4. 架构选型，不一定是什么新，什么流行用什么，得考虑团队或者个人的学习成本，可能这个新技术确实很好，但是现有团队业务开发任务很重，没有必要一步登天，折磨自己，折磨别人，一句话适合自己的才是最好的
5. 明确重构的目的是为了，让项目不像老代码那样臃肿，难以维护，那么定一些标准化的参考规则是很有必要的，最起码保证相当长的时间内，看着像一个正经的项目

我个人在重构过程中的一些习惯（仅供参考）

1. 首先，我会梳理现有项目代码，对照项目页面，给老项目加一点注释标记
2. 创建项目结构 + 功能脑图，项目干了点啥，需要哪些功能一目了然，后期开发，参照起来，安排排期、预估开发进度，个人感觉还挺有用的
3. 标记问题，老项目缺少注释，文件结构混乱是常有的事儿，遇到不理解的，多思多问是个好习惯，提前把风险点记录下来，可以用来评估，这个项目重构带来的结果是不是正向的
4. 参照通用规范，梳理开发标准，像 css、js 的变量命名，模块抽分标准这样还是要有个可参考的开发标准的
5. 基础技术栈统一，一个项目js、ts 混着用，可能是不好的，鉴于现在前端的发展趋势，大方向上使用 ts 会是未来几年的大趋势，也避免了 js 弱类型带来的一些负面影响，样式管理的话，我这边采用的是 less + css module 来做，这样命名相对清晰，也不会造成样式文件相互影响

---

最后，总结一句话，鞋合不合适，只有脚知道。总不能自己给自己穿小鞋儿是不是。项目重构是不可避免的，但不一定是必要的，没必要为了炫技或者 OKR 来做一些吃力不讨好的事情。