receiving-code-review

コードレビューへの対応

概要

コードレビューに必要なのは、感情的なパフォーマンスではなく、技術的な評価です。

基本原則： 実装する前に検証します。仮定する前に質問します。社交的な心地よさより、技術的な正しさを優先します。

応答パターン

收到代码审查反馈时：

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

禁止されている返答

絶対に言わないでください：

• 「おっしゃるとおりです！」（CLAUDE.md の規定に明確に違反します）
• 「いい視点ですね！」／「素晴らしいフィードバックです！」（形だけの返答です）
• 「すぐに実装します」（検証する前に言わないでください）

次のように対応してください：

• 技術的な要件を言い換えて確認します
• 明確化のために質問します
• レビューの指摘が誤っている場合は、技術的な理由を示して反論します
• すぐに作業に取りかかります（言葉より行動です）

曖昧なフィードバックへの対応

如果有任何一项不明确：
  停下来——先不要实施任何内容
  就不明确的项目提出澄清

为什么：各项之间可能有关联。部分理解 = 错误实施。

例：

搭档："修复第 1-6 项"
你理解 1、2、3、6。对 4、5 不确定。

❌ 错误做法：先实施 1、2、3、6，稍后再问 4、5
✅ 正确做法："第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手。"

提案者による対応の違い

パートナーからのフィードバック

• 信頼できます —— 理解したら、そのまま実装します
• 範囲が不明確な場合は、引き続き質問します
• 形だけの同意はしません
• すぐに行動するか、技術的な確認を返します

外部レビュー担当者からのフィードバック

实施之前：
  1. 检查：对这个代码库来说技术上正确吗？
  2. 检查：是否会破坏现有功能？
  3. 检查：当前实现这样写是否有原因？
  4. 检查：在所有平台/版本上都适用吗？
  5. 检查：审查者了解完整上下文吗？

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

如果无法轻易验证：
  说明情况："没有 [X] 我无法验证这一点。我应该 [调查/提问/先做]？"

如果与搭档之前的决策冲突：
  先停下来和搭档讨论

パートナーの原則： 「外部からのフィードバックには懐疑的な姿勢を保ちつつ、慎重に検証する」

YAGNI の確認——「専門的な」機能の提案について

如果审查者建议"正规地实现"：
  在代码库中 grep 实际使用情况

  如果没人用："这个接口没有被调用。删掉它（YAGNI）？"
  如果有人用：那就正规实现

パートナーの原則： 「あなたもレビュー担当者も、私に対して責任を負います。この機能が不要なら、追加しないでください。」

実装の順序

对于包含多项的反馈：
  1. 先澄清所有不明确的项
  2. 然后按以下顺序实施：
     - 阻塞性问题（崩溃、安全）
     - 简单修复（拼写、导入）
     - 复杂修复（重构、逻辑）
  3. 逐个测试每项修复
  4. 验证没有回归

反論すべき場合

以下の場合は反論します：

• 提案によって既存の機能が壊れる
• レビュー担当者が完全なコンテキストを把握していない
• YAGNI に違反している（機能を使う人がいない）
• 現在の技術スタックでは技術的に正しくない
• レガシーまたは互換性上の理由がある
• パートナーのアーキテクチャ上の決定と矛盾する

反論の方法：

• 防御的な感情を交えず、技術的な理由を示します
• 具体的な質問をします
• 正常に動作しているテストやコードを引用します
• アーキテクチャの問題が関係する場合は、パートナーにも参加してもらいます

人前で反論しづらい場合の合言葉： 「Strange things are afoot at the Circle K」

正しいフィードバックの確認

フィードバックが正しい場合：

✅ "已修复。[简要说明改了什么]"
✅ "发现得好——[具体问题]。已在 [位置] 修复。"
✅ [直接修复并在代码中体现]

❌ "你说得太对了！"
❌ "好观点！"
❌ "感谢你发现了这个！"
❌ "感谢你 [任何内容]"
❌ 任何感谢的表达

感謝を述べない理由： 行動がすべてを物語ります。直接修正してください。フィードバックを受け取ったことは、コード自体が示します。

「ありがとう」と書きそうになったら： 削除してください。修正内容を直接伝えます。

自分の反論を適切に訂正する

反論したものの、後になって自分が間違っていたと気づいた場合：

✅ "你是对的——我检查了 [X]，确实 [Y]。正在实施。"
✅ "验证后确认你是对的。我最初的理解有误，因为 [原因]。正在修复。"

❌ 长篇道歉
❌ 为自己的反驳辩护
❌ 过度解释

訂正した内容を正直に伝えてから、先に進みます。

よくある間違い

間違い	修正方法
形だけの同意	要件を言い換えて確認するか、すぐに行動する
検証せずに実装する	まずコードベースと照らし合わせて検証する
テストせずにまとめて実装する	一度に一つずつ行い、個別にテストする
レビュー担当者が必ず正しいと思い込む	既存の機能が壊れないか確認する
反論を避ける	技術的な正しさ > 社交的な心地よさ
一部しか理解せずに実装を始める	すべての項目を先に明確にする
検証できないのに作業を続ける	制約を説明して、指示を求める

実例

形だけの同意（悪い例）：

审查者："删除遗留代码"
❌ "你说得太对了！让我删掉它……"

技術的な検証（良い例）：

审查者："删除遗留代码"
✅ "查了一下……构建目标是 10.15+，这个 API 需要 13+。向后兼容需要保留遗留代码。当前实现有错误的 bundle ID——修复它还是放弃 pre-13 支持？"

YAGNI（良い例）：

审查者："实现完善的指标追踪，包括数据库、日期过滤、CSV 导出"
✅ "在代码库中 grep 了一下——没有任何地方调用这个接口。删掉它（YAGNI）？还是有我遗漏的调用？"

不明確な項目（良い例）：

搭档："修复第 1-6 项"
你理解 1、2、3、6。对 4、5 不确定。
✅ "第 1、2、3、6 项我理解了。第 4 和第 5 项需要澄清后再动手。"

GitHub のコメントへの返信

GitHub でインラインレビューコメントに返信する場合は、コメントスレッド内で返信してください（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies）。PR のトップレベルコメントは投稿しないでください。

最後に

外部からのフィードバック = 評価すべき提案であり、必ず実行すべき命令ではありません。

検証します。疑問を投げかけます。それから実装します。

形だけの同意はしません。常に技術的な厳密さを保ちます。