kill-legacy

レガシーを削除する

目標はひとつです。 レガシーコードとフォールバックコードをなくし、コードベースを新旧の経路がいつまでも併存する状態ではなく、現在の経路ひとつにします。

一般的なコードの問題の整理、名前の変更、無関係なリファクタリングに範囲を広げないでください。レガシー／フォールバックではないコード（または、その削除を完了するために必要なコード）は変更しないでください。

基本ルール

• 古い経路をラップしたり、フラグで切り替えたり、「後で整理する」より、削除を優先してください。
• 現行の実装を優先してください。まだ必要である証拠がない限り、念のためとして使われていない二重経路を残さないでください。
• ユーザーが破壊的変更を許可していない限り、公開されている動作と外部との契約を維持してください。レガシー経路が公開 API の契約になっている場合は、呼び出し元を移行するか、削除前に明示的な承認を得てください。
• 経路を削除する前に、未使用または置き換え可能であることを確認してください（参照箇所、機能フラグ、環境変数のデフォルト、実行時設定、ドキュメント、テスト）。
• レガシーを存続させている足場を取り除いてください。フラグ、環境変数、アダプター、二重読み書き、一時的な分岐、古い経路専用のテストが対象です。
• 削除したフォールバックを、新しい暗黙のフォールバックで置き換えないでください。入力が現行モデルに適合しない場合は、境界で明確にエラーにしてください。
• 無関係なユーザーの変更は維持してください。変更をレビューしやすい単位に保ってください。

対象範囲の設定

• 対象を限定する場合： 指定されたファイル、ディレクトリ、モジュール、機能、フラグ、または移行の残存物だけを対象にします。削除を完了するために必要な場合に限り、対象外のファイルも変更します。
• コードベース全体の場合： まず、自社コード内のレガシー／フォールバックの発生箇所を検索します。生成ファイル、ベンダーコード、ビルド出力、キャッシュ、ロックファイル、適用済み移行の履歴は、問題として指定されていない限り対象外です。レガシーな列／テーブルを削除する新しい移行コードは、この整理の対象として認められます。

経路がまだ必要かどうかが曖昧で、削除すると本番環境や公開 API が壊れる場合は、要点を絞った質問をひとつしてください。それ以外の場合は、前提を明示し、根拠を示して作業を進めてください。

レガシー／フォールバックに該当するもの

新旧の世界を併存させるために存在するコードは、削除対象として扱ってください。

• 非推奨の API、二重実装、互換性シム、「古いクライアント向け」のアダプター
• デフォルトが恒久的に「新」になっており、古い分岐が使われていない機能フラグ／環境変数による切り替え
• 二重読み書き、移行期のキャッシュ、一時的なリダイレクト、サポート対象のランタイムで不要になったポリフィル
• コメントアウトされた古い実装、#ifdef形式の使われない分岐、TODO: remove after migration
• 移行漏れを隠すフォールバック値／分岐（|| oldField、?? legacyDefault、古いデータ形状を維持するためのanyキャストなど）
• 古い経路だけをテスト、再現、説明するテスト、フィクスチャ、ドキュメント、型定義

パターンの一覧：legacy-patterns.md。

ワークフロー

1. 候補を探す

legacy-patterns.mdにある手掛かりを検索します。候補ごとに以下を記録してください。

• 場所
• 維持されている古い動作
• 正規の現行経路
• まだ必要である、または安全に削除できることを示す根拠
• 削除のリスク（公開 API、データ形式、クライアント、本番環境でまだ有効なフラグ）

2. 維持するか削除するかを決める

判断	条件
今すぐ削除	呼び出し元／設定が残っていない、フラグのデフォルトが恒久的に新になっている、サポート対象のクライアントがすべて新しい経路を使用している、またはユーザーが破壊的変更を許可している
移行して削除	呼び出し元／データがまだ古い経路を使っているが、ユーザーが整理を望んでいる — 同じ作業内で移行してから削除する
維持（報告のみ）	サポート対象のクライアント、実施中のロールバック、または法令／コンプライアンス上の保存のためにまだ必要 — 担当者と終了条件を記載する

「中途半端な」レガシーを残さないでください（コメントアウトされたコード、未使用のフラグ、空のシムファイルなど）。削除するか、具体的な終了条件とともに維持が必要な理由を記録してください。

3. 完全に削除する

それぞれの削除対象について：

1. 残っているすべての利用箇所を正規のパスに切り替えます（または、レガシーのためだけに存在していた利用箇所を削除します）。
2. レガシー実装、型、エクスポート、フラグ、環境変数の設定処理、アダプターを削除します。
3. 現在の動作のみを検証するよう、テストを削除または書き換えます。
4. 古いパスについて説明しているドキュメントやコメントを更新します。
5. レガシー名を公開するためだけに存在していた再エクスポートやバレルを削除します。
6. ユーザーが外部クライアント向けの一時的な互換性のない変更を必要とする場合を除き、「非推奨」として例外をスローするスタブ関数を残さないでください。内部コードでは、コンパイル時に削除する方法を優先します。

詳細：removal-checklist.md。

4. 検証する

変更した箇所に関連する、最も範囲の狭い型チェック、Lint、テスト、ビルドを実行します。削除した名前やフラグをもう一度 grep し、残存箇所がないことを確認します。

検証を実行できない場合は、スキップした内容を明記します。

完了レポート

• 調査した範囲
• 削除したもの：パス／フラグ／シム → 正規の置き換え先
• 維持したもの（終了条件を含む）：引き続き必要なもの
• 残存箇所の検索対象
• 実施した検証と結果