This post originated from an RSS feed registered with Agile Buzz by Jared Richardson. Original Post: Help! I've Inherited Legacy Code Feed Title: Jared's Weblog Feed URL: http://www.jaredrichardson.net/blog/index.rss Feed Description: Jared's weblog. The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers. Latest Agile Buzz Posts Latest Agile Buzz Posts by Jared Richardson Latest Posts From Jared's Weblog

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright © 2005 The Pragmatic Programmers LLC. All rights reserved.

Help! I’ve Inherited Legacy Code

You’ve inherited a legacy product that you will be maintaining and enhancing. What’s the quickest way to get a handle on it? Learn to build it, automate it, and finally test it.

1. Build it
First, figure out how to build it, and then script that build process. This task isn’t always easy, especially if the code has had only one owner. The code will often build on only one machine because it relies on the surrounding environment. Once complete, anybody can build the product on any machine. After that, it should be easy to automate the builds.

2. Automate it:
Your goal is to automatically build and test the entire product on a clean machine with an absolute minimum of manual intervention. We didn’t say no manual intervention; there’s a balance here. Sometimes it’s easier to manually install and configure a supporting piece of the environment than to write a script to do it automatically. Apps that you install only once are prime candidates (compilers, etc.). Document all the build steps and make this documentation publicly available.

3. Test it:
Figure out what the code does, then begin testing by writing mock client tests for it (see the sidebar on page 45). Once you have the project building cleanly, you’ll want to confirm that it works. In order to write the tests, you’ll have to learn exactly what the product is supposed to do (no surprise there).

Mock client tests are a good starting point: they test the broad functionality of a product because they act just as a product user would.

4. Test it more:
Figure out the product’s innards (things such as structure, flow-of-control, performance, and scalability), and write more tests for it. Unless the product is completely unused, there will be bugs you’ll need to fix (or at least document) or enhancements you’ll have to make. Normally these changes are a pretty scary thing to do to legacy code, because you’re never quite sure what you’re going to affect when you make a code change. But you can do this fearlessly because of the mock client tests you wrote as a safety net; they’ll keep you from breaking things too badly. (You did write those tests, didn’t you?)

Write a new test for every bug you fix and for every enhancement you add to the product (see Defect Driven Test Creation). The type of test you write will depend on what you’re changing (e.g., a unit test for a low-level internal change, or a mock client test for a new feature). At this point you’re treating the legacy product in the same way you would any other product you support.

After you’ve done all this, anybody will be able to support this code! They’ll be able to automatically build it anywhere and then confirm it’s working correctly by running the automated tests on their desktop. And the automated build system will run the build and tests again in a clean environment to be sure that everything is really still working.

The Tip?
Don’t change legacy code until you can test it