我在10年的时间里审查了数千个拉取请求。模式出奇的一致——相同类型的问题一次又一次地出现，无论语言、框架或开发者的经验水平。
我实际关注的内容
忘掉那50项的教科书代码审查检查表。在实际操作中，我专注于五个能捕捉到90%真实问题的方面：
1. 错误处理
生产事故的首要来源。我会问的问题是：当这个API调用失败时会发生什么？如果数据库宕机呢？如果输入为null呢？如果答案是“崩溃”，那就是一个问题。
2. 边缘情况
空数组、零值、非常大的输入、Unicode字符、并发请求。快乐路径总是有效的。边缘情况是错误存在的地方。
3. 安全性
用户输入直接进入SQL查询、HTML或shell命令。端点缺少身份验证检查。秘密硬编码在源代码中。根据谷歌的代码审查指南，安全问题应该阻止任何PR的通过。
4. 可读性
一个没有写这段代码的人能在30秒内理解它吗？变量名称能够说明其内容。功能只做一件事。注释解释为什么，而不是是什么。
5. 性能（当它重要时）
N+1数据库查询、不必要的重新渲染、大数据集上的O(n²)算法。我不会过早优化，但我会标记明显的性能问题。
审查流程
AI代码审查工具自动化了代码审查的机械部分——检查常见模式、安全问题和样式违规。但它并不能替代对架构决策和业务逻辑的人为审查。
我的流程：首先AI审查（捕捉明显的问题）→ 人工审查（捕捉微妙的问题）→ 讨论（解决 disagreements）。
如何给出良好的反馈
- 要具体。 “这可以更好”是毫无意义的。“这个SQL查询容易受到注入攻击——请改用参数化查询”是可操作的。
- 解释原因。 不要仅仅说“改变这个”。解释原因，让开发者学习。
- 区分阻塞问题与建议。 “必须修复：安全问题”与“建议：我会重命名这个变量以提高清晰度。”
- 赞扬好代码。 “这里的错误处理很好”强化了良好的实践。
相关工具
代码生成器 — 生成遵循最佳实践的代码
单元测试生成器 — 确保代码按预期工作
代码格式化工具 — 审查前的一致格式
差异检查器 — 比较代码版本