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 でインラインレビューコメントに返信するときは、トップレベルの PR コメントではなく、コメントスレッド内で返信します（gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies）。