5 exercises on technical debt and refactoring vocabulary.
0 / 5 completed
1 / 5
In Fowler's technical debt quadrant, what is prudent inadvertent debt?
Inadvertent + Prudent: "Now we know what we should have done." You learned by building. The original design seemed correct. Use discovered a better approach. This is normal and expected. Fowler quadrant: Deliberate+Prudent ("ship now, fix later — we have a plan"), Deliberate+Reckless ("no time for design"), Inadvertent+Prudent ("now we know better"), Inadvertent+Reckless ("what is layering?"). Most dangerous: Deliberate+Reckless (knowingly creates mess) and Inadvertent+Reckless (pure ignorance). Best managed: Deliberate+Prudent (if you actually pay it back).
2 / 5
What is the strangler fig pattern for migrating legacy systems?
Strangler fig (Fowler 2004): key elements: routing façade (API gateway, reverse proxy, feature flag), new system built incrementally alongside the old, traffic gradually shifted one domain at a time, old system decommissioned when traffic reaches zero. Why better than big-bang rewrite: each migration ships to production (validates correctness continuously), business features continue shipping during migration, rollback is possible at any point, team learns the domain by migrating it. Related: Branch by abstraction (create abstraction layer, swap implementation behind it), Parallel change/expand-contract (for API/schema changes).
3 / 5
What is refactoring in the strict sense?
Refactoring (Martin Fowler): behavior-preserving. The external behavior does not change — only the internal structure. Critical: tests must pass throughout. Never refactor without tests (or add tests first — "don't change code without tests" is the golden rule). Common refactorings: Extract Method, Move Method, Rename, Inline, Extract Class, Replace Conditional with Polymorphism, Introduce Parameter Object. Refactoring vs rewriting: refactoring is incremental and safe (tests verify); rewriting is risky (big-bang, behavior often changes). Code smells: structural patterns indicating refactoring opportunities (Long Method, God Class, Feature Envy, Primitive Obsession).
4 / 5
What is a debt register?
Debt register: treats debt as a balance sheet liability. Per-item fields: ID, description, area of codebase, type (design/test/infrastructure/documentation), principal (fix cost in story points), interest rate (slowdown hours/sprint), total interest to date, owner, priority (interest rate / principal = ROI). High ratio = pay this first. Executive communication: "This authentication refactor costs 2 sprints to fix. It costs us 4 hours/sprint in slowdown. At fully loaded engineer cost, it pays back in 12 sprints." Vague backlogs fail because items compete with features on no objective basis and are never prioritized. Debt register makes ROI explicit.
5 / 5
What is a deprecation path for an internal API?
Deprecation path elements: Announcement: early, multi-channel (email, Slack, docs update). Include: what, why, replacement, timeline. Machine-readable signals: HTTP Deprecation header (RFC 8594) with sunset date. Compiler warnings in SDKs. Usage dashboard: logs showing which callers still use the deprecated endpoint — without this you can't know when it's safe to remove. Migration guide: code examples of before/after. Graduated pressure: warnings → throttling → hard removal. Firm sunset date: soft deadlines extend forever. External API deprecation: longer notice periods (6-12+ months), stricter SLAs. Internal deprecation can be faster with complete caller visibility.