代码审查清单：提升团队代码质量

为什么需要代码审查？

• 发现潜在 bug
• 知识共享与传承
• 保持代码风格统一
• 提升整体代码质量

审查清单

功能性 ✅

• 代码是否实现了需求？
• 边界条件是否处理？
• 错误处理是否完善？
• 是否有单元测试覆盖？
• 性能是否有明显问题？

代码设计 🏗️

• 函数/类职责是否单一？
• 是否有重复代码需要提取？
• 命名是否清晰有意义？
• 函数长度是否合理（建议<50 行）？
• 是否过度设计或设计不足？

可读性 📖

• 代码是否易于理解？
• 是否有必要的注释？
• 注释是否解释了"为什么"而非"是什么"？
• 格式是否符合团队规范？
• 是否有魔法数字需要提取为常量？

安全性 🔒

• 用户输入是否验证？
• 是否有 SQL 注入风险？
• 敏感信息是否硬编码？
• 权限检查是否到位？
• 日志是否泄露敏感信息？

测试 🧪

• 是否有单元测试？
• 测试是否覆盖主要场景？
• 测试是否可维护？
• 测试名称是否清晰？

审查示例

❌ 不好的审查意见

"这段代码有问题，重写。"

✅ 好的审查意见

"这个函数有 120 行，建议拆分成 2-3 个小函数，每个负责单一职责。比如可以把数据验证逻辑提取到 validateInput() 函数中。"

审查流程建议

1. 提交前自检

## 变更说明
- 功能描述
- 测试情况
- 影响范围

## 自查清单
- [ ] 代码已通过本地测试
- [ ] 已运行 linter
- [ ] 已更新相关文档

2. 审查时机

• 小 PR（<400 行）：24 小时内审查
• 大 PR：安排专门时间审查
• 紧急修复：快速通道

3. 审查人数

• 常规 PR：1 人审查
• 核心模块：2 人审查
• 架构变更：团队讨论

常见陷阱

1. 完美主义

不要追求完美代码，关注关键问题。

2. 人身攻击

对事不对人，用"代码"而非"你"。

❌ "你为什么这样写？" ✅ "这样写可能导致..."

3. 过度审查

关注重要问题，不要纠结于格式细节（用工具自动化）。

4. 审查疲劳

单次审查不超过 60 分钟，每天不超过 4 个 PR。

工具推荐

• GitHub/GitLab：内置代码审查
• Phabricator：企业级代码审查
• Reviewable：专业审查工具
• SonarQube：自动化代码质量检查

审查者心态

1. 帮助而非批评：目标是帮助作者改进
2. 提问而非命令："考虑过...吗？"而非"必须..."
3. 认可优点：好的代码也要表扬
4. 及时响应：不要让 PR 积压

被审查者心态

1. 开放心态：审查是为了代码更好
2. 及时回应：尽快处理审查意见
3. 解释意图：有疑问主动说明
4. 感谢反馈：审查是免费的学习机会

总结

有效的代码审查能显著提升代码质量和团队能力。建立清晰的审查清单和流程，培养良好的审查文化，让审查成为团队成长的助力而非负担。