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

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

github.com/poteto開発16198 回インストール22 週間前に更新
リポジトリ

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

連携した破壊的変更が可能なプロジェクト向けのリファクタリングスキルです。内部の呼び出し元を新 API に移行し、同じリファクタリングで旧 API を削除する方針を示します。

主な機能

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

活用シーン

  1. 01リファクタリング時の内部 API の簡素化
  2. 02古い互換経路の削除
  3. 03API 契約変更後のテスト更新

インストール

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

$npx skills add https://github.com/poteto/plugins --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 の両方を維持すると、二重経路による複雑さが生まれ、整理が遅れ、コードベースが追加一辺倒に感じられるようになります。

コメント