Refactoring & Code Quality
Refactoring Workflow & Tooling
Refactoring works as a practiced discipline, not a one-off event: wear one hat at a time, lean on version control as an undo button, and prefer automated tool support over manual edits wherever it exists.
- "Two hats" — adding function and refactoring are different modes of work; switch consciously between them, never blend
- Commit after every small, green refactoring step — version control becomes a reliable undo button, not just a backup
- Automated IDE refactorings (Rename, Extract, Move) rewrite every reference correctly and are safer than manual find-and-replace
- Continuous integration turns "did this break anything" from an end-of-week surprise into immediate feedback
- A refactor buried inside a large feature PR is effectively unreviewable — nobody can tell what changed for what reason
The "two hats" metaphor: when adding a feature, you're not supposed to be restructuring existing code, and when refactoring, you're not supposed to be adding behavior. In practice these interleave constantly — add a feature, notice the code resists it, switch hats and refactor to make room, switch back — but at any given moment only one hat is on. Losing track of which hat you're wearing is exactly how "just a quick refactor" grows a new feature nobody asked for review on, or "just a quick feature" quietly restructures something without test coverage for the restructuring.