novel-jp/learn-gw-review

/learn-gw-review — レビュー→修正→マージ（06-03）

レビュー指摘への対応、修正コミット、マージ、complete_work までの一連のサイクルを体験する演習です。

所要時間: 約 45 分 前提: /learn-gw-pr（06-02）完了済み スキル対応: Git Workflow（チーム開発フロー）

---

Step 1: 導入

「コードレビューは品質を高めるだけでなく、チームの知識共有の場です。

AI 時代でもレビューの重要性は変わりません。
むしろ AI が高速にコードを生成するからこそ、
人間のレビューが品質のゲートキーパーとして機能します。

この演習では、レビュー指摘を受けてから完了までの全サイクルを体験します。」

---

Step 2: 演習モードの判定と準備

2-1. PR の有無を確認する

まず、06-02 で作成した PR が存在するか確認する:

gh pr list --state open --author @me

• PR がある場合 → そのまま PR を使って演習を進める（実践モード）
• PR がない場合 → シミュレーションモードで進める。以下の scaffold を生成し、ローカルで演習する

2-2. シミュレーションモード: scaffold の生成

PR がない場合、AI が以下のようなサンプルコードを生成する（受講者のプロジェクトに合わせて調整してよい）:

// sample-review-target.js
function processUserInput(d) {
  const result = JSON.parse(d);
  return result.name.toUpperCase();
}

このコードには意図的にレビューで指摘される問題を含めている:

• エラーハンドリングがない（JSON.parse が失敗する可能性）
• 変数名 d が不明瞭

新卒向け: AI に「このコードのレビュー指摘に対応してください」と依頼すると、修正案を提案してくれます。まずは自分で考えてから、AI の提案と比較してみましょう。

2-3. レビュー指摘のシナリオ

受講者に以下のレビュー指摘シナリオを提示する:

「あなたの PR（またはコード）に以下のレビューコメントが付きました:

1. 【改善要望】エラーハンドリングが不足している — JSON.parse や null アクセスが失敗する場合の処理を追加してください
2. 【質問】この実装方法を選んだ理由は？ — 代替手段との比較を PR description に追記してください
3. 【nit】変数名 `d` が分かりにくい — より説明的な名前（例: `rawInput`）にしてください」

レビュー指摘の種類

| マーク | 意味 | 対応 | | ------------ | ---------- | ---------------------------------------------- | | 改善要望 | 修正必須 | 修正してコミット | | 質問 | 意図の確認 | 回答する（PR コメントまたは description 更新） | | nit | 軽微な指摘 | 可能な限り対応（次回でも可） |

---

Step 3: 修正の実施

レビュー指摘に対応する:

3-1. コードの修正

指摘に基づいてコードを修正する。scaffold の場合、以下のような修正が期待される:

• JSON.parse を try-catch で囲む
• result.name の null チェックを追加
• 変数名 d を rawInput 等に改善

3-2. レビュアーへの返答（実践モード）

「質問」タイプの指摘には、PR コメントで回答する:

gh pr comment <PR番号> --body "JSON.parse を直接使った理由: 入力が常に JSON 文字列である前提でしたが、ご指摘の通り防御的なパースに変更しました。代替として zod でのバリデーションも検討しましたが、この規模ではオーバーキルと判断しました。"

シミュレーションモードの場合: コメント内容を口頭で説明する。「なぜその実装を選んだか」を言語化する練習として取り組む。

「レビュアーへの返答のコツ:
- 『なぜそうしたか』の質問には経緯と根拠を含めて回答する — Intent Engineering の実践
- 指摘を受けて変更した場合は、何をどう変えたか明記する
- nit でも対応するとレビュアーの信頼を得られる」

3-3. コミットとプッシュ

修正をコミットする。レビュー対応は 1 コミットにまとめるのが一般的（レビュアーが差分を追いやすい）:

git add <修正したファイル名>
git commit -m "fix: レビュー指摘対応 — エラーハンドリング追加、変数名改善"

注意: git add . は意図しないファイル（設定ファイル、一時ファイル等）を含むリスクがあります。修正したファイルを名前で指定しましょう。

実践モードの場合、プッシュする:

git push

---

Step 4: マージと完了

レビュー対応後、マージから完了までの流れ:

4-1. マージ

実践モード: PR をマージする。

gh pr merge --squash

squash merge を使うのは、レビュー対応の中間コミットを 1 つにまとめ、main ブランチの履歴を読みやすく保つためです。

シミュレーションモード: マージの手順は説明のみ。次の 4-2 に進む。

4-2. ブランチの整理

実践モードの場合、マージ済みブランチを削除する:

git checkout main && git pull && git branch -d <ブランチ名>

-d（小文字）はマージ済みブランチのみ削除できる安全なオプションです。未マージのブランチに対しては Git が警告を出して削除を拒否するので、安心して使えます。

4-3. ProjSight 完了

complete_work(taskId) でタスクを完了にする。

「complete_work の前に:
- PR がマージ済みであることを確認する（実践モードの場合）
- 未登録の PR があれば attach_pr で紐づける
- complete_work は deliverable の進捗を自動計算する」

---

Step 5: 振り返り

「レビュー→修正→マージ→完了のサイクルまとめ:

1. レビュー指摘を受ける — 改善要望 / 質問 / nit を区別
2. コードを修正し、質問にはコメントで回答する
3. 修正したファイルを指定してコミット・プッシュ
4. マージ — squash merge で履歴をきれいに
5. complete_work — ProjSight でタスク完了を記録

ポイント:
- レビューは『ダメ出し』ではなく『品質向上の協働作業』
- AI が書いたコードも人間が書いたコードも同じレビュープロセスを通す
- complete_work を忘れると、ProjSight の進捗が正確にならない

次の /learn-gw-cicd では、CI の結果の読み方と失敗時の対応を学びます。」

受講者のタスクを complete_work(taskId) で完了にする。