There will be many times in our careers when we support legacy code. Sometimes, in a new job, modifying legacy code is one's first assignment, or perhaps the company reorganizes and a legacy product ends up among an Agile team's assets. In fact, to stretch the definition a bit, we could consider any code written before today to be legacy code. Both situations are challenging and potentially risky if a team doesn't have a strategy in place for handling legacy code.
Incremental Test Driven Development is fine for brand new code... but how does one get started with a code base that doesn't have a regression suite? The traditional approach is to start making changes while doing your best to avoid unintentional collateral damage. Unfortunately, because the code is unfamiliar, you aren't sure what's really going to happen when you change a data structure or update a variable. This leads to interesting kluges when developers re-invent the wheel rather than refactoring code not supported by unit tests, bloating the code and making it still harder to maintain.
How does one avoid these pitfalls of working with existing code? Jared Richardson, author of ShipIt!, says in this exclusive InfoQ arcticle:
"Rather than wandering into this minefield blindly, let's create a plan of attack. Don't just start making changes and hope that everything still works. Instead, take aim and hit it out of the park with a 'BAT': Build, Automate, and Test. ...In addition to this article on testing legacy code, Jared has made a sample chapter of Ship It! available for InfoQ readers.
The BAT approach will ensure that your code continues to work the way you want it to work. It quickly catches unintended side effects and helps you to eliminate them."