一、规范总览：为什么需要前端规范？
说实话，我刚入行那会儿，也觉得规范这东西挺烦人的。
「代码能跑不就行了？写那么规矩干嘛？」——这是我当时的真实想法。
直到有一次，我接手了一个离职同事的项目。打开代码一看，好家伙——有的文件用 2 空格缩进，有的用 4 空格，有的甚至混着 Tab 和空格。变量名有拼音、有英文、还有拼音首字母。一个组件写了 2000 行，没有任何注释。
我花了整整三天，才搞清楚那个页面到底在干嘛。嗯，从那以后，我再也不敢说「规范不重要」了。
1.1 前端规范到底解决什么问题？
你想想看，一个团队 5 个人，每个人写代码的习惯都不一样。A 喜欢用单引号，B 喜欢双引号，C 觉得无所谓。合并代码的时候，光格式化冲突就能吵半天。
规范要解决的，说白了就是三个核心痛点：
- 可读性差——代码像天书，新人看不懂，老人不想看
- 维护成本高——改一个功能，要翻遍十几个文件，还怕改出 bug
- 协作效率低——代码风格不统一，Code Review 全在纠结格式问题
我个人的经验是：一个没有规范的团队，前三个月可能还能靠默契撑着。一旦项目超过 6 个月、人数超过 5 人，代码质量就会断崖式下跌。
1.2 规范能带来哪些实际收益？
别把规范想成「束缚」。它其实是给团队装了个「自动驾驶」。
| 痛点 | 没有规范 | 有规范 |
|---|---|---|
| 代码风格 | 每个人各写各的，合并时大量冲突 | 统一风格，格式化自动处理 |
| 命名方式 | 变量名随意，猜不出含义 | 见名知意，降低理解成本 |
| 组件设计 | 一个组件干所有事，复用性极差 | 职责单一，易于组合和测试 |
| 代码审查 | Review 全在纠结格式和命名 | Review 聚焦逻辑和架构 |
| 新人上手 | 需要大量时间适应团队风格 | 按规范写，快速融入 |
我在项目中遇到过最典型的例子：一个老项目，没有 ESLint，没有 Prettier，没有命名规范。后来我们花了两个迭代，专门做「规范落地」。结果呢？Bug 率下降了 40%，新功能开发速度提升了 30%。
1.3 规范的落地策略
很多团队不是不想搞规范，而是「搞不动」。我见过最惨的案例：leader 拍脑袋定了一套规范，发到群里让大家执行。结果一周后，没人记得这事了。
为什么会这样？因为规范落地，不是「发个文档」就完事了。它需要一套完整的策略。
策略一：工具先行，人治为辅
别指望靠「自觉」来执行规范。人都是懒的，我也不例外。
正确的做法是：用工具把规范「固化」到开发流程里。
// 举个例子，用 ESLint + Prettier 自动格式化
// 提交代码前自动检查，不通过就不让提交
// .eslintrc.js
module.exports = {
extends: ['eslint:recommended', 'plugin:react/recommended'],
rules: {
'no-unused-vars': 'error',
'react/prop-types': 'warn',
},
}
// 配合 husky + lint-staged，在 pre-commit 时自动检查
// package.json
{
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"]
}
}小技巧：我建议在项目初始化时就配好这些工具。如果项目已经跑了一半，也别怕，可以分模块逐步引入。我曾经在一个 20 万行的老项目里，花了两周时间，一个模块一个模块地加规范检查，最后全量覆盖。
策略二：渐进式推行，别搞「一刀切」
最忌讳的就是：某天突然宣布「从明天起，所有人必须按新规范写代码」。
结果呢？老代码改不动，新代码又和老代码风格不一致，反而更乱了。
我建议分三步走：
- 第一步：定基线——先统一格式化工具（Prettier），保证代码外观一致
- 第二步：加规则——逐步引入 ESLint 规则，从 warning 开始，慢慢升级到 error
- 第三步：建文化——通过 Code Review 和分享会，让规范变成团队共识
注意：千万不要在项目中期突然改所有文件的缩进风格。我曾经见过一个团队，把整个项目的 2 空格改成 4 空格，结果 git 历史全乱了，Code Review 根本没法做。这种「格式化大扫除」，最好只在项目初始化时做一次。
策略三：文档要「活」，不要「死」
很多团队的规范文档，写完之后就躺在 Wiki 里吃灰。没人看，也没人更新。
我个人的习惯是：把规范文档放在项目仓库里，和代码一起维护。
// 项目根目录下建一个 docs/ 文件夹
// 里面放规范文档，比如：
docs/
├── 01-命名规范.md
├── 02-组件设计规范.md
├── 03-状态管理规范.md
└── 04-代码提交规范.md
// 然后在 README.md 里加个链接
// 新人来了，第一件事就是看这个文档而且，文档要定期更新。每次 Code Review 时发现的新问题，都可以补充到规范里。这样规范才是「活的」，而不是一纸空文。
1.4 规范落地的「避坑指南」
讲几个我踩过的坑，希望能帮你少走弯路。
- 坑一：规范太细，执行不下去——比如「变量名必须 3-20 个字符」，这种规则没人记得住。规范要「少而精」，先抓大放小。
- 坑二：只定规范，不配工具——没有自动化检查，全靠人工 Review，效率极低。工具能做的，别让人做。
- 坑三：规范是「老大说了算」——团队规范应该是大家讨论出来的，不是某个人拍脑袋定的。我建议开个「规范讨论会」，每人提 3 条最在意的规则，然后投票决定。
- 坑四：忽略历史代码——老代码不改，新代码按规范写，结果新旧混在一起更乱。我建议给老代码一个「缓冲期」，逐步重构。
总结一下：规范不是目的，而是手段。它的最终目标是让团队更高效、代码更健壮、协作更顺畅。别为了规范而规范，要为了「解决问题」而规范。
好了，第一章就聊到这儿。下一章我们会深入聊聊「命名规范」——说实话，这是前端规范里最基础也最容易出问题的一环。到时候我会分享一些我踩过的命名坑，保证让你有共鸣。