principle-migrate-callers-then-delete-legacy-apis について
破壊的な API 変更を一括で進められるプロジェクト向けのリファクタリングスキルです。互換レイヤーを標準で維持せず、同じ改修で内部の呼び出し元を移行し、旧 API を削除する方針です。
主な機能
- 01既存 API の呼び出し元を洗い出す
- 02呼び出し元を新 API に移行
- 03同じ改修で旧 API を削除
- 04新しい契約に合わせてテストを更新
- 05アダプターは一時的な例外として扱う
活用シーン
- 01外部互換性が不要な内部 API の簡素化
- 02複数の呼び出し元にまたがる破壊的 API 変更の調整
- 03リファクタリング前の実装詳細だけを保護するテストの削除
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mdsmithaustin/ pstack --skill principle-migrate-callers-then-delete-legacy-apisインストール後、Claude Code で/principle-migrate-callers-then-delete-legacy-apisを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
呼び出し元を移行してからレガシー API を削除する
新しい API が適切な設計だと判断した場合は、互換性レイヤーを残すのではなく、同じリファクタリングの段階で呼び出し元を移行し、古い API を削除します。
ルール:
- 内部の呼び出し元がまだ存在するという理由だけで、レガシー API の経路を残さないでください
- 呼び出し元を洗い出し、移行して、古い API を直ちに削除してください
- 一時的なアダプターは例外的かつ期限付きのものとして扱い、標準的なアーキテクチャにしないでください
- テストを新しい契約に沿って更新し、リファクタリング前の実装の詳細だけを保護するテストは削除してください
この方針が当てはまる場合:
- 外部ユーザーが後方互換性に依存していない
- プロジェクトが連携した破壊的変更に対応できる
- 新しい API が簡素化またはリファクタリングの取り組みの一部である
古い API と新しい API の両方を残すと、二重経路による複雑さが生じ、クリーンアップが遅れ、コードベースが追加専用のように感じられます。
コメント
Markdown 対応