让团队代码像一个人写的

前端代码规范

一千个读者，有一千个哈姆雷特 一千个程序员，就有一千种代码风格 由于个人喜好、习惯、编码风格各异，因此团队合作中需要统一规范

前端代码规范流程实践思路

1. 本地开发过程，提示、校验、更改
2. Git 提交过程，代码校验是否允许提交
3. 服务端校验，代码校验是否合并和发布

一、开发者本地IDE统一

开发工具统一配置，智能实时提示

以 VS COde 为例， 安装 ESLint，Vetur 等扩展包

规则设置

项目构建时 lint 规则可以继承优秀团队基于最佳实践设定的编码规范，如 airbnb, 这样避免重复造轮子造成人力的资源浪费和规则覆盖的缺陷，继承社区知名代码规范后团队内部再进行细节调整

{
  "extend": ["airbnb-base"],
  "rules": {
    "semi": ["error", "never"]
  }
}

社区知名的代码规范

• eslint-config-airbnb (https://github.com/airbnb/javascript)
• eslint-config-standard (https://github.com/standard/eslint-config-standard)
• eslint-config-alloy (https://github.com/AlloyTeam/eslint-config-alloy)

vue-cli3 脚手架初始化项目时规范选择

可以设置部分 eslint rule 为警告，保障开发体验，并且在 pre-commit 与 CI 中把警告视为不通过，保证严格的代码规范

二、 Git Hooks

团队合作中的编码规范有一点是，虽然自己有可能不舒服，但是不能让别人因为自己的代码而不舒服。

git 自身包含许多 hooks，在 commit，push 等 git 事件前后触发执行。与 pre-commit hook 结合可以帮助校验 Lint，如果非通过代码规范则不允许提交。

husky 是一个使 git hooks 变得更简单的工具，只需要配置几行 package.json 就可以愉快的开始工作。

// package.json
{
  "scripts": {
    "lint": "eslint . --cache"
  },
  "husky": {
    "hooks": {
      "pre-commit": "npm lint",
    }
  }
}

git commit 过程拦截效果

注意： git hooks 的规范校验可以通过 git commit -n 跳过，需要在 CI 层继续加强校验

三、 CI/CD

git hooks 可以绕过，但 CI(持续集成) 是绝对绕不过的，因为它在服务端校验。使用 gitlab CI 做持续集成，配置文件 .gitlab-ci.yaml 如下所示

lint:
  stage: lint
  only:
    - /^feature\/.*$/
  script:
    - npm run test

GitLab pipelines 运行效果

资料参考

常见的几种js代码规范工具

代码质量管理的开源平台Sonar

https://www.sonarqube.org/

前端代码规范（静态检查）工具

前端团队代码规范最佳实践

自动化代码规范工具

由浅入深定制你的代码规范与检查

ESLint

husky

githooks

GitLab Continuous Integration (CI)

GitLab CI/CD