代码审查最佳实践：如何给予和接收反馈

代码审查能提升质量、分享知识，并在代码进入生产环境前捕获错误。

审查者清单

正确性

• 代码是否实现了其声称的功能？
• 是否处理了边界情况（null、空值、溢出）？
• 错误路径是否正确？
• 逻辑对所有输入是否都正确？

设计

• 改动是否放在正确的位置？
• 是否遵循现有模式？
• 是否过于复杂？能否简化？
• 是否违反了 SOLID 原则？

测试

• 是否有足够的测试？
• 测试是否真正验证了行为？
• 边界情况是否被测试？

安全

• 是否存在 SQL 注入、XSS 或注入漏洞？
• 敏感数据是否被记录或暴露？
• 输入是否经过验证和清理？

性能

• 是否存在 N+1 查询问题？
• 数据库查询是否使用了合适的索引？
• 是否在适当的地方使用了缓存？

给予良好的反馈

# 糟糕的反馈
"这段代码是错的"
"你为什么要这么做？"
"我会完全用不同的方式做"

# 良好的反馈
"这可能会导致并发访问问题——考虑在这里使用事务"
"小建议：能否将 `d` 重命名为 `daysSinceLastLogin` 以提高可读性？"
"你觉得把它提取成一个共享工具类怎么样？我们在 UserService 中使用了类似的逻辑"

# 提问而非命令
"如果 user 为 null，这会导致问题吗？"
vs
"如果 user 为 null，这会抛出异常"

接收反馈

• 不要将反馈个人化；它针对的是代码
• 回复所有评论（LGTM、已修改，或解释为何不同意）
• 对模糊的反馈要求澄清
• 可以不同意——解释你的理由

Pull Request 最佳实践

![代码审查最佳实践：如何给予和接收反馈插图](https://images.pexels.com/photos/10942478/pexels-photo-10942478.jpeg?auto=compress&cs=tinysrgb&h=650&w=940)

## 摘要
简要描述更改了什么以及为什么。

## 变更
- 添加了 `PaymentService` 以处理 Stripe 集成
- 重构了 `OrderController` 以使用新服务
- 为支付失败场景添加了单元测试

## 测试
- [ ] 单元测试通过
- [ ] 使用 Stripe 测试模式的集成测试
- [ ] 结账流程的手动测试

## 截图（如果涉及 UI 变更）

自动化以减少审查负担

# .github/workflows/pr-checks.yml
- name: Lint
  run: npm run lint

- name: Type check
  run: npm run typecheck

- name: Tests
  run: npm test

- name: Bundle size check
  run: npm run build && npx bundlesize

审查周转时间

• 审查者：目标在 1 个工作日内完成审查
• 作者：在 1 个工作日内回复反馈
• 小型 PR：更容易审查（目标少于 400 行）
• 过时 PR：在回复完所有评论后重新请求审查

良好的代码审查是协作对话，而非把关。