Review 流程

这一课你将能做到

1. 把 PR 控制在「可审查」的大小范围内，并说服作者拆 PR
2. 设计团队的 Review 节奏：谁来审、多久审完、什么情况可以合并
3. 用 CI、分支保护、模板等工具把流程固化下来

为什么要学

Code Review 最常见的失败不是「审不出问题」，而是「流程烂到没人想审」——PR 堆三天没人看、1000 行变更 reviewers 直接 LGTM、紧急情况绕过 review 直接上 master。

人话：流程对了，review 才有意义；流程不对，review 就是走形式。

先建立图像

健康的 Review 节奏

作者                    系统                     Reviewer
 │                       │                         │
 ├─ 提交 PR（<400 行）──→│                         │
 │                       ├─ CI 跑测试/Lint ────────→│ 收到通知
 │                       │   （5 分钟内出结果）      │
 │                       │                         ├─ 24h 内开始审
 │                       │                         ├─ 一次性给完反馈
 │  ←── 需要修改 ────────┤                         │
 ├─ 修改并 push ────────→│                         │
 │                       ├─ CI 重跑 ──────────────→│ 复审（只看改动）
 │                       │                         ├─ Approve
 │  ←── 自动合并 ────────┤                         │

关键指标：
- PR 平均大小：< 400 行变更
- 首次响应时间：< 24h（工作时间）
- 从提交到合并：< 48h

跟着做

步骤 1：控制 PR 大小

❌ 反例：1000+ 行的「史诗 PR」

feat: 课程模块完整实现
- 新增 CourseController（300 行）
- 新增 CourseService（500 行）
- 新增 CourseMapper + XML（200 行）
- 新增 DTO 15 个
- 修改 UserService（100 行）
- 修改配置文件
- 新增测试（500 行）

reviewer 看到这种 PR 的真实反应：拉到最下面，点个 Approve。

✅ 正例：拆成 5 个小 PR

PR 1: feat(course): 新增课程领域模型与 Mapper（200 行）
      只含 Entity + Mapper + 单测，不含业务逻辑

PR 2: feat(course): 课程 CRUD Service 层（250 行）
      依赖 PR 1，含 Service + 单测

PR 3: feat(course): 课程 Controller + DTO（300 行）
      依赖 PR 2，含接口层 + 集成测试

PR 4: feat(course): 课程搜索与筛选（200 行）

PR 5: refactor(user): 抽离用户权限判断供课程模块使用（100 行）

每个 PR 独立可审、独立可合、独立可回滚。

审查动作：看到 >500 行的 PR，第一反应是问「能不能拆」。

步骤 2：写 PR 描述

❌ 反例：

修改课程相关代码

✅ 正例：用模板

## 改动说明
新增课程发布功能：讲师可将草稿课程发布为正式课程，
发布后 C 端可见，同时触发搜索索引更新。

## 影响范围
- 新增接口 `POST /api/v1/courses/{id}/publish`
- 修改 `CourseService.publish()`（新增方法）
- 新增 Outbox 事件 `course.published`

## 测试
- [x] 单元测试：CourseServiceTest 新增 3 个用例
- [x] 集成测试：CourseServiceIT 覆盖并发发布场景
- [x] 本地手动验证：发布 → 搜索可见 → C 端列表出现

## 注意事项
- 依赖 PR #123（课程领域模型）先合并
- 上线后需配置 ES 索引别名