接收代码评审（Receiving Code Review）

概述

代码评审需要技术评估，而非情绪表演。

核心原则： 先验证再实施。先问清再假设。技术正确性高于社交舒适度。

响应模式

收到代码评审反馈时：

1. 阅读：完整阅读反馈，不急于反应
2. 理解：用自己的话复述需求（或提问）
3. 验证：对照代码库实际情况检查
4. 评估：对这个代码库来说技术上合理吗？
5. 回应：技术性确认或有理有据的反驳
6. 实施：逐项实施，每项都测试

禁止的回应

绝对不要：

• "你说得太对了！"（表演性认同）
• "好观点！" / "优秀的反馈！"
• "让我现在就实施"（验证之前）

应该：

• 复述技术需求
• 提出澄清问题
• 如果评审者错了，用技术理由反驳
• 直接开始工作（行动胜于言语）

处理不清楚的反馈

如果任何条目不清楚：停下——不要实施任何东西。先要求澄清。

来源区分处理

来自协作伙伴

• 受信任——理解后实施
• 范围不清时仍然要问
• 不要表演性认同
• 跳过废话直接行动

来自外部评审者

实施之前：

1. 对这个代码库技术上正确吗？
2. 会破坏现有功能吗？
3. 当前实现有什么原因？
4. 所有平台/版本都适用吗？

如果建议有误：用技术理由反驳。

YAGNI 检查

如果评审者建议"正规实现"：

• 搜索代码库查看实际使用情况
• 未使用？"这个端点没有被调用。删除它（YAGNI）？"
• 在使用？那就正规实施

何时反驳

反驳条件：

• 建议会破坏现有功能
• 评审者缺少完整上下文
• 违反 YAGNI
• 对当前技术栈技术上不正确
• 存在兼容性原因

承认正确反馈

正确做法：
- "已修复。[简要描述变更]"
- "好发现——[具体问题]。已在 [位置] 修复。"
- [直接修复并在代码中展示]

错误做法：
- "你说得太对了！"
- "感谢捕获这个！"
- 任何感谢表达

为什么不感谢： 行动说明一切。直接修复。代码本身表明你听到了反馈。