团队还在人肉Code Review？这套自动化规范方案让你准时下班-优快云博客

你是不是也遇到过这些抓狂瞬间？

新人提交的代码风格千奇百怪，缩进用空格和tab的混用，分号时有时无。Code Review时都在纠结格式问题，根本没空关注真正的逻辑缺陷。更崩溃的是，有人把调试用的console.log提交到了生产环境…

别急，今天我就带你用三件套彻底解决这些问题。看完本文，你会获得一套开箱即用的前端规范方案，让你的团队代码质量瞬间提升，再也不用为格式问题吵架了！

为什么需要自动化规范？

先说说手动维护规范的痛点。靠人肉检查代码规范，就像让交警一个个检查每辆车的轮胎气压——效率低还容易漏检。

我们团队之前就吃过亏。有个小伙伴不小心把未定义的变量提交到了主干，导致线上页面白屏整整半小时。自从上了自动化方案，这种低级错误再也没出现过。

最重要的是，把格式检查交给工具后，团队可以把更多精力放在架构设计和业务逻辑上，Code Review效率直接翻倍。

基础配置：ESLint + Prettier黄金组合

先来安装最重要的两个依赖：

# 安装基础依赖
npm install --save-dev eslint prettier eslint-config-prettier

ESLint负责找代码中的问题，Prettier负责格式化。他俩各司其职，配合起来天衣无缝。

接下来配置.eslintrc.js，这是我们的核心规则集：

module.exports = {
  env: {
    browser: true,
    es2021: true
  },
  extends: [
    'eslint:recommended',
    'prettier' // 重要！必须放在最后，避免规则冲突
  ],
  parserOptions: {
    ecmaVersion: 12,
    sourceType: 'module'
  },
  rules: {
    // 自定义规则：禁止使用console.log
    'no-console': 'error',
    // 强制使用全等
    'eqeqeq': ['error', 'always'],
    // 变量必须先声明后使用
    'no-undef': 'error',
    // 其他自定义规则...
  }
};

然后配置.prettierrc，定义代码格式标准：

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2,
  "endOfLine": "auto"
}

现在试试效果！在package.json里添加格式化脚本：

{
  "scripts": {
    "lint": "eslint src --ext .js,.jsx,.ts,.tsx",
    "lint:fix": "eslint src --ext .js,.jsx,.ts,.tsx --fix",
    "format": "prettier --write src/**/*.{js,jsx,ts,tsx,css,md}"
  }
}

运行npm run lint:fix就能自动修复问题，npm run format可以格式化代码。是不是很简单？

Git Hooks：把问题扼杀在提交前

配置好了检查工具，怎么确保每个人都会用呢？答案就是Git Hooks！

手动检查靠自觉，但Husky能确保每次提交都自动检查。这就像给代码提交加了安检门，不合格的根本过不去。

安装配置很简单：

npm install --save-dev husky lint-staged

然后在package.json里配置：

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{css,md}": [
      "prettier --write"
    ]
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "echo '校验commit message格式'"
    }
  }
}

这样配置后，每次git commit时都会自动触发代码检查和格式化。只有通过检查的代码才能成功提交。

我还推荐配置commit message规范，使用commitlint：

npm install --save-dev @commitlint/cli @commitlint/config-conventional

创建commitlint.config.js：

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    // 提交信息必须以feat/fix/docs等开头
    'type-enum': [2, 'always', [
      'feat', 'fix', 'docs', 'style', 'refactor', 
      'test', 'chore', 'revert'
    ]]
  }
};

这样每次提交的message都有统一格式，生成CHANGELOG时特别方便！

CI集成：最后一道防线

虽然Husky能在本地拦截问题，但有些人可能会绕过检查（比如用–no-verify）。这时候就需要CI/CD流水线作为最后一道防线。

我们在GitHub Actions中配置（其他CI工具类似）：

创建.github/workflows/ci.yml：

name: Code Check
on: [push, pull_request]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Setup Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '16'
    - name: Install dependencies
      run: npm ci
    - name: Run ESLint
      run: npm run lint
    - name: Run tests
      run: npm test
    - name: Check build
      run: npm run build

这样配置后，每次推送代码或提PR都会自动运行检查。如果ESLint报错或者测试失败，CI就会显示失败，阻止合并代码。

对于我们团队，还在CI中加了代码覆盖率检查：

- name: Check coverage
  run: |
    npm run test:coverage
    # 检查覆盖率是否达到预设阈值
    npx coverage-check --lines 80 --functions 80 --branches 70

这样就确保了测试质量，不会有人提交未经测试的代码。

高级技巧：自定义规则和共享配置

团队规模大了之后，可能需要更精细的规则控制。比如我们禁止直接操作DOM：

// custom-eslint-rules.js
module.exports = {
  rules: {
    'no-direct-dom-manipulation': {
      create: function(context) {
        return {
          CallExpression: function(node) {
            if (node.callee.property && 
                ['innerHTML', 'appendChild'].includes(node.callee.property.name)) {
              context.report({
                node: node,
                message: '禁止直接操作DOM，请使用框架提供的方法'
              });
            }
          }
        };
      }
    }
  }
};

然后在ESLint配置中引用：

// .eslintrc.js
const customRules = require('./custom-eslint-rules');

module.exports = {
  // ...其他配置
  rules: {
    ...customRules.rules,
    // 其他规则...
  }
};

对于多项目团队，建议创建共享配置包：

# 创建共享配置包
mkdir eslint-config-myteam
cd eslint-config-myteam
npm init

创建index.js：

module.exports = {
  extends: ['eslint:recommended', 'prettier'],
  rules: {
    // 团队统一规则
    'no-console': 'error',
    'eqeqeq': ['error', 'always']
  }
};