How often do you find yourself refactoring code?
Why?
Refactoring, by definition makes no change to the behavior of your code.
This seems to bother some people in interesting ways. In particular, I see people treating code refactoring as if it had customer-facing value.
Have you ever seen a “user story” about refactoring?
Have you ever thought or said “If this code needs to be refactored, QA will let me know”?
Has anyone ever said “We have a bug, refactoring will fix it”?
These are all examples of conflating refactoring with user-facing value.
If the change your making has direct customer impact, it’s not a refactoring. If it adds functionality or improves performance, then it’s not a refactor. If it is a refactor, it only changes the code structure.
So why bother with refactoring if it provides no direct customer value?
We refactor code to “to make it easier to understand and cheaper to modify”.
In other words, from an end-user standpoint, refactoring is always about the secondary effects. It’s about what it enables us to do later, not about what the refactoring itself does.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)