Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS


Jared Richardson Most Popular
Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers



Blog Archive
2005-December
2005-November
2005-October
2005-September
2005-August
2005-July
2005-June

Sun, 04 Dec 2005

Help! I've Inherited Legacy Code

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

posted at: 19:21 | path: | permanent link to this entry

Common Problems and How to Fix Them

The last chapter in Ship it! A Practical Guide to Successful Software Projects is called Common Problems and How to Fix Them (also known as the FAQ). The chapter is a series of FAQ-esque entries with some solutions to those problems. I'm going to mix in a few of the topics as blog entries over the next few weeks.

If you've read the book and would like to see a particular entry published, let me know. Also, if you have an entry or answer you'd like to see expanded, this would be a great time to ask. :)

Thanks!

Jared

posted at: 19:19 | path: | permanent link to this entry