mcpField
P
principle-migrate-callers-then-delete-legacy-apis

principle-migrate-callers-then-delete-legacy-apis

github.com/hachej開発160 回インストール1 日前に更新
リポジトリ

principle-migrate-callers-then-delete-legacy-apis について

新しい API で内部の旧 API を置き換えるリファクタリング向けのコーディングスキルです。外部互換性が不要な場合に、呼び出し元の移行、旧 API の削除、テストの更新を同じ変更で進めます。

主な機能

  1. 01呼び出し元の洗い出しと移行
  2. 02旧 API パスの削除
  3. 03一時アダプターの制限
  4. 04新しい契約のテスト

活用シーン

  1. 01外部互換性が不要な内部 API のリファクタリング
  2. 02新旧 API パスの併存解消
  3. 03協調的な破壊的変更に伴うテスト更新

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/hachej/boring-stack --skill principle-migrate-callers-then-delete-legacy-apis

インストール後、Claude Code で/principle-migrate-callers-then-delete-legacy-apisを入力して読み込まれたか確認します。

同梱ファイルLICENSE

詳細

呼び出し元を移行してからレガシー API を削除する

新しい API が適切な設計だと判断した場合は、互換性レイヤーを残すのではなく、同じリファクタリングの段階で呼び出し元を移行し、古い API を削除します。

ルール：

  • 内部の呼び出し元がまだ存在するという理由だけで、レガシー API の経路を残さないでください
  • 呼び出し元を洗い出し、移行して、古い API を直ちに削除してください
  • 一時的なアダプターは例外的かつ期限付きのものとして扱い、標準的なアーキテクチャにしないでください
  • テストを新しい契約に沿って更新し、リファクタリング前の実装の詳細だけを保護するテストは削除してください

この方針が当てはまる場合：

  • 外部ユーザーが後方互換性に依存していない
  • プロジェクトが連携した破壊的変更に対応できる
  • 新しい API が簡素化またはリファクタリングの取り組みの一部である

古い API と新しい API の両方を残すと、二重経路による複雑さが生じ、クリーンアップが遅れ、コードベースが追加専用のように感じられます。

コメント

Markdown 対応