代码审查（Code Review）实战
掌握专业 Code Review 的方法论和常见问题识别
- 理解 Code Review 的目的和流程
- 掌握审查 Checklist
- 学会识别常见代码坏味道
- 了解如何给出有效的审查意见
Code Review 不只是找 Bug
Code Review 是团队保证代码质量、知识共享、统一风格的实践。Review 的目的不是挑错，是发现潜在问题、确保代码可维护、团队成员互相学习、统一技术方案。
Google 工程实践文档指出：Review 时先看变更是否正确，再看可维护性（可读性、复杂度、耦合度），最后才是风格细节。如果变更整体方向正确，即使不完美也应该批准，不要因为个人偏好阻塞合并。
审查 Checklist
每次 Review 按以下顺序检查：
正确性：逻辑是否正确？边界条件处理了吗？并发安全吗？
错误处理：异常有没有被正确捕获和传播？资源有没有正确释放？
安全性：有没有 SQL 注入、XSS、硬编码密钥？权限校验了吗？
可维护性：命名清晰吗？函数太长吗？注释解释了为什么而不是做什么？
测试：有单元测试吗？覆盖了边界和异常路径吗？
性能：有没有明显的N+1查询、不必要的循环、内存泄漏？
常见代码坏味道
# 1. 过长函数（>50行就要警惕）
# 反例：一个函数做了太多事
def process_order(order_id):
# 验证库存（20行）
# 扣减库存（15行）
# 计算价格（30行）
# 发送通知（10行）
# 写日志（5行）
pass
# 正例：拆成小函数，每个只做一件事
def process_order(order_id):
order = get_order(order_id)
validate_inventory(order)
deduct_inventory(order)
total = calculate_price(order)
notify_customer(order)
log_order_processed(order, total)
# 2. 魔法数字
# 反例
if status == 3: ...
# 正例
ORDER_STATUS_SHIPPED = 3
if status == ORDER_STATUS_SHIPPED: ...
# 3. 重复代码（DRY原则）
# 反例：三个地方写了相似的数据库查询
# 正例：提取为公共方法
# 4. 过深的嵌套（>3层）
# 反例
if user:
if user.is_active:
for order in user.orders:
if order.total > 100:
...
# 正例：提前返回（Guard Clause）
if not user or not user.is_active:
return
for order in user.orders:
if order.total <= 100:
continue
...如何给出有效的 Review 意见
糟糕的 Review 意见
"这写得不好""为什么不用XX？""太烂了"好的 Review 意见"这里如果用字典映射替代 if-elif，新增类型时不需要改这段代码，符合开闭原则。""这个循环里有数据库查询，N 条记录会查 N 次（N+1问题）。可以用 select_related 一次性查出。""这个函数有 4 层嵌套，建议用提前返回降低嵌套深度，可读性会好很多。"原则：对事不对人：说「代码」而不是「你」解释「为什么」：不只说要改什么，还要说原因区分「必须改」和「建议」：用 Nit: 前缀表示非阻塞建议肯定好的部分：不要只挑错
如果你在 Review 时需要超过 60 秒才能理解一段代码在做什么，这段代码就需要重构——不是你需要更努力地看，而是代码需要写得更清楚。
调试第一步应该是？
断点调试相比 print 的优势？
修复一个 Bug 后，最应该补上的是？
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
底层是大量、快速、稳定的单元测试（优先覆盖纯函数与边界/异常路径），中间是少量集成测试（验证模块协作），顶端是少量端到端测试（慢且脆）。测试最大的价值是当「安全网」：有它你才敢放心重构。没测试兜底的重构，本质是在赌博。写用例先想正常、边界、异常三类。
挑战任务
审查代码
以下代码有多个问题，找出至少 3 个并给出修改建议。
课后作业
审查真实代码
找一段你之前写的Python代码，用Checklist逐项审查，记好发现的问题和改进方案。