如何写出易于维护的Vue代码（踩坑经验）

目录

前言

正文

data 属性数量不宜过多

组件入参数量不宜过多

mixins 与 业务代码低耦合

建议封装纯函数

数据结构尽量简单

保持良好的注释习惯

合理封装 mixins 与 组件

总结

---

前言

在开发时你心里是否在想着：把功能实现就行了！如果是，那么该文章比较适合你。

“把功能实现就行了”很大可能会增加后期维护的成本！

如何写出易于维护的 Vue 代码？踩坑经验告诉你，请查收！

正文

data 属性数量不宜过多

你是否在开发时，为了自己容易分辨而尝试在 data 中定义各种属性？你是否有过反复修改代码，最后有些属性用不到，但是也不敢删除？你是否有过“复制粘贴”其他页面代码，data 属性懒得删除，直接添加新属性？如果是，那么恭喜你，成功入坑！

对于 Vue2 来说，双向绑定是通过遍历劫持 data 中的属性来实现，越多的属性，代表着内部需要做更多的操作，即性能、效率越低。

暂且不论性能，属性越“丰富”，越不容易理解。如果打开一个页面，前 100 行都是 data 属性，我会望而生畏，甚至没有写下去的欲望。

有句话说的很好：

良药与毒药的区别在于剂量。有少量的全局数据或许无妨，但数量越多，处理的难度就会指数上升。 

不好示范： 

  

data 属性不宜过多，添加有必要或有代表性的属性， 让代码更加容易理解。 

组件入参数量不宜过多

data 属性数量过多，我们可以使用注释来帮助理解。但是组件的入参，即 props 数量过多却让理解的成本更上一层。你首先得先理解父组件内绑定的值是什么，再理解子组件内的入参用做什么。

不好示范：

更有甚者，让父组件跟子组件的名称不一致，理解难度再翻一番。

看到这样的代码，我心想：为啥让我来维护？毁灭吧，累了。

mixins 与 业务代码低耦合

我们知道，合理使用 mixins 可以帮助我们更好地复用组件与理解逻辑。但是，如果 mixins 与业务代码高耦合，这将得不偿失。

当 mixins 中的很多属性与方法都与组件的相同，更有甚者，让 mixins 去调用组件的方法或者变量，导致多出了很多引用，这不是拿起石头砸自己的脚吗？此刻的 mixins 意义何在？

不好示范：

tips：mixins 属性和方法尽量加上特殊前缀与组件方法区分，理解更容易，复用更简单。

建议封装纯函数

如果有一个很重要的业务组件可读性很差，势必要小步快跑的迭代重构，这种情况也不用怕，我们一个微小的习惯就可以让这件事情变得简单，那就是封装纯函数方法。

纯函数的好处是不引用其他变量，可以轻易的挪动和替换；让每个方法尽量不引用 data 属性，这样可以随时迁移或替换该方法，当然，更不要在方法里引入 mixins 里的属性和方法，保持函数的“单纯”。

数据结构尽量简单

数据结构越复杂，越不容易理解，后期维护成本就越高。

数据结构尽量减少循环嵌套与递归遍历，在必要的复杂块添加易于理解的注释。

不好示范：

 

越复杂，最后有可能连自己都看不懂，更别说其他人了，何必呢？

保持良好的注释习惯

你不写注释，别人看起来费力；别人不写注释，你看起来费力。换位思考，你就知道写注释的重要性了，大家好才是真的好。

合理封装 mixins 与 组件

如果你是前端开发，但是你从没封装过可重用的 mixins 或组件，那得抓紧了。合理封装组件，是前端开发人员的必备技能，它可以帮助我们减少代码冗余，提升开发效率，降低理解与维护成本，何乐而不为？

总结

以上就是一些踩坑经验，希望能够帮助大家，一起写出更易于维护的代码！