サンプルコードで身につける: レビューコメントへの対応 — 指摘はコードへの意見

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

1修正した場合の返信 — 対応内容とコミットを示す

指摘に沿って修正したら、何をどう直したかとコミットのハッシュを添えて返信します。レビュアーは返信からそのコミットに飛んで、修正だけを確認できます。「修正しました」の一言より、何をしたかまで書くのが親切です。

<!-- レビュアーのコメント:
     「この変数名 data だと中身が分かりません。
       フィルタ済みユーザー一覧だと分かる名前にしませんか?」 -->

<!-- 良い返信の例 -->
ご指摘ありがとうございます。たしかに曖昧でした。
`data` → `filteredUsers` にリネームしました。(a1b2c3d)

<!-- ポイント:
     ・何をどう直したかを具体的に書く
     ・修正コミットのハッシュを添える(レビュアーが差分に飛べる)
     ・GitHub の「Resolve conversation」はレビュアー側が
       確認後に押す運用のチームが多い(チームのルールに従う) -->

2修正しない場合の返信 — 理由を添えて相談する

すべての指摘に従う必要はありませんが、黙って無視するのは禁物です。修正しないなら理由を説明し、相手の判断を仰ぐ形で返します。意見が違うこと自体は健全で、大事なのは理由を言葉にして残すことです。

<!-- レビュアーのコメント:
     「このAPI呼び出し、コンポーネントに直接書かずに
       サービスに切り出したほうがよくないですか?」 -->

<!-- 良い返信の例(修正しない理由を添えて相談する) -->
コメントありがとうございます。悩んだのですが、この API は
この画面からしか呼ばれない想定なので、今回はコンポーネント内に
置いています。他画面でも使うことになった時点でサービスに
切り出そうと考えていますが、いかがでしょうか?

<!-- 悪い返信の例 -->
<!-- (返信せず放置する / 「今のままでいいです」とだけ返す) -->

<!-- 理由を書けば、相手が納得するか、より良い案が返ってくるかの
     どちらかになる。どちらでも PR は前に進む -->

3修正は追いコミットで積む

レビュー対応の修正は、既存コミットの修正ではなく新しいコミットとして積みます。レビュアーは「前回見た位置からの差分」だけを確認すればよくなり、再レビューが数分で済みます。コミットメッセージにレビュー対応であることを書くと更に親切です。

# レビュー指摘に対応したら、新しいコミットとして積む(追いコミット)
git add src/app/user-list/user-list.ts
git commit -m "レビュー指摘: フィルタ処理を computed に変更"
git push

# GitHub の PR 画面では:
#   ・Commits タブに対応コミットが1つ増える
#   ・レビュアーは「Changes since your last review」で
#     前回レビュー以降の差分だけを表示できる
#   → 全部読み直さなくてよいので、再レビューが速い

# 「コミットが増えて履歴が汚れる」心配は不要。
# マージ時に squash すれば main には1コミットにまとまる

4レビュー済みの部分を書き換えるforce pushは避ける

レビュー中のブランチで git commit --amend や rebase をして force push すると、レビュー済みのコミットが別物に置き換わり、レビュアーは差分を追い直せなくなります。レビューが始まったら履歴は書き換えない、が原則です。

# ── 避けたい操作(レビューが始まったあとのブランチで)──
git commit --amend        # 直前のコミットを作り直す
git rebase -i main        # コミットをまとめ直す
git push --force          # 書き換えた履歴を上書き push

# 何が起きるか:
#   ・レビュー済みのコミットが「別のコミット」に置き換わる
#   ・「前回レビューからの差分」が正しく表示されなくなる
#   ・過去のレビューコメントが対応する行を見失うことがある
#   → レビュアーは最初から全部読み直すはめになる

# 原則: レビューが始まったら追いコミット(通常の commit + push)のみ。
# 履歴の整理はマージ時の squash に任せればよい。
# (PR を出す前の、自分しか見ていない段階なら書き換えても問題ない)

5平行線になったら通話へ — 切り替えと書き戻し

テキストの議論が2〜3往復しても収束しないときは、通話や対面に切り替えるのが実務の判断です。声で話すと数分で決着することがよくあります。ただし話した結論は必ず PR コメントに書き戻し、記録として残します。

<!-- コメント欄で設計議論が3往復して平行線になった場面 -->

<!-- 切り替えの提案 -->
文章だとお互いの前提がずれている気がするので、
10分ほど通話で相談させてください。今日の午後は空いています。

<!-- 通話のあと: 結論を必ず PR に書き戻す -->
先ほど通話で相談し、以下に決まりました。

- 今回は現在の実装(コンポーネント内で状態を保持)のまま進める
- 次の画面で同じ状態が必要になったら、サービスへの切り出しを別 PR で行う

上記の方針でこのスレッドはクローズします。

<!-- 書き戻しがないと、半年後に経緯を調べる人(未来の自分を含む)が
     「なぜこの設計になったのか」を辿れなくなる -->