拉取请求审查
Source: Dev.to
你应该进行 PR 评审吗？
当然。
两层级评审流程
在 Software Engineering at Google 中，他们描述了一个两层级的评审流程：
- 语言评审 – 关注语言的使用，确保一致性和共享语义。
- 功能实现评审 – 检查功能的正确性和设计。
有时同一个人可以兼顾两个层级（例如，同时是 Python 审批组成员的工程师）。
目标是让代码库中的语言使用保持一致，补充自动化的 lint 工具。
人工评审的挑战
一位 Google 工程师曾报告说，一个 PR 被卡了整整一个月。设计阶段提出的反馈基本被忽视，但在 PR 提交时，许多评审者却给出了非常具体的意见。这凸显了时间点和期望会产生摩擦。
自动化人类难以处理的部分
Lint、Prettify 等
如果你使用 GitHub，可以通过 GitHub Actions 设置 lint、格式化（如 Prettier）以及类型检查（针对动态类型语言）。半天的工作就足以：
- 添加这些 Action，
- 将它们设为必需检查，
- 保护主分支。
你还可以采用一套风格指南来处理需要判断的决定（例如，在 Python 中何时避免列表推导式，或何时即使函数技术上只做“一件事”也要拆分）。将这些约定文档化可以避免在每个 PR 中重复讨论。
测试与测试覆盖率
为 PR 添加以下检查：
- 测试执行 – PR 必须通过所有测试。
- 覆盖率指标 – 追踪代码库被测试覆盖的程度。
最初，只在测试失败时阻止 PR，并收集覆盖率数据。随后，引入一个低覆盖率阈值并逐步提升。此类自动化减少了对显而易见的正确性问题进行人工审查的需求。
手动评审不该是什么
在许多组织中，缺乏自动化工具会导致出现类似 “分支受保护，必须有人批准 PR” 的规则。搭建自动化通常只需几天，但团队可能因为不熟悉或想快速交付而跳过。用人工关卡取代自动化恰恰是降低交付速度的做法。
手动评审 不应 成为所有本可以自动化的检查的“兜底”。只要可以自动化，就去实现；代码贡献是应用的血液，所以应优先考虑提升流畅性的自动化。
手动评审应关注的内容
手动评审属于 无形 的范畴——它是为作者提供 思考伙伴 的机会。正如 Simon（前同事）所说：
“你在提供上下文、经验和建议，帮助作者得到一个优秀的答案……这不是关于正确性，而是引导作者考虑他们可能未曾想到的权衡，同时赋予他们最终决定的权力。”
这与 Dawna Markova 在 Collaborative Intelligence 中提出的 “思考伙伴” 概念相呼应。
给评审者的引导性问题
- 变更是否体现了预期的权衡？
- 代码是否易读、易维护，并对未来的贡献者友好？
- 它是否在复杂度与正确性之间取得了恰当的平衡？
这些讨论是 交流，而非正式的变更请求。它们帮助作者确认或重新评估自己的决定。
当评审者带来历史背景——对子系统的了解、用户反馈或支持经验——评审就会成为一次强有力的知识共享时刻。相反，缺乏业务背景的评审者可能会揭示隐藏的假设（例如 “我们一直都是这么做的”），促使作者重新思考。
更广泛的影响
如果审慎进行，PR 评审可以成为：
- 知识共享的渠道，
- 整个组织技能提升的手段，
- 构建关系和决策能力的练习。
它们从守门人转变为协作改进。你的经验可能不同，这本身就很有价值——欢迎分享你的观点。关键是把 PR 评审视为 有意图、具战略性的实践，而不是事后才想到的事。