构建统一的代码风格及代码检查工作流，提升前端应用质量与代码可维护性背景
对于多人参与的中大型前端项目，代码质量与代码风格的重要性不言而喻，对于开发者而言，当你重构或者接手别人工作时，都期望是一目了然的舒爽，而不是令人头晕眼花的"shi shan"。对于团队而言，良好的代码质量可以减少产品的缺陷，一致的代码风格能够提升团队开发效率。
那么，如何去保障团队代码质量和风格，或者说，通过一种友好，高效，不带来额外负担的自动化方式去落地，笔者在此分享一下自己的实践，可在代码保存时，代码提交时，代码打包时三个阶段去采用不同的手段进行检查/管控，目的是实现一种自动化的代码检查工作流。
插件介绍
插件安装/配置一次即可，插件详情可自行baidu
”eslint“: javascript代码检测工具 ”eslint-plugin-vue“：针对vue的eslint插件 "stylelint": css检测工具 "stylelint-config-standard": stylelint的推荐配置 "stylelint-order": css属性排序插件，合理的排序加快页面渲染 "stylelint-scss": 增加支持scss语法
第一关，保存时：vscode插件eslint stylelint
解决痛点：ide保存时自动格式化代码，省时省力高效
编辑器安装插件后能够读取eslint/stylelint配置文件并对不符合规范的地方出现红色的波浪线提示；可配置ctrl s 保存时自动格式化当前文件js和css部分，但是错误无法自动修复，如定义一个变量并未使用。
代码语言：txt复制vscode编辑器设置：
vscode setting.json
{
"eslint.format.enable": true,
//保存时进行格式化
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true,
"source.fixAll.stylelint":true
},
//自动格式化粘贴的代码
"files.autoSave": "afterDelay"
}第二关，提交时： husky lint-staged eslint/stylelint --fix
解决痛点：不用跑CI流水线时才发现代码问题，把问题暴露在本地提交之前
代码语言：txt复制 安装：npm install husky lint-staged --save -devhusky插件（需要nodejs 10.6以上）能够设置git钩子，在你commit之前执行相关脚本
代码语言：txt复制 "husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},lint-staged插件能够只针对git add加入到stage区域的文件进行扫描，这样每个人只对自己要提交的增量代码进行扫描及修复
代码语言：txt复制 "lint-staged":{
"*": [
"stylelint --fix",
"eslint --fix"
]
},通过husky和lint-staged配合，每次commit时对进行检查及自动格式化，如果有无法自动修复的错误，会停止commit, 可以在底部output处看到错误发生位置，进行手动修复并再次提交
为什么不全量扫描？
- 如果维护的是一个老项目，或者项目一开始没有引入代码检查，则突然进行全量检查时会报大量的错误
- 每个人只去负责改动自己的代码，以免影响其他部分，随着项目推进，只要被改到的代码都会被检查到。
- 建议在项目早期安排专人进行全量扫描并全盘修复一次，之后只需要进行增量代码进行扫描。第三关，打包时：CI流水线增加代码扫描流水线加入sonar代码扫描并设置阈值阻断
存在问题：
1、需要执行流水线才能发现问题。
2、sonar已有规则与eslint规则不完全一致（能否一致？），目前流水线中是执行eslint检查并将结果输出上传到sonar平台进行展示，而没有采用sonar规则检查
3、实际上，提交代码能通过前两关，第三关是不会再有错误的，可以去掉了。
总结:
1、只要能实现1，2关的都应采用，高效优雅，且不用浪费CI资源。
2、无法实现的老旧项目，使用第三关行代码质量检测及管控。
3、本文侧重提供一将代码检查及管控融入工作流的实践思路及方法，对于所提到的各个插件不够清楚的可自行baidu，不同技术栈也会有所差别。
著作权归作者所有。商业转载请联系本账号获得授权，非商业转载请注明原文地址。
