深圳服装网站建设,服务营销案例100例,富阳区建设局网站多少,找图片素材网站前言 相比其他的框架来说#xff0c;Vue中更容易产出屎山代码#xff1b;因为Vue中的options就是一个大对象#xff0c;导致js本身的很多检测都失效了#xff0c;比如一个函数没有用到的话会“变灰”#xff0c;template中代码提示比较少#xff0c;较多的mixins等等Vue中更容易产出屎山代码因为Vue中的options就是一个大对象导致js本身的很多检测都失效了比如一个函数没有用到的话会“变灰”template中代码提示比较少较多的mixins等等遇到屎山代码大多数人第一反应就是这谁写的代码这么差其实大多数公司大多数人至少曾经都写过一些屎山代码有屎山代码很正常问题在于怎么快速梳理出业务逻辑防止在迭代新需求时引发bug在富有余力的情况下可以进行局部重构渐进式优化屎山代码 今天重点就看一看Vue2中的那些屎山 文章目录 一号屎山--目录杂乱二号屎山--奇葩命名法三号屎山--组件不拆分四号屎山--复杂的表达式五号屎山--大量重复节点六号屎山--if else switch七号屎山--后端参数处理八号屎山--硬编码九号屎山--Mixins屎山十号屎山--无用代码不删除十一号屎山--类名无规范十二号屎山--样式大量重复十三号屎山--不写注释十四号屎山--组件不写name 一号屎山–目录杂乱
危害程度⭐️
src/
├── App.vue
├── api
├── components
├── constants
├── main.js
├── pages
├── router
├── services
├── utils
│ └── hash.js
└── views
看一下上面的目录views和pages是类似的含义都是指的路由对应的页面而api和services也是类似的都是存放后端接口的封装同时存在这几种文件夹说明项目初期没有规范每个人按照自己的规范去开发导致有的人页面写在views里面有的写在pages里面建议这几个相似含义的目录只保留一个 一号屎山的危害在于让后续接手的人要频繁切换文件夹去看不同页面的逻辑并且不知道后续自己应该在哪个文件夹开发自己的页面导致恶性循环
二号屎山–奇葩命名法
危害程度⭐️⭐️⭐️⭐️⭐️ 奇葩命名法有以下几种情况
全拼音命名法 ”毕竟都是中国人嘛全拼音命名大家应该都看得懂吧“举个例子dazhe.vue。但是同一个拼音可以翻译出不同的意思出来他们之间是一对多的关系因此不适合作为组件名当然全拼音命名还算是手下留情的有的时候全拼音命名可能会很长那就直接取首字母吧
拼音首字母命名法 于是dazhe.vue变成了dz.vue这个时候就成了猜谜语有一首歌词写得好女孩的心思男孩你别猜别猜别猜你猜来猜去也猜不明白到了这里就是代码的心思你别猜直接放弃吧
中西合璧命名法 有些同学觉得光中文那不太高大上啊要把英语也加进来才能显示自己的水平所以这样命名dzList.vue照样还是让人看不懂
英文首字母命名法 我想这种方式命名的同学应该不多吧毕竟已经拿起翻译工具翻译了直接cv就可以了为什么还要摘出首字母来呢
上面举了文件名作为例子其实命名规范充斥在所有程序员的每一项工作中比如变量命名、函数命名、类命名、接口命名以我之见严格遵循命名规范是编程的第一步必须使用翻译的英文来命名英文就是一个字典至少大部分的英文通过翻译之后还是能够准确地知晓其含义的这里面错误的概率远远低于以上几种方式
三号屎山–组件不拆分
危害程度⭐️⭐️⭐️⭐️⭐️ Vue将template、script、style组合在一个.vue文件中这天然就会使得每一个.vue文件的行数会非常多难以维护Vue2中一个最明显的屎山就是几千行、甚至上万行的代码用专业的术语来讲就是不符合单一职责原则一个组件应该只干一件事情一个函数应该只处理一个逻辑剩下的逻辑交给其他函数或者组件来做时刻牢记“SOLID”原则是远离屎山的第一心法 前面通用屎山已经堆积到一定高度接下来再加大马力看看template屎山、script屎山和style屎山。
四号屎山–复杂的表达式
危害程度⭐️⭐️⭐️ divclassfiles:class{ disabled: !isAllowRead hasNotPassed aaa (bbb || ccc) }clicktoDetail()a/b v-if!isAllowRead hasNotPassed aaa (bbb || ccc)//div看这一段代码为了判断一个禁用状态使用了大量的运算符导致逻辑不清晰并且遇到相似的逻辑在下面b组件上不得不ctrl cv妥妥地变成了cv工程师这里正确的做法是应该放到计算属性里面去进行判断并且根据后面所使用到的逻辑进行计算属性的拆分 divclassfiles:class{ disabled: isFileDisabled }clicktoDetail()a/b v-ifisFileDisabled//divscriptexport default {// 此处省略...computed: {isFileDisabled(){return !isAllowRead hasNotPassed aaa (bbb || ccc)}}}/script当然isFileDisabled这个计算属性也可以拆分成多个这个主要看后续的复用情况所以二号屎山的优化方案就是利用计算属性或者拆分计算属性
五号屎山–大量重复节点
危害程度⭐️⭐️⭐️
templatedivspan姓名:{{ name }}/spanspan年龄:{{ age }}/spanspan性别:{{ gender }}/spanspan身高:{{ height }}/spanspan体重:{{ weight }}/spanspan爱好{{ habit }}/span/div
/template优化后的代码 divspan v-foritem in textConfigs :keyitem.valueKey{{response[item.valueKey]}}/span/divdata() {return {textConfigs: [{ label: 性别, valueKey: name },{ label: 年龄, valueKey: age },{ label: 性别, valueKey: gender },{ label: 身高, valueKey: height },{ label: 体重, valueKey: weight },{ label: 爱好, valueKey: habit }]};},可能有些同学认为这个不算是屎山代码但是当这个span变得复杂起来之后甚至这个span里面包含了几十行代码的时候就会发现这里面的重复元素太多了进而无法维护
六号屎山–if else switch
危害程度⭐️⭐️
if(!values.username){this.$message.error(用户名不能为空)
} else if(!values.password){this.$message.error(密码不能为空)
} else if(!values.phoneNumber){this.$message.error(手机号不能为空)
} else {this.submit();
}
可能有人会说上面的代码语义明确写得还不够好吗但是如果需要增加更多的校验条件时开发者不得不侵入到具体方法去修改代码使用策略模式优化之后能够让校验条件与具体判断逻辑解耦当需要增加校验条件时直接修改数组即可
const validators [{ message: 用户名不能为空, required: true, key: username },{ message: 密码不能为空, required: true, key: password },{ message: 手机号不能为空, required: true, key: phoneNumber }
];export default {methods: {validator(values) {const result validators.some(el {if (el.required !values[el.key]) {this.$message.error(el.message);return true;}});return result;},submit(values) {if (this.validator(values)) {return;}// ... 调用接口}}
};七号屎山–后端参数处理
危害程度⭐️⭐️⭐️ handleParams() {const params {};params.id this.formItem.id;params.startDate this.formItem.startDate.format(YYYY-MM-DD);params.endDate this.formItem.endDate.format(YYYY-MM-DD);params.price this.formItem.price.toString();params.type this.formItem.type;params.total this.formItem.total;params.name this.formItem.name;params.comment this.formItem.comment;// ... 此处省略一万行代码}看到这样的代码内心是崩溃的明显只有几个字段需要处理一下却把所有字段都赋值了一遍可以这样简化 handleParams() {const { startDate, endDate, price, ...params } this.formItem;params.startDate startDate.format(YYYY-MM-DD);params.endDate endDate.format(YYYY-MM-DD);params.price price.toString();// ... 此处省掉一万行代码}八号屎山–硬编码
危害程度⭐️⭐️⭐️⭐️
computed: {isGood() {return this.type 1;},isBad() {return this.type 0;}}看上面的例子这种硬编码基本随处可见作者在写这段代码的时候肯定是觉得这个type只会在这里用到没有必要单独定义一个常量来管理后面接收的同学来了他也不会去关注之前的逻辑他只要用到了type又会去重新判断一下是good还是bad就这样最后代码中充斥着0,1,2,3这样的数字后来新人接到一个需求并且涉及到这些数字背后的含义这个时候就不得不去一个一个地询问原作者了好的做法就是写成常量配置文件单独写一个文件config.js然后组件去引用这个常量:
// 货物的品质枚举值
export const GOODS_TYPE {good: 1, // 质量好bad: 0 // 质量差
};九号屎山–Mixins屎山
危害程度⭐️⭐️⭐️
我不生产代码我只是Mixins的搬运工
// a.mixin.js
export default {data() {return {username: ,password: ,age: 18};},created() {this.fetchUserInfo();},methods: {fetchUserInfo() {}}
};// b.mixin.js
export default {data(){return {height:,weight:}},created(){this.fetchBodyFat();},methods:{fetchBodyFat(){}}
}// c.vue
const DEGREEMAP {doctor:博士
}
export default {mixins:[a,b],data(){return {degree:DEGREEMAP.doctor}},created(){this.log()},methods:{log(){if(this.age 30 this.height180 this.degreeDEGREEMAP.doctor){alert(真牛)}}}
}
这里a、b提供了一些数据最后统一在c.vue中使用这样的话容易造成变量覆盖以及来路不明等问题如果必须使用vue2的话这种情况是避免不了的只能尽量减少组件对mixins中data的耦合度但是最近看到一篇文章打开了新的思路有兴趣的可以读一读我可能发现了Vue Mixin的正确用法——动态Mixin
十号屎山–无用代码不删除
危害程度⭐️⭐️ 大段注释不删除没用的methods也不注释本着多一事不如少一事的原则因为Vue中父组件调用子组件方法比较常见因此有些方法不使用了自己也不去注释或者删除害怕引发其他bug或者干脆就不管直接写一个其他名称的方法 无用的文件不删除比方说开始定义了一个list.vue,后面这个文件重构了直接增加了一个List.vue,目录中同时存在这两个文件让人摸不着头脑无形增加了项目复杂度试想一下如果一个超大项目一半的文件都是没有引用到的那是多么的可怕!
十一号屎山–类名无规范
危害程度⭐️
将id驼峰、横线、下划线结合使用
#id{}
#App{}
.AppBuy{}
.app-buy{}
.app_buy{}
.App_Buy{}好的css是有一定的规范的禁止使用id选择器、!important类名用横线分割或者参考BEM规范
十二号屎山–样式大量重复
危害程度⭐️
.a{display:flex;align-items:center;justify-content:center;
}
.b{display:flex;align-items:center;justify-content:center;font-size:16px;color:red;
}
十三号屎山–不写注释
危害程度⭐️⭐️⭐️⭐️⭐️ 写个注释是举手之劳花不了多少时间而且前面所有的屎山堆起来如果有注释的话还是可以快速理解其含义的但是如果再加上不写注释那就是天坑了谁也救不了这个屎山 罗马的道路不是一日铺成的屎山的代码也不是一天写成的而是在每个开发者无所谓的心态下堆成的如果平时多注意注意至少也能保证自己写的代码”留有余香“。 建议读完本文之后再读一读参考文章最后是严格地执行如果以时间不够为借口而不执行那么看再多的文章也没有用
十四号屎山–组件不写name
危害程度⭐️
// temp.vue
templatedivtemp/div
/template
script
export default {};
/script// App.vue
templatediv idappmy-component//div
/template
script
import MyComponent from /components/temp;export default {components: {MyComponent},
};
/script
temp组件不写name然后导入的时候随便设置一个其他的名字在父组件中使用这样在vue-devtools中查看的话组件名为MyComponent如果只有这样一个组件问题不大想一下所有组件都不设置name然后从根组件开始每一层组件都有一个叫Button的组件一个新人接手这个项目了他用devtool打开一看全是Button组件看起来貌似是一样但是其实不一样而且要搞清楚到底对应的代码在哪里还很费时间如果定义了name那么即使改变注册的key组件名也是固定的另外推荐组件名与文件名一致这样大大地降低了组件搜索成本
