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

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

github.com/q-qp-p開発146 回インストール2 週間前に更新
リポジトリ

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

このスキルは、内部 API の置き換え時に呼び出し元を新しい契約へ移行し、同じ変更単位で旧 API を削除する方針を示します。外部互換性を保つ必要がなく、破壊的変更を調整できるプロジェクト向けです。

主な機能

  1. 01既存 API の呼び出し元を調査
  2. 02呼び出し元を新契約へ移行
  3. 03旧 API の経路を削除
  4. 04新契約に合わせてテストを更新
  5. 05例外的なアダプターに期限を設定

活用シーン

  1. 01リファクタリングで内部 API を簡素化
  2. 02外部互換性が不要な場合の破壊的変更の調整

インストール

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

$npx skills add https://github.com/q-qp-p/pstack --skill principle-migrate-callers-then-delete-legacy-apis

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

詳細

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

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

ルール：

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

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

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

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

コメント

Markdown 対応