40

PR Review 方法论

⏱️ 20分钟

PR 多角色审查方法论

为什么需要多角色审查?

单一视角的代码审查容易遗漏问题。通过模拟多个角色的审查,可以更全面地评估代码变更的质量和影响。

Review Roles

1. Product Manager Review

从产品角度审视变更:

  • Business Value: Does this deliver promised value?
  • User Experience: Will users benefit from this change?
  • Strategic Alignment: Does it align with product goals?
  • Feature Completeness: Are all requirements met?
  • Action: Provide directives for maximum impact

2. Developer Review

从开发者角度审视代码质量:

  • Code Quality: Is code clean and maintainable?
  • Standards: Does it follow coding conventions?
  • Performance: Are there efficiency concerns?
  • Scalability: Will it handle growth?
  • Refactoring: Any code that needs improvement?
  • Action: Suggest specific code improvements

3. Quality Engineer Review

从测试角度审视质量保障:

  • Test Coverage: Are all paths tested?
  • Edge Cases: Are boundary conditions handled?
  • Regression Risk: Could this break existing features?
  • Test Quality: Are tests comprehensive and clear?
  • Action: Identify missing tests and scenarios

4. Security Engineer Review

从安全角度审视潜在风险:

  • Vulnerabilities: Any security risks?
  • Data Handling: Is sensitive data protected?
  • Authentication: Are auth checks proper?
  • Input Validation: Is user input sanitized?
  • Compliance: Does it meet security standards?
  • Action: Flag security concerns immediately

5. DevOps Review

从运维角度审视部署和监控:

  • CI/CD Integration: Will builds succeed?
  • Configuration: Are configs properly managed?
  • Infrastructure: Any deployment concerns?
  • Monitoring: Are metrics and logs adequate?
  • Rollback: Can changes be safely reverted?
  • Action: Ensure smooth deployment

6. UI/UX Designer Review

从用户体验角度审视界面:

  • Visual Consistency: Does it match design system?
  • Usability: Is it intuitive to use?
  • Accessibility: Is it accessible to all users?
  • Responsive: Does it work on all devices?
  • Polish: Any rough edges to smooth?
  • Action: Ensure delightful user experience

Review Process

标准化的审查流程:

  1. Read PR description and linked issues

    • 理解变更的背景和目的
  2. Review code changes systematically

    • 逐文件审查,注意上下文
  3. Test functionality locally if applicable

    • 实际运行验证功能
  4. Consider each perspective above

    • 依次用各角色视角审视
  5. Leave constructive feedback

    • 提供具体、可操作的建议
  6. Approve or request changes

    • 做出明确的审批决定

Key Principle

Improvements scheduled for "later" must be addressed NOW!

不要让"以后再改"成为技术债务的借口。

实践建议

审查清单模板

## PR Review: [PR Title]

### Product Perspective

-   [ ] Business value delivered
-   [ ] Requirements met
-   [ ] User experience considered

### Developer Perspective

-   [ ] Code is clean and readable
-   [ ] Follows coding standards
-   [ ] No obvious performance issues

### QA Perspective

-   [ ] Test coverage adequate
-   [ ] Edge cases handled
-   [ ] No regression risks

### Security Perspective

-   [ ] No security vulnerabilities
-   [ ] Input properly validated
-   [ ] Sensitive data protected

### DevOps Perspective

-   [ ] CI/CD compatible
-   [ ] Monitoring in place
-   [ ] Rollback possible

### UX Perspective

-   [ ] Consistent with design system
-   [ ] Accessible
-   [ ] Responsive

让 AI 帮助审查

你可以让 AI 从不同角色视角审查代码:

请从以下角色审查这个 PR:
1. 产品经理 - 关注业务价值
2. 安全工程师 - 关注安全风险
3. 测试工程师 - 关注测试覆盖

[粘贴 PR 代码或链接]

下一步

学习 代码分析选项 了解更多代码质量分析技术。

📚 相关资源

❓ 常见问题

关于本章主题最常被搜索的问题,点击展开答案

为什么单一视角的代码审查不够?

纯 developer 视角容易漏 4 类问题:(1) 业务价值与产品目标对齐(PM 视角);(2) 边界与回归风险(QA 视角);(3) 输入校验与敏感数据保护(Security 视角);(4) CI/CD 兼容、回滚、监控(DevOps 视角)。多角色审查不是流程繁琐,是把这些隐性风险显式拉出来。

本章列了几种审查角色?分别看什么?

六个:(1) PM — Business Value / UX / Strategic Alignment;(2) Developer — Code Quality / Standards / Performance / Refactoring;(3) QA — Test Coverage / Edge Cases / Regression Risk;(4) Security — Vulnerabilities / Auth / Input Validation / Compliance;(5) DevOps — CI/CD / Config / Monitoring / Rollback;(6) UI/UX Designer — Visual Consistency / Usability / Accessibility / Responsive。

「以后再改」为什么是审查里最危险的回答?

本章 Key Principle 直接写:Improvements scheduled for "later" must be addressed NOW。"以后"是技术债务的代名词,PR 合进去那一刻不修就基本不会修。审查里看到要改的点立刻 request changes,比新开 issue 的修复率高一个量级 — issue 平均 lifetime 几周到几月,PR 内反馈是 24 小时。

怎么让 AI 帮我从多角色视角审 PR?

本章直接给了 prompt 模板:"请从以下角色审查这个 PR:1. 产品经理 - 关注业务价值;2. 安全工程师 - 关注安全风险;3. 测试工程师 - 关注测试覆盖",然后粘 PR diff 或链接。每次只挑 2-3 个最相关角色,不要 6 个全上 — 角色越多输出越泛,2-3 个针对性反馈反而具体可操作。

PR 审查清单模板该多长?

本章模板每个角色 3 项 checkbox,6 角色共 18 项。关键不是项数而是「每项可勾选」— Test coverage adequate 是可勾的,Code is good 不是。20 项以上的清单没人认真过,每条都要落到具体行为:CI/CD compatible、Input properly validated、Responsive on mobile,模糊的「Quality is high」一律删掉。