Listen to this post
Refactoring is defined by Martin Fowler as “improving the design of existing code.” Refactoring stipulates two things: that behavior does not change, and that the design has been improved. While developers have been “cleaning up” their code from the very early days, Fowler made this a discipline that developers can collaborate within. He defined a shared way to do it.
In TDD, we support refactoring by ensuring that all code has behavioral tests associated with it, which can then be used to ensure behavior has not, in fact, changed.
Refactoring is also part of the TDD process itself.
Learning how to refactor efficiently and effectively takes time and effort, often through training and coaching/study sessions. The skills gained through this effort apply to multiple aspects of development.
- It is used to improve legacy code, which is often functional but expensive to work with due to a weak design.
- It helps developers to keep production code and test code from decaying over time.
- It enables just-in-time design where code is refactored immediately proximate to changes being made, in order to make those changes safer and cheaper.
Learning strong refactoring skills isn’t free, but it pays the organization back in many ways.