113. レビューコメントへの対応 — 指摘はコードへの意見

レビューで受ける指摘は、あなたの人格ではなくコードへの意見です。最初は指摘の多さに落ち込みがちですが、レビューはコードを良くする共同作業であり、指摘が多いのは真剣に読んでもらえた証拠です。対応の基本は、すべてのコメントに返信することです。修正したなら「修正しました」、しないなら理由を書いて、放置コメントを残さないようにします。

指摘を受けた修正は、新しいコミットを積む「追いコミット」で行います。レビュー済みのコミットを書き換えて force push すると、レビュアーは「どこが変わったのか」を差分で追えなくなり、もう一度全部読み直すことになります。マージ前に履歴をきれいにしたければ、squash マージに任せれば十分です。

テキストでの議論が2〜3往復しても平行線なら、対面や通話に切り替えるのが実務の判断です。文字では伝わりにくい設計の意図も、5分話せば解決することがよくあります。ただし、話して決めた結論は必ず PR のコメントに書き戻しましょう。後から経緯を読む人のための記録になります。

サンプルコード(フレームワーク環境が必要なため表示のみ)

<!-- レビューコメントへの返信の基本パターン -->

<!-- パターン1: 指摘どおり修正した場合 -->
ご指摘ありがとうございます。おっしゃるとおりなので
変数名を `users` → `filteredUsers` に修正しました。(a1b2c3d)

<!-- パターン2: 修正しない場合は理由を添える -->
ここは意図的にこの形にしています。
○○のケースで△△が必要になるためです。いかがでしょうか?

<!-- パターン3: 平行線になったら同期コミュニケーションへ -->
この設計は文章だと伝えづらいので、10分ほど通話で相談させてください。
(通話後)相談の結果、□□の方針で進めることになりました。

<!-- どのパターンでも「返信しないコメント」をゼロにするのが基本 -->

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗