第03章：PR驱动开发与高质量Code Review

第03章：PR驱动开发与高质量Code Review

把 PR 变成质量入口，而不是“形式流程”

本章学习目标

  • 理解 PR 的本质：代码审核 + 风险控制 + 合并入口。
  • 掌握高质量 PR 描述写法。
  • 建立可执行的 Review 清单。

一、PR 是什么

PR（Pull Request）本质是：
“请求把某个分支的变更合并到目标分支，并接受团队审查与自动检查。”

PR 不是“通知别人我写完了”，而是团队对变更进行统一评估的机制。

二、一个合格 PR 至少包含

  1. 做了什么（What changed）
  2. 为什么做（Why now）
  3. 怎么验证（How to test）
  4. 风险与回滚（Risk & rollback）
  5. 关联 Issue（Traceability）

三、PR 模板（可直接复用）

## 背景
- 关联 Issue: #123
- 目标: 解决 xxx / 新增 xxx

## 变更内容
- [ ] 功能 A
- [ ] 重构 B
- [ ] 文档更新

## 测试说明
- 本地: lint/test/build 全通过
- 手工验证:
  - [ ] 场景1
  - [ ] 场景2

## 风险与回滚
- 风险点:
- 回滚方案: revert PR / 回退到 tag vX.Y.Z

四、Review Checklist（重点看行为与风险）

  • 业务逻辑是否符合需求与验收标准？
  • 是否引入回归风险（边界、异常、兼容）？
  • 测试是否覆盖关键路径和失败场景？
  • 是否有安全问题（权限、输入校验、敏感数据）？
  • 代码是否可维护（命名、结构、重复、复杂度）？

五、小步提交的价值

好的 commit 应做到：

  • 单一职责：一次只做一件事。
  • 语义清晰：看到 message 就知道目的。
  • 可回滚：出现问题可以精准回退。

推荐 Conventional Commits：

  • feat: 新功能
  • fix: 修复
  • refactor: 重构
  • test: 测试
  • docs: 文档

六、PR 反模式

  • “超大 PR 一把梭”：阅读成本极高，review 质量下降。
  • “只有代码，没有解释”：reviewer 无法判断意图。
  • “CI 红了先合再说”：把风险转移到线上。
  • “评论不闭环”：讨论未解决就合并，埋下隐患。

七、落地动作

  • 仓库开启 PR 模板。
  • 设定最小评审门槛（至少 1 人 + 所有 checks 通过）。
  • 每周复盘 2 个高风险 PR，沉淀团队经验。