In 30 seconds
- Small, behaviour-preserving changes to make code cleaner.
- Tests confirm nothing broke.
- Done continuously, not as a separate project.
What it is
Martin Fowler's 1999 book Refactoring defined it as changing a program's internal structure without changing its external behaviour. Each step is small and safe; many small steps add up to a big improvement.
Common refactorings
- Rename a variable or function to reveal intent
- Extract a function from a long one
- Remove duplicated code
- Replace conditionals with clearer structures
Making time for it
Refactor as part of the work that needs it, the third step of TDD's red-green-refactor cycle. Leave code a little better than you found it. This keeps technical debt in check without separate projects.
Myth vs reality
Myth · Refactoring means rewriting.
Reality · It's small, safe, behaviour-preserving changes.
Myth · Refactoring needs its own stories.
Reality · Usually it belongs inside feature work.
Myth · Refactoring without tests is fine if careful.
Reality · Tests are what make it safe.
The AI angle
AI can perform mechanical refactorings at scale. Keep the same discipline: small steps, tests after each one, and human review of anything that changes behaviour.
FAQ
How do I know refactoring is safe?
Run tests after each small step.
When should I not refactor?
When the code is about to be deleted or deadlines are immediate.
Do IDEs help?
Yes, many common refactorings are automated.