Gen1→Gen2移行のための準備

なぜデッドコードを削除するのか

デッドコード（使われていないコード）を放置すると、以下の問題が起きます。

① 読む側のコストが上がる：新しいメンバーが「このコード何のために存在するの？」と混乱します。使われているコードと使われていないコードが混在していると、全体像の把握が難しくなります。

② 移行作業のスコープが広がる：Amplify Gen1からGen2への移行のような大きな作業では、デッドコードまで移行対象に含めてしまうと、作業量が無駄に増えます。移行前の整理は必須でした。

③ バンドルサイズが増える：使われていないパッケージやコードも含めてビルドされると、アプリのサイズが大きくなります。

---

削除PRのレビューで確認すべきこと

今回レビューしたPR（KYO-564）の内容は「Amplify Gen1からGen2への移行前に、使われていないWebフロントエンドのコードを削除する」というものでした。

削除PRのレビューで一番大事なのは「削除してはいけないものが消えていないか」の確認です。「何を削除したか」より「何が残っているか」を確認します。

---

「絶対に触ってはいけない」ファイルを先に特定する

レビューを始める前に、「このPRで絶対に変更されてはいけないファイル」を先にリストアップします。

# 絶対に変更されてはいけないもの（KYO-564の場合）

amplify/backend/    → AWSのインフラ設定。変更されると環境が壊れる
src/api/            → GraphQLのAPI層。削除すると全機能が止まる
src/graphql/        → 自動生成ファイル。手動で触らない
SSO関連のコード      → 認証が壊れると全員ログインできなくなる
/settings/**        → 現在使われている設定画面

# 削除してOKなもの（KYO-564の場合）

src/view/           → 使われていない古いWebの画面
src/redux/          → 使われていない古いReduxスライス
cypress/            → E2Eテストのうち古いWebフロントのもの
package.json の不要な依存（FullCalendarなど）

このリストを先に作ってからGitHubの Files Changed を確認すると、「触ってはいけないものが変更されていないか」を効率よくチェックできます。

---

CIを使って安全を確認する

削除PRで一番信頼できる確認方法はCIです。TypeScriptのコンパイルエラーやテストの失敗はCIが自動で検出してくれます。

# CIで自動確認される内容（KYO-564の場合）

npm run check → TypeScriptの型チェック
              → 削除したファイルを参照しているコードがあればエラーになる

npm run build → ビルドが通るか
              → import先が存在しないとビルドエラーになる

# ローカルで確認する必要があること

- 実際にログインできるか（SSO）
- 設定画面が動くか
- 削除されたはずのページが表示されないか

---

コード削除は「勇気」ではなく「確認」です。確認すべきことを確認すれば、怖がらずに不要なコードを消せます。きれいなコードベースは開発速度を上げます。