前言
相较于其他框架而言，Vue2中更容易产出屎山代码，因为Vue中的options就是一个大对象，导致js本身的很多检测都失效了，比如组件里没有用到某个data的值，没有用到methods下的某个函数，不会有
'xxx' is defined but never used的eslint提示; template中代码提示比较少，也没有ts检测; 较多的mixins; template和逻辑代码相分离等等
有屎山代码也很正常，多数公司的大部分人都曾经写过一些屎山代码，可能是因为排期紧张，可能是经多人接手，问题在于这块需求不断，屎山代码会给后续迭代带来严重危害。所以在有余力的情况下我们可以对其进行重构，渐进式优化屎山代码
在我看来，好的代码结构设计符合以下几个特点
- 易于阅读
- 易于删除
- 易于修改
- 易于扩展
也就是在业务中的crud，增删改查的成本最小，代表我们需要改动的点就小，危险系数也就越小
大部分人都经历过牵一发动全身的问题，也出现因为改动的链路比较长导致有遗漏点从而导致上线有Bug
如何有效去规避这些问题呢？一个实践就是平时开发时候尽量按照SOLID原则去思考
以下是盘点一些常见的屎山代码，以及优化建议
一、组件不拆分
危险系数 ⭐️⭐️⭐️⭐️⭐️
由于vue是单文件组件模式，template/script/style都写在同一个.vue文件里，每一个.vue的代码行数会比较多，并且template和script是分离的，甚至data和methods都是分离的，导致一个文件行数太多的话，要完整看一个功能点的逻辑会非常麻烦，新人难以上手和维护
优化点
时刻牢记单一职责原则，即一个组件只做一件事，一个函数只处理一个逻辑。如果一个组件承担了过多的职责，他将变得复杂和难以维护
// todo 组件不拆分示例，以及优化代码
二、复杂的表达式
危险系数 ⭐️⭐️
看到这段代码想必头已经开始痛了，一个class，在template里写了大量的逻辑。正确的做法是UI与逻辑分离，复杂的逻辑放到计算属性里去判断，UI层只负责处理一些简单的展示逻辑就够了。
优化建议
将复杂的计算属性放到computed中
相同逻辑下的 if else switch
危险系数 ⭐️⭐️
先来看一个需求 – 简单实现一个常见的促销活动规则
- 预售活动，全场 9.5 折
- 大促活动，全场 9 折
- 返场优惠，全场 8.5 折
- 限时优惠，全场 8 折
以上代码存在肉眼可见的问题：大量if-else、可扩展性差、违背开放封闭原则，如果需要增加更多的活动规则时，开发者不得不侵入到具体方法去修改代码。也常见于表单验证
优化建议
使用策略模式优化
三、组合技 – 多层循环嵌套 + 多层if-else
危险系数 ⭐️⭐️⭐️⭐️⭐
代码节选自某个196行的长函数中的某一小节
当我掏出3层forEach循环，外加N多个if else + &&，不知阁下如何应对
优化建议
拆分成多个函数处理，每个函数只处理小的单元，最后再组合起来。把同一业务逻辑下的代码统一写在一个函数里，从视觉上看代码语义明确，逻辑清晰，但是后续要修改和新增功能的话，就必须梳理整个函数的代码逻辑，不符合开闭原则，可能牵一发而动全身
四、函数副作用
危险系数 ⭐️⭐️⭐️⭐️⭐️
前端要处理ajax的数据，UI层的交互，通常这些地方所带来一些副作用是不可避免的。我们目标不是完全杜绝副作用的产生，而是要利用某些易于管理的副作用的小部分代码，保证整个程序的可读性和可维护性，尽量做到pure function
关于纯函数的好处以及副作用可能带来的危害请参考《JavaScript函数式编程》，或搜索关键词纯函数，引用透明，副作用，immutable.js等
以下是mihoyo-admin-model库里的部分代码，当options参数传入一个没有data属性的对象的时候，会把入参对象改为{ data: options }
优化建议
不直接修改参数的值，可建立一个副本
