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

Migrate Callers Then Delete Legacy APIs

When we decide a new API is the right design, migrate callers and remove the old API in the same refactor wave instead of preserving compatibility layers.

Rule:

Do not keep legacy API paths only because internal callers still exist
Inventory callers, migrate them, and delete the old API immediately
Treat temporary adapters as exceptional and time-boxed, not default architecture
Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details

When this applies:

No external users depend on backward compatibility
The project can absorb coordinated breaking changes
The new API is part of a simplification or refactor initiative

Keeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.

您可能也喜歡

constraint-driven-development

91Ktesting-qa

Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.