receiving-code-review

Receiving Code Review - 技术严谨的代码审查响应指南

技能概述

Receiving Code Review 是一个专注于技术验证的代码审查响应技能，帮助开发者在收到审查反馈时进行严谨的技术评估，而非表演性同意或盲目实现。

适用场景

1. 收到不清楚或模糊的代码审查反馈

当审查意见表述不明确、缺少上下文或难以理解时，该技能指导你如何暂停实施，主动询问澄清，避免因部分理解导致错误实现。

2. 面对外部审查者的技术建议

对于来自项目外部或团队外部的代码审查建议，该技能提供系统化的验证流程，帮助评估建议是否适用于当前代码库的技术栈、架构约束和业务需求。

3. 需要对审查意见进行技术验证时

当审查建议可能破坏现有功能、与既有架构冲突或技术上不可行时，该技能指导如何基于技术推理进行合理的反驳和沟通。

核心功能

1. 六步响应流程

提供 READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT 的标准化响应模式，确保每个审查反馈都经过完整的技术验证流程，避免盲目实施。

2. 来源差异化处理

区分来自信任伙伴和外部审查者的反馈，对外部建议采用"怀疑但仔细检查"的策略，包含五项验证检查清单，确保建议的技术正确性和适用性。

3. 禁止响应模式

明确定义了需要避免的表演性表达（如"你绝对正确"、"很好的建议"），提供技术性的替代响应方式，强调用行动和代码变化来展示对反馈的理解。

常见问题

收到代码审查反馈后应该立即实现吗？

不应该立即实现。该技能要求在实施前先完整阅读反馈、理解需求、验证技术可行性、评估对代码库的影响，只有确认建议正确且适用后才逐步实现。对于不清楚的反馈项，应在实施前先询问澄清，避免部分理解导致的错误实现。

什么时候应该对代码审查建议提出质疑？

当审查建议可能破坏现有功能、违反 YAGNI 原则（建议实现未使用的"专业"功能）、在当前技术栈下技术上不正确、存在遗留或兼容性约束、或与项目架构决策冲突时，应该基于技术推理进行合理的反驳。该技能提供了具体的质疑方法和沟通策略。

如何处理不清楚或模糊的代码审查意见？

当收到不清楚的审查意见时，应立即停止实施工作，主动询问澄清。不要只实施理解的部分而留下不清楚的部分，因为多个审查项可能彼此相关。正确的做法是明确说明哪些项已理解、哪些项需要澄清，在获得完整理解后再统一实施。