Refactor
Reorganizing code to make it cleaner and easier to change, without changing what the app does.
Before
- One 2,000-line file
- Duplicated logic
- Same behavior
After
- Small, named pieces
- Shared helpers
- Same behavior
What it is
To refactor is to restructure existing code (splitting a huge file, removing duplication, renaming things clearly) while keeping the app's behavior identical. Users shouldn't notice anything.
Refactoring pays off when an app has grown messy and every change starts breaking something else. It's like reorganizing a cluttered kitchen: nothing new to eat, but cooking gets faster.
Keep refactors separate from new features. Mixing them makes it hard to tell what caused a new bug.
How to ask for it
“The code is a mess, fix it.”
“Refactor the checkout code into smaller pieces (cart, shipping, payment) with no change in behavior. Don't add features in this step, and confirm a full test purchase still works afterward.”
"Fix the mess" is open-ended; "refactor" with "no behavior change" and a check sets clear boundaries.
You've seen this in
- EEngineering teams scheduling "cleanup" sprints
- AApps getting faster to update after a rewrite
- CCommit messages like "refactor: split checkout"