Refactor for Life
In the {End Bracket} column for the July issue of MSDN Magazine, Eric Bush wrote about the nature of software systems to become a tangled web of legacy code, and the need for refactoring to simplify maintenance and ongoing development.
Software systems tend to become increasingly disordered and complex as they are developed. When software reaches that critical point where it has aged and cannot be maintained, we bestow upon it the venerable title of Legacy Code. It might sound prestigious in another field, but when it comes to software, Legacy Code is a title no one is anxious to own.
Prior to arriving at Microsoft, I can only think of one software project I worked on that did not include legacy code. Every other project contained significant legacy code written by numerous developers with varying levels of expertise. In retrospect, I think I spent two-thirds of my time working in the legacy code instead of writing new code. I didn’t know it as refactoring at the time, but I frequently engaged in refactoring without the benefit of unit tests (also unknown to me at the time) to prevent regressions. Instead, I would make small changes, compile, and run the code to see what broke.
I think if I had tools at my disposal such as Visual Studio’s refactoring and unit testing features, I would’ve spent far less time in legacy code and more time implementing new features. Put simply, the proper use of refactoring and unit testing are important contributors to developer productivity.
954