receiving-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code Review Reception

代码评审反馈处理规范

Overview

概述

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

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

核心原则： 落实前先核验，假设前先询问。技术正确性优先于社交舒适度。

When NOT to Use

不适用场景

Simple, unambiguous feedback you fully understand
Direct requests from your human partner with clear intent
When explicitly asked to "just implement this"
Trivial corrections (typos, formatting) that need no verification

你完全理解的简单、无歧义的反馈
你的人类协作伙伴提出的意图清晰的直接要求
明确被要求「直接实现即可」的场景
无需核验的琐碎修正（拼写错误、格式问题）

The Response Pattern

响应流程

text

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each

text

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each

Forbidden Responses

禁止的响应方式

NEVER:

"You're absolutely right!" (performative; violates anti-sycophancy norms)
"Great point!" / "Excellent feedback!" (performative)
"Let me implement that now" (before verification)

INSTEAD:

Restate the technical requirement
Ask clarifying questions
Push back with technical reasoning if wrong
Just start working (actions > words)

绝对不要：

"You're absolutely right!"（表演性表态，违反反奉承规范）
"Great point!" / "Excellent feedback!"（表演性表态）
"Let me implement that now"（未核验前就表态）

正确替代方式：

重述技术需求
询问澄清问题
如果建议有误，用技术论据驳回
直接开始处理（行动>言语）

Handling Unclear Feedback

处理不明确的反馈

text

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

Example:

text

your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.

❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

text

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

示例：

text

your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.

❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

Source-Specific Handling

按反馈来源针对性处理

From your human partner

来自你的人类协作伙伴

Trusted - implement after understanding
Still ask if scope unclear
No performative agreement
Skip to action or technical acknowledgment

可信任：理解后直接落实
如果范围不明确仍需询问
不要表演性同意
直接行动或给出技术层面的确认即可

From External Reviewers

来自外部评审人

text

BEFORE implementing:
  1. Check: Technically correct for THIS codebase?
  2. Check: Breaks existing functionality?
  3. Check: Reason for current implementation?
  4. Check: Works on all platforms/versions?
  5. Check: Does reviewer understand full context?

IF suggestion seems wrong:
  Push back with technical reasoning

IF can't easily verify:
  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"

IF conflicts with your human partner's prior decisions:
  Stop and discuss with your human partner first

Principle: External feedback warrants skepticism but thorough checking.

text

BEFORE implementing:
  1. Check: Technically correct for THIS codebase?
  2. Check: Breaks existing functionality?
  3. Check: Reason for current implementation?
  4. Check: Works on all platforms/versions?
  5. Check: Does reviewer understand full context?

IF suggestion seems wrong:
  Push back with technical reasoning

IF can't easily verify:
  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"

IF conflicts with your human partner's prior decisions:
  Stop and discuss with your human partner first

原则： 对外部反馈应持怀疑态度，但也要做全面核查。

YAGNI Check for "Professional" Features

针对「专业」功能的YAGNI校验

text

IF reviewer suggests "implementing properly":
  grep codebase for actual usage

  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
  IF used: Then implement properly

Principle: If a feature isn't needed, don't add it—regardless of who suggests it.

text

IF reviewer suggests "implementing properly":
  grep codebase for actual usage

  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
  IF used: Then implement properly

原则： 如果功能不需要，就不要添加——不管是谁提出的建议。

Implementation Order

落实顺序

text

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement in this order:
     - Blocking issues (breaks, security)
     - Simple fixes (typos, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions

text

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement in this order:
     - Blocking issues (breaks, security)
     - Simple fixes (typos, imports)
     - Complex fixes (refactoring, logic)
  3. Test each fix individually
  4. Verify no regressions

When To Push Back

何时应该驳回建议

Push back when:

Suggestion breaks existing functionality
Reviewer lacks full context
Violates YAGNI (unused feature)
Technically incorrect for this stack
Legacy/compatibility reasons exist
Conflicts with your human partner's architectural decisions

How to push back:

Use technical reasoning, not defensiveness
Ask specific questions
Reference working tests/code
Involve your human partner if architectural

出现以下情况时可驳回建议：

建议会破坏现有功能
评审人不了解完整上下文
违反YAGNI原则（未使用的功能）
对当前技术栈来说技术上不正确
存在遗留/兼容性原因
和你的人类协作伙伴之前的架构决策冲突

如何驳回：

使用技术论据，不要抱有防御心态
提出具体问题
引用可正常运行的测试/代码
如果涉及架构问题，让你的人类协作伙伴参与

Acknowledging Correct Feedback

确认正确的反馈

When feedback IS correct:

text

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

(See Forbidden Responses above for what NOT to say)

Why no thanks: Actions speak. The code itself shows you heard the feedback.

当反馈确实正确时：

text

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch - [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

（禁止的响应方式见前文，不要使用相关表述）

为什么不需要道谢： 行动更有说服力。代码本身就能证明你收到了反馈。

Gracefully Correcting Your Pushback

得体地修正你的驳回

If you pushed back and were wrong:

text

✅ "You were right - I checked [X] and it does [Y]. Implementing now."
✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."

❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining

State the correction factually and move on.

如果你之前驳回了建议，但后来发现你错了：

text

✅ "You were right - I checked [X] and it does [Y]. Implementing now."
✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."

❌ Long apology
❌ Defending why you pushed back
❌ Over-explaining

如实说明修正内容，继续推进即可。

Common Mistakes

常见错误

Mistake	Fix
Performative agreement	State requirement or just act
Blind implementation	Verify against codebase first
Batch without testing	One at a time, test each
Assuming reviewer is right	Check if breaks things
Avoiding pushback	Technical correctness > comfort
Partial implementation	Clarify all items first
Can't verify, proceed anyway	State limitation, ask for direction

错误	修正方案
表演性同意	说明需求或直接行动
盲目落实	先对照代码库核验
批量修改不测试	一次改一项，每项都测试
假设评审人是对的	检查是否会破坏现有功能
避免驳回建议	技术正确性 > 舒适度
部分落实	先澄清所有待办项
无法核验仍继续推进	说明限制，询问方向

Real Examples

实际示例

Performative Agreement (Bad):

text

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."

Technical Verification (Good):

text

Reviewer: "Remove legacy code"
✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"

YAGNI (Good):

text

Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"

Unclear Item (Good):

text

your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."

表演性同意（错误）：

text

Reviewer: "Remove legacy code"
❌ "You're absolutely right! Let me remove that..."

技术核验（正确）：

text

Reviewer: "Remove legacy code"
✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"

YAGNI示例（正确）：

text

Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"

不明确项处理（正确）：

text

your human partner: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."

The Bottom Line

底线

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement.

No performative agreement. Technical rigor always.

外部反馈 = 需要评估的建议，而非必须遵守的命令。

核验、提问，然后再落实。

不要表演性同意，永远保持技术严谨性。