一、误区：混乱是项目变复杂的必然结果
很多团队会这样安慰自己：
- “项目大了，本来就会乱”
- “人多了，不可能统一”
- “先跑起来，规范以后再说”
但现实是：
👉 不是项目变复杂，而是“复杂度没有被约束”
没有规范的项目，演变路径几乎一致：
文件乱放 → 命名混乱 → 提交不可读 → 分支失控 → 不敢改代码
二、工程化视角：规范的本质是“降低协作成本”
规范不是为了“好看”，而是解决三个问题：
- 别人能不能快速理解你的代码
- 多人协作会不会互相干扰
- 问题能不能快速定位和回滚
所以判断规范是否有价值的标准是：
有没有让协作更顺畅，而不是更繁琐
三、最小但有效的 4 个规范（核心）
不需要一堆文档，只要这 4 个做到位，项目就会明显“干净”。
1️⃣ 目录结构：让代码“能被猜到在哪”
很多项目的问题：
- utils 到处都是
- components 什么都放
- 页面 / 逻辑 / 状态混在一起
👉 结果：找代码靠“记忆”
✅ 极简结构（通用前端）
src/
├── pages/ # 页面（路由级）
├── components/ # 通用组件
├── features/ # 按业务划分（推荐）
│ └── user/
│ ├── api.ts
│ ├── store.ts
│ ├── components/
│ └── hooks.ts
├── utils/ # 真正通用的工具
├── services/ # 请求封装
🎯 核心规则
- 优先按“业务”分，而不是按“技术类型”分
- 一个功能的代码尽量放在一起
👉 本质：
让“猜路径”成为可能
2️⃣ Git 提交：让历史“可读、可回滚”
常见问题：
fixupdate改了一下- 一次提交改 20 个文件
👉 结果：Git 记录毫无价值
✅ 极简提交规范（够用版）
feat: 新增用户登录功能
fix: 修复登录接口报错
refactor: 重构用户模块结构
style: 调整样式
🎯 核心规则
- 一句话说明“做了什么”
- 只做一件事（一个提交）
- 可回滚（不要把多个改动混一起）
👉 本质：
Git 是你的“时间机器”，不是备份工具
3️⃣ 分支管理：避免“代码互相污染”
常见混乱：
- 所有人都在 main 上开发
- 分支命名随意
- 合并冲突频繁
✅ 极简分支策略（小团队够用）
main # 稳定可发布
dev # 日常开发
feature/* # 功能开发
fix/* # bug 修复
🎯 核心规则
- 不在 main 上直接开发
- 一个功能一个分支
- 开发完成再合并
👉 示例：
feature/login
fix/user-api-error
👉 本质：
隔离变化，减少冲突
4️⃣ Code Review：保证代码“可控”
很多团队的问题：
- 不 review，直接合
- review 只看“有没有 bug”
- review 变成“挑刺大会”
✅ 极简 Review 规则（高性价比）
只看 3 件事：
① 结构是否清晰
- 文件是否放对位置？
- 有没有乱放 utils？
② 命名是否可读
- 变量名是不是“看名知意”？
- 有没有 a、b、temp 这种？
③ 有没有明显重复代码
- 是否可以抽复用？
- 是否在 copy 改？
🎯 核心原则
Review 不是找错，而是“保证长期可维护”
四、真正的分水岭：规范不是“多”，而是“持续执行”
很多团队失败在：
- 写了一堆规范
- 没人执行
- 三天后全部失效
👉 规范不是“文档”，而是：
每天都在发生的行为约束
五、落地建议（非常关键）
1️⃣ 从“最小规则”开始（不要贪多）
只推这 4 个：
- 目录结构
- 提交规范
- 分支规则
- Review 三点
2️⃣ 用工具“强制执行”
而不是靠自觉：
- commit lint（限制提交信息）
- lint / format（统一代码风格）
3️⃣ 先统一“新代码”，再慢慢治理旧代码
👉 不要一开始就全量重构
六、总结一句话
项目的混乱，不是因为人多，而是因为“没有约束变化的规则”。
规范的价值，不在于“看起来专业”，
而在于：
👉 让项目在持续变化中，依然保持可控
