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.

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

核心原则： 先验证再实施。有疑问先询问，技术正确性优先于社交层面的融洽。

The Response Pattern

回应流程

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

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)
"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

处理模糊的反馈

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:

Reviewer: "Fix items 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."

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.

示例：

Reviewer: "Fix items 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 User (Trusted)

来自可信用户

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

理解后再实施
若范围不明确仍需询问
不做情绪化认同
直接行动或给出技术层面的确认

From External Reviewers

来自外部评审者

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?"

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?"

YAGNI Check

YAGNI 检查

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

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

实施顺序

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

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 architectural decisions

How to push back:

Use technical reasoning, not defensiveness
Ask specific questions
Reference working tests/code

出现以下情况时推回：

建议会破坏现有功能
评审者不了解完整背景
违反YAGNI原则（功能未被使用）
对当前技术栈来说在技术上不可行
存在遗留/兼容性限制
与架构决策冲突

推回方式：

基于技术理由，而非防御性态度
提出具体问题
引用可运行的测试/代码

Acknowledging Correct Feedback

确认正确反馈的方式

When feedback IS correct:

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

NOT:

"You're absolutely right!"
"Great point!"
"Thanks for catching that!"

Why no thanks: Actions speak. Just fix it. The code shows you heard the feedback.

当反馈正确时：

"Fixed. [Brief description of what changed]"
"Good catch - [specific issue]. Fixed in [location]."
[直接修复并在代码中体现]

不要使用：

"You're absolutely right!"
"Great point!"
"Thanks for catching that!"

为何不用感谢： 行动胜于言语。直接修复即可，代码本身就能体现你已接收反馈。

GitHub Thread Replies

GitHub 评论线程回复

Reply in the comment thread, not as top-level PR comment:

bash

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies

在评论线程中回复，而非作为PR的顶级评论：

bash

gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies

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

错误	修正方案
情绪化认同	明确技术要求或直接行动
盲目实施	先对照代码库进行验证
批量实施未测试	逐项实施，每项单独测试
默认评审者正确	检查是否会破坏现有功能
回避推回反馈	技术正确性优先于社交融洽
部分实施	先澄清所有模糊项再行动

The Bottom Line

核心总结

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

Verify. Question. Then implement.

No performative agreement. Technical rigor always.

外部反馈是需要评估的建议，而非必须执行的命令。

先验证，再质疑，最后实施。

拒绝情绪化认同，始终保持技术严谨性。