Martin Fowler wrote an important book in the canon of software engineering more than 20 years ago. In it, he attempted to distill the ways that existing software can be improved. Since then, he has published a second edition and now, an online one as well. Though he didn’t invent the term, his book helped popularize “refactoring” and it is used even among non-professionals to refer to any kind of maintenance or upkeep activity. In elementary algebra, the term “factoring” refers to finding a multiplier that can be extracted from an algebraic expression without changing its veracity, often as part of a process of solving an equation. Similarly, refactoring in software is the practice of identifying ways that the code can be changed for the better without altering its functionality.
Though it may seem counter-intuitive that a purely intellectual abstraction like software code can deteriorate, as if it were a physical object, in fact, software constantly atrophies. It atrophies in several ways:
- Context change: even software that is functioning perfectly well must live in an environment that itself is changing. In this way, relative to its environment, the software has changed, often in ways that reduce its functionality or make it completely unable to perform its prescribed task.
- Functionality change: in the evolution of a software system, often it needs to be extended; the act of doing so can lead to code that is more complex, hard to comprehend and increasingly costly to support.
So, refactoring is a never-ending activity that software organizations must budget into their development effort. That said, the more regularly it is done, particularly as part of the rhythm of feature development, the easier it is. This is because as the code atrophies, it tends to deteriorate faster and into a less maintainable state, as one extemporization is piled on top of another. Constant vigilance is the watchword; a good refactoring practice is like tending a garden: don’t let the weeds take over!
Fowler goes further to distill patterns from software that often indicate a need for refactoring; he calls these “bad smells”. Further, he distills a number of canonical refactorings that he states are widely applicable and provides the conditions under which they…
