在多人协作开发时，统一代码的规范性不可或缺。
笔者有幸在大学毕业时带领团队对老旧项目进行了重构，并推动了代码规范、CodeReview 等。从而提高了代码质量和可维护性。在这里记录下之前的一些实践经验。
如果你对完整的项目配置感兴趣，可以查看 github 仓库中的vue3-vite-starter项目中找到。
prettier只会对代码的格式进行检查和修复。但有时候，我们需要对其 js/css 等语法进行校验，就需要用eslint和stylelint。
同时这里强烈建议使用统一的 IDE VSCode（如果官网下载很慢，尝试修改源），方便统一插件和settings.json配置
安装依赖：
yarn add eslint eslint-plugin-vue @typescript-eslint/parser @typescript-eslint/eslint-plugin -D-
eslint: ESLint 的核心代码
-
eslint-plugin-vue：ESLint 关于检测 vue 代码规范的插件
-
@typescript-eslint/parser：ESLint 的解析器，用于解析 typescript，从而检查和规范 Typescript 代码
-
@typescript-eslint/eslint-plugin：这是一个 ESLint 插件，包含了各类定义好的检测 Typescript 代码的规范
安装完依赖后添加.eslintrc.js和.eslintignore配置文件。
最后在VSCode的扩展程序中安装ESlint，从而在编辑器中直观看到错误提示。
安装依赖：
yarn add stylelint stylelint-config-standard -D-
stylelint: stylelint 的核心代码
-
stylelint-config-standard: stylelint 官方共享的标准规则集成。
安装完依赖后添加.stylelintrc lint 规则。
最后在VSCode扩展程序中安装stylelint，便于在编写样式代码时直观看到报错信息（红色波浪线）。
prettier支持自动格式化多种文件，包括：ts、js、html、json 等。这里我们可以统一用它来格式化。
先安装依赖：
yarn add prettier eslint-config-prettier eslint-plugin-prettier -D-
prettier：prettier 插件的核心代码
-
eslint-config-prettier：解决 ESLint 中的样式规范和 prettier 中样式规范的冲突，以 prettier 的样式规范为准，使 ESLint 中的样式规范自动失效
-
eslint-plugin-prettier：将 prettier 作为 ESLint 规范来使用
prettier会有一套默认的规则，如果你对某些规则不是太满意。可以在项目的根目录中添加.prettierrc文件，对全局配置进行覆盖。比如：prettier默认会在对象末尾添加逗号。如果需要忽略它，你可以在.prettierrc文件中这么做：
{
"trailingComma": "none"
}最后在VSCode中搜索扩展程序Prettier - Code formatter并安装。如果需要在保存代码时，自动格式化代码。可以修改.vscode/settings.json
比如：
{
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
}
}为防止忘记对代码执行 lint 的情况，我们可以修改 git hooks 的钩子函数，在提交代码前自动执行一次 lint。
首先安装依赖：
yarn add lint-staged husky -D-
husky: 基于 git hooks 对其暴露的钩子进行修改（如：在 commit 前对所有代码进行 lint 自动校验）
-
lint-staged: 一个在 git 暂存文件上运行 linters 的工具
第一次运行项目时，执行以下命令初始化：
npm set-script prepare "husky install" # 添加script脚本快捷命令
npm run prepare # 执行脚本命令
npx husky add .husky/pre-commit "npx lint-staged"执行完以上命令后，会在项目根目录位置新增.husky文件夹和.husky/pre-commit文件。
.husky/pre-commit
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npx lint-staged接着，我们在根目录新增.lintstagedrc.js文件并编写 lint 内容。
.lintstagedrc.js
module.exports = {
"*.{js,ts,vue}": "eslint",
"*.{vue,less}": "stylelint",
};上面，我们通过一些工具把代码格式进行了统一。
但针对一些变量/函数命名这些规范，却无能为力。所以，团队还需要根据自己的需求打造一套关于代码实现的一些软性规范。下面是我们目前团队的两个规范，用于参考：
记住，一个好的规范一定是每个团队成员都参与进来讨论的结果。
如果你对此毫无头绪，不妨参考一些国内外大厂的一些已有规范。基于此，让每个团队成员展开一场讨论。最终形成属于自己团队的一套规范。
-
dev：开发分支。存储最新的开发代码。
-
master：主分支。一般也是上一个稳定版本的代码分支。
-
feature：功能分支。用于开发新功能使用。一般从最新的 dev 分支 checkout 出来，开发完成后，需合并回 dev 分支。命名如：
feature/test-user -
fix：bug 分支。用于修复 bug 使用。一般从最新的 dev 分支 checkout 出来，开发完成后，需合并回 dev 分支。命名如：
fix/test-user -
hotfix：热修复分支。用于紧急修复线上版本的问题。一般从 master 分支 checkout。当 bug 修复后，需要通过 cherry-pick 分别合并到 master 和 dev 分支。命名如：
hotfix/test-user
commit 提交内容为：tag: 内容描述。tag 内容如下：
-
feat：新功能。
-
fix：修复 bug。
-
perf：针对性能的优化
-
style：样式相关的更改
-
docs：文档修改
-
test：测试代码变更
-
refactor：重构，代码优化
-
ci：CI/CD 流程修改
-
build：打包方式修改
-
chore：杂项，如格式化代码之类的
-
revert：回滚代码
-
release：版本发布
有了 commit 规范后，我们防止出现“111”之类的无意义提交，便于生成CHANGELOG.md。还需要使用工具对每次 commit 的格式进行自动校验。实现如下：
yarn add @commitlint/config-conventional @commitlint/cli -D执行以下命令，在项目根目录新建commitlint.config.js
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js然后在 git 的 commit-msg 钩子中添加该 lint 校验。执行如下命令：
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'执行成功后，会新建.husky/commit-msg文件并添加内容。
commit-msg
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
#--no-install 参数表示强制npx使用项目中node_modules目录中的commitlint包
npx --no-install commitlint --edit "$1"一次正确的提交应该是：
git commit -m 'feat: add user list'如果你想知道更多，请阅读commitlint 文档
有了代码格式和代码命名等的规范，如何保证入库的代码都是完全符合规范的呢？
答案是：CodeReview。
在项目前期，我会建议Reviewer指定为一个同职级同事和前端组长。当自己去Review别人的代码时，你会加深对代码及其规范的理解。而前端组长，则是把控其代码质量的最后一环。
当然，如果希望节省人员 Review 的时间。你可以在 CI 中添加一个 Sonar 检测的步骤。代码提交后，先经过SonarQube对代码进行一次机器审核。通过后，才能指派给对应同学 Review。
CodeReview相关规范可以参考如下：