跳到主要内容

代码规范如何落地

场景​

团队代码风格不一致，代码质量参差不齐，如何推动代码规范的制定和执行？

方案设计​

1. 工具链配置​

核心工具链
// eslint.config.mjs (ESLint 9 Flat Config)
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  eslint.configs.recommended,
  ...tseslint.configs.recommended,
  {
    rules: {
      '@typescript-eslint/no-unused-vars': ['error', { argsIgnorePattern: '^_' }],
      '@typescript-eslint/no-explicit-any': 'warn',
    },
  }
);
.prettierrc
{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2
}

2. Git Hooks 强制执行​

package.json
{
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{css,scss}": ["prettier --write"],
    "*.md": ["prettier --write"]
  }
}

3. 推行策略​

阶段做法目标
第一周加工具、只 warn 不 error让大家感知规范
第二周逐步开启 error 规则新代码必须符合
第三周开启 pre-commit hook阻止提交不合规代码
第四周CI 流水线加检查最后一道防线
持续定期 Code Review培养规范意识
注意

不要一次性对存量代码全面开启严格模式，会产生几千个报错打击团队积极性。应该：

  1. 新代码严格执行
  2. 旧代码逐步迁移（lint-staged 只检查 staged 文件）

4. Code Review 规范​

## Code Review 检查项

### 必查项
- [ ] 命名是否语义化
- [ ] 是否有明显的性能问题
- [ ] 是否处理了错误和边界情况
- [ ] 是否有安全风险（XSS、敏感信息）

### 建议项
- [ ] 代码是否可以更简洁
- [ ] 是否可以复用已有组件/函数
- [ ] 是否需要补充注释

常见面试问题​

Q1: 你是如何推动代码规范落地的？​

答案：

  1. 工具先行：配置 ESLint + Prettier + Husky，让规范自动化执行
  2. 渐进式推进：先 warn 后 error，只检查新改动文件
  3. 团队共识：规范不是一个人定的，组织评审让大家参与制定
  4. 持续改进：定期回顾规范是否合理，及时调整

Q2: ESLint 和 Prettier 的关系是什么？冲突怎么解决？​

答案：

  • ESLint：检查代码质量（未使用变量、类型错误等）+ 部分格式规则
  • Prettier：纯格式化（缩进、引号、分号等）

冲突解决：使用 eslint-config-prettier 关闭 ESLint 中与 Prettier 冲突的格式规则，让 Prettier 专管格式。

相关链接​