Refactor
Refactoring is changing the internal structure of code without changing its external behaviour. The goal is to make code easier to understand, modify, or test — not to add features. Refactoring under test coverage is low-risk; refactoring without tests is rewriting in disguise.
Martin Fowler's 'Refactoring: Improving the Design of Existing Code' is the canonical reference. The discipline distinguishes refactors (behaviour-preserving) from rewrites (behaviour-changing). A real refactor passes the same tests before and after. The most common refactor anti-pattern: bundling a refactor with a feature change, then claiming any regression was 'just the refactor' — making both changes individually verifiable is the point.
Long-form posts that explore refactor in depth — when to use it, common failure modes, how AI helps.
- Should engineers write ADRs for every architecture decision?Yes — the bar isn't 'big decision', it's 'would a new engineer six months from now wonder why we did this?' Most teams under-write ADRs.8 min read
- How to migrate from Confluence to a structured doc toolThe 30-day playbook for leaving Confluence. The hard part isn't the content move — it's deciding what NOT to move.10 min read
Related terms
- Technical debt
Technical debt is the accumulated cost of shortcuts taken during development — code that's harder to change than it should be, missing tests, outdated dependencies, or architectural choices that no longer fit.
- Regression test
A regression test verifies that previously working functionality still works after a code change.