聊聊如何保障前端代码质量和代码风格

构建统一的代码风格及代码检查工作流，提升前端应用质量与代码可维护性背景

对于多人参与的中大型前端项目，代码质量与代码风格的重要性不言而喻，对于开发者而言，当你重构或者接手别人工作时，都期望是一目了然的舒爽，而不是令人头晕眼花的"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部分，但是错误无法自动修复，如定义一个变量并未使用。

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流水线时才发现代码问题，把问题暴露在本地提交之前

 安装：npm install husky lint-staged --save -dev

husky插件（需要nodejs 10.6以上）能够设置git钩子，在你commit之前执行相关脚本

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },

lint-staged插件能够只针对git add加入到stage区域的文件进行扫描，这样每个人只对自己要提交的增量代码进行扫描及修复

 "lint-staged":{
     "*": [
       "stylelint --fix",
       "eslint --fix"
     ]
  },

通过husky和lint-staged配合，每次commit时对进行检查及自动格式化，如果有无法自动修复的错误，会停止commit, 可以在底部output处看到错误发生位置，进行手动修复并再次提交

为什么不全量扫描？

1. 如果维护的是一个老项目，或者项目一开始没有引入代码检查，则突然进行全量检查时会报大量的错误
2. 每个人只去负责改动自己的代码，以免影响其他部分，随着项目推进，只要被改到的代码都会被检查到。
3. 建议在项目早期安排专人进行全量扫描并全盘修复一次，之后只需要进行增量代码进行扫描。第三关，打包时：CI流水线增加代码扫描流水线加入sonar代码扫描并设置阈值阻断

存在问题：

1、需要执行流水线才能发现问题。

2、sonar已有规则与eslint规则不完全一致（能否一致？），目前流水线中是执行eslint检查并将结果输出上传到sonar平台进行展示，而没有采用sonar规则检查

3、实际上，提交代码能通过前两关，第三关是不会再有错误的，可以去掉了。

总结:

1、只要能实现1，2关的都应采用，高效优雅，且不用浪费CI资源。

2、无法实现的老旧项目，使用第三关行代码质量检测及管控。

3、本文侧重提供一将代码检查及管控融入工作流的实践思路及方法，对于所提到的各个插件不够清楚的可自行baidu，不同技术栈也会有所差别。

著作权归作者所有。商业转载请联系本账号获得授权，非商业转载请注明原文地址。