前端重构和优化的思考

 

为什么要重构

1. 原来的项目漏洞（bug）太多，或者稳定性太差，当前的框架很难彻底根治。

2. 新的项目需求，原有的程序框架已经无法满足。

测试

如果原来的代码没有单元测试、集成测试，有条件的话一定要补充上。为什么测试如此重要？打一个比好，重构就好像对着一把老钥匙来配新钥匙，而测试代码则是老钥匙的模子，我们做出来的新钥匙要能够和这个模子全对上。这个模子越详细，则新钥匙可以正常开锁的概率越大 --- 重要

分支管理

分支管理一定要做好

开关

稍微大一些的重构，我会比较推荐使用程序开关，使用一些控制参数来控制逻辑入口是用老代码还是新代码，这样在线上出现了问题，可以及时的调整控制参数，迅速的回滚到老的逻辑。

 

使网站前端兼容于现代浏览器(针对于不合规范的css、如对IE6有效的) 对于移动平台的优化 针对于seo进行优化 深层次的网站重构应该考虑的方面 减少代码间的耦合 让代码保持弹性 严格按规范编写代码 设计可扩展的API 增强用户体验 ？ 通常来说对于速度的优化也包含在重构中 压缩js、css、image等前端资源(通常是由服务器来解决) 程序的性能优化(如数据读写) 采用CDN来加速资源加载 对于js DOM的优化 HTTP服务器的文件缓存

 

遵循单一职责原则，使用 HOC / 装饰器 / Render Props 增加职责

避免在 JSX 中写复杂的三元表达式，应通过封装函数或组件实现

 

为啥要重构

1. 原来的项目漏洞（bug）太多，或者稳定性太差，当前的框架很难彻底根治。

2. 新的项目需求，原有的程序框架已经无法满足。

什么是重构

 在不改变外部行为的前提下,简化结构、添加可读性,而在网站页面上保持和以前一致的行为和操作

 

重构需要考虑的事情

测试

如果原来的代码没有单元测试、集成测试，有条件的话一定要补充上。为什么测试如此重要？打一个比好，重构就好像对着一把老钥匙来配新钥匙，而测试代码则是老钥匙的模子，我们做出来的新钥匙要能够和这个模子全对上。这个模子越详细，则新钥匙可以正常开锁的概率越大 --- 重要

 

分支管理，新老版本切换

分支管理一定要做好

稍微大一些的重构，我会比较推荐使用程序开关，使用一些控制参数来控制逻辑入口是用老代码还是新代码，这样在线上出现了问题，可以及时的调整控制参数，迅速的回滚到老的逻辑。

 

全局状态管理

大部分情况下建议少维护全局的状态或变量。 一般需要贯彻全局或很多页面的这个时候才用全局状态

全局状态管理和prop传递/location传递的选择

 

css样式重叠问题和覆盖问题

引入插件解决？

加上命名规范解决？

 

代码副作用问题

减少代码副作用 让代码更可控；如果要写副作用，每个副作用尽量都写上依赖。

 

数据和ui组件剥离问题

是否考虑数据处理和ui展示的分离

函数式编程 减少代码耦合性 增加代码独立性。

写代码前多思考，考虑周全，思维先行，代码后行。

中间层数据处理，中间件是否需要？

 

文件目录是否需要调整

让目录更加清晰明了，使新人能快速看懂或者自己能快速找到相应文件。

个人建议前端目录结构使用以页面为单位划分，这样看到页面就能直接知道是那个文件

 

项目规范问题

eslint+prettier 插件

类型不能用any 让变量类型都边的可追溯。方便后续排查问题

 

组件模块化

公共组件，组件独立性，每个组件（至少公共的组件）都得跑单元测试并通过

 

插件的选择

轻量级，符合项目需求，尽量已经被广泛使用的，并在持续更新的插件

 

代码可维护性，代码开发中的细节提升

易读性，注释率

不要修改原数据和传进来的参数，尽量用深拷贝

尽量用组件或者函数来替代三母运算；如果非要写三母。 不建议多层包裹

组件代码尽量控制在200行以内

 

性能优化

请求的优化，资源的压缩优化

 

单元测试+mock数据

单元测试能对项目中的某个模块进行测试基本逻辑和功能是否正确，有利于减少后续bug 和后续维护

前后端分离。如果确认数据格式后 大致的用mock数据前端先进行页面的开发，让前后端进行同步开发，目前我们好多项目都没有做这一块

 

 

 

重构方式

提炼函数（常用）

1.确认函数是用来干嘛的

2.将需要提炼的代码解耦，比如变量，参数说明耦合关系之类的

3.提取代码放置函数里面，一功能一函数（细化功能，函数式编程思想）

搬移函数

1.检查函数在当前上下文里引用的所有元素（变量和函数），确定是否需要将他们一并搬移

2.检查待搬移函数是否具备多态性

3.移动加测试（函数逻辑测试，单元测试）

内联变量

 

多态取代条件表达式

 

1.复杂的程序逻辑是代码里面最难理解的，各种条件判断等。 简化逻辑判断或抽离成函数

 

 

数据资料：

如果一段代码能正常工作，并且确定了后续都不会修改，那么完全没必要重构，除非有人觉得很难理解，并且有成本让你去修改。是需求的变更让重构变附加上了必要性。

1. 测试保证程序和以前一样不出问题。（重中之重）

2. 如果你给一个程序或模块添加一个新功能，发现代码因缺乏良好的结构而不易于进行更改，如果时间允许情况下，先重构那个程序或模块。

3. 提炼函数（106），内联变量（123），搬移函数（198），多态取代条件表达式（272）（搬移函数和提炼函数可以一起使用）

4. 函数参数化 高级组件（ps：大部分一般的公司很少用这玩意，不建议萌新使用，还是建议写出让萌新更容易理解的代码，仅个人观点）

5. 新功能添加时发现有相同的功能代码。可能略微有点差距。这个时候就得重构，为函数添加或修改参数，（前提：函数本身不是很复杂）

 

命令式编程和声明式编程

命令式：面向对象越接近人类语言越精细，细化一步步过程

声明式： 函数式编程 只关注结果。不关注过程

 

ps: 本文只提出了一些建议，具体还是得根据项目情况来实施。

 

参考资料：《重构-改善既有代码的设计  第二版》    链接: https://pan.baidu.com/s/1MLPIirW3R44XdZct2mjoJQ  提取码: v228