Refactoring
Changing structure without changing behaviour, in verified steps.
3 to work through
-
intermediate
A team schedules a large refactoring project and it is repeatedly deprioritised. What approach actually gets refactoring done?
2 min answer -
advanced
An enterprise software vendor of SAP's shape must replace a logging call used at 2,400 sites across 1,100 files owned by 40 teams. The codemod itself takes an afternoon to write. Sequence the change so it lands once and stays landed.
3 min answer -
advanced
Figma's database stack grew roughly 100x between 2020 and 2024. Rather than rewriting the application to be shard-aware in one step, the team vertically partitioned first, then introduced logical sharding, where queries still ran against a single database but were routed as if it were already sharded. Why is that intermediate step worth its cost, and what does it find that a cutover cannot?
3 min answer
5 terms in this topic
Branch by Abstraction
Making a large change incrementally on the trunk by introducing an abstraction over the old implementation, building the new one behind it, then remo…
practicePreparatory Refactoring
Reshaping existing code first so the behaviour change that follows is small, keeping the two in separate commits with separate claims about what is true.
practiceQuality Ratchet
An automated rule ensuring a codebase can only improve on a chosen dimension - new code meets the standard, existing code improves when touched, and …
practiceRefactoring Under Test
Changing internal structure without changing behaviour, with tests as the mechanism that makes the claim verifiable.
practiceShadow Planning
Running a new routing or planning layer over live production traffic without serving its results, so the work it cannot handle is enumerated from rea…
Neighbouring topics
Software Architecture
General material on the engineering underneath an architecture.
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.