コードを減らすことは保守性を上げますが、「検索で0件」だけでは未使用と断定できません。
削除前の確認
- importや関数名の参照
- 文字列による動的参照
- ルート、設定、プラグイン登録
- HTMLやテンプレートからの利用
- 外部APIや公開パッケージの利用者
- ビルド時だけ使うスクリプト
小さく削除する
- 削除対象と理由を記録する
- 関連コードだけを一つの変更で消す
- 型検査、テスト、ビルドを実行する
- 主要画面を確認する
- 戻せるコミットとして残す
迷う時は観測する
利用状況が分からない機能なら、すぐ削除せずログやメトリクスで利用を確認します。公開APIは利用者へ非推奨期間を知らせる場合もあります。
コメントアウトで残さない
Gitに履歴があるなら、大量のコメントアウトを残す必要はありません。現在使うコードだけを読みやすく保ちます。
次に読む記事
ケーススタディ：旧CSV出力処理を削除する
画面から旧CSVボタンが消えて半年たったため、対応する生成関数を削除するとします。名前検索で呼び出しがゼロでも、定期ジョブ、管理者専用URL、動的import、設定文字列から参照されている場合があります。まず「利用者向け画面から消えた」と「実行経路が存在しない」を分け、ルート、ジョブ定義、権限表、監視、運用手順を確認します。
判断手順は三段階です。第一に静的参照を検索し、関数名だけでなくURL、イベント名、出力ファイル名も探します。第二に本番相当期間のアクセス数、ジョブ実行数、生成件数を観測します。第三に削除対象が担っていた副作用を列挙します。CSV本体を使っていなくても、生成時の監査記録だけが月次確認に使われていれば、関数全体の削除は別業務を壊します。
悪い例は、呼び出し検索がゼロだったため実装、テスト、設定、ドキュメントを一括削除し、後から月末ジョブが文字列指定で読み込んでいたと判明する変更です。良い例は、先に旧ルートへ観測ログを置き、十分な期間ゼロ件であることを確認し、ジョブ所有者にも用途終了を確認したうえで、実装と専用テストを一つの小さな差分で削除します。共有のCSV整形器は新経路が使うため残す、といった境界も説明します。
削除判断を止める条件は、観測期間が業務周期より短い、所有者が不明、戻す際に失われるデータがある、外部利用者との契約終了を確認できない場合です。削除後は、旧URLが意図した404または410になること、主要CSV出力が変わらないこと、ジョブ一覧と監視に孤立した参照がないことを確認します。コード行数の減少ではなく、不要経路が消え、残した経路の契約が保たれたことを完了の証拠にします。
まとめ
安全なコード削除の中心は、参照・動的利用・外部契約を確認して小さく消すことです。期待と実際を分け、条件を固定し、小さな仮説を同じ手順で検証します。成果は修正だけでなく、なぜその修正でよいと判断できたかという確認可能な根拠です。
参考リソース
関連記事
ケース：管理画面の旧CSV経路
画面からCSVボタンを消して半年でも生成関数が不要とは限りません。管理者URL、月末scheduler、文字列指定job、監査記録の副作用を確認します。「画面がない」と「実行経路がない」を分け、route登録、job定義、権限表、access log、runbookを読みます。
業務が月次なら一週間の0件は証拠になりません。一周期を含む履歴を見て所有者へ用途終了を確認します。CSV本体を誰も受け取らなくても生成件数が月次監査へ送られるなら、CSV生成と監査記録を分離して不要側だけ消します。
削除後は旧URLが仕様どおり404または410となり、現行出力の列順とencodingが変わらず、schedulerとmonitorに孤立参照がないことを確認します。公開packageのexportはrepository内0件でも外部利用者がいるため、deprecated期間とmajor version方針を確認します。所有者不明、観測不足、data復元不能、契約終了未確認なら削除を止め、その理由をissueへ残します。
削除差分のレビュー観点
factoryのcase、dependency injection登録、command名、route名、event topic、flag名を検索し、file名と異なる識別子から到達しないか確認します。fixtureやsample設定の参照も、必要なdocumentか残骸かを判断します。
古いproviderが障害時fallbackなら、通常利用0でも復旧経路です。incident runbookと切替手順を確認します。alertが旧function名やmetric名を参照していれば、実装後に監視だけ壊れます。
DB columnは読取0でも古いappが書込みを続ける場合があります。全writer更新後に観測してcolumnを落とします。queueや保存済みJSONの再処理互換性も見ます。release後はerror率、404、job失敗を観測します。commitを戻せてもdata非互換ならrollbackできないため、戻し方を説明できる範囲に変更を保ちます。
生成codeの場合、生成物だけを削除しても次のbuildで復活します。schema、template、generator設定のどれがsource of truthかを特定し、生成手順を実行して差分が再現することを確認します。逆に生成元だけ消して古い生成物を残すと、見かけ上buildが通って削除漏れになります。
license、NOTICE、migration履歴など、実行参照がなくても保存義務や監査価値があるfileもあります。unused検出toolの結果を自動削除命令として扱わず、対象の種類とrepository規約を確認します。
削除対象ごとの判断表
| 対象 | 検索以外の確認 | 中止条件 |
|---|---|---|
| HTTP route | access log、API仕様、client | 外部clientが不明 |
| batch | scheduler、runbook、履歴 | 業務周期未観測 |
| event | dashboard、集計SQL | 指標入力に残る |
| CSS class | template、CMS、E2E | 動的HTMLで利用 |
| env | deploy設定、CI、各環境 | 一環境でも参照 |
公開APIの利用アプリ担当、定期処理の運用担当、分析イベントのデータ利用者も削除判断の当事者です。「参照なし」は検索範囲内の事実であり、「利用者なし」という結論ではありません。 文字列参照、plugin登録、別repository、公開packageを除外します。
削除後の確認方法
削除と一緒に消えたimport、登録、test、documentを確認し、共有helperや現行経路のtestまで消していないか見ます。型検査とbuildだけで動的経路は保証できないため、schedulerのdry runやAPI contract testを選びます。PRには不要の根拠、検索範囲、確認した所有者、戻すcommitを記します。データ削除migrationは別変更にします。安全な削除は行数ではなく、残す契約を明示した変更です。
← 一覧に戻る
