Themes

We’ll work through an example of incrementally improving a legacy codebase. You’ll learn a handful of specific techniques, each tailored to the specific legacy challenge at hand. The approaches you’ll learn are a subset of at least a couple dozen such techniques found in Working Effectively with Legacy Code [Fea04] and elsewhere. You’ll discover that the techniques are simple to learn and that once you’ve learned a handful, it’s pretty easy to figure out many of the rest.

Core themes for approaching legacy challenges include the following:

• Test-drive whenever you can. Test-drive code changes into either new members or even new classes when possible.

• Don’t decrease the test coverage. It’s very easy to introduce a small amount of code and then dismiss it as “only a few simple lines.” Every line of new code for which you don’t have a test results in lower coverage.

• You’ll have to change existing code to write tests! Legacy code doesn’t easily accommodate tests in many circumstances, largely because of dependencies on challenging collaborators. You’ll need a way of breaking these dependencies before you can write tests.

• There are a number of small, constrained code changes that entail minimal risk. You can manually make small and safe code transformations using one of a number of techniques.

• Everything you type represents risk. Even a single mistyped character can introduce an insidious defect that can waste hours. Type as little as possible, and think every time you press a key.

• Stick to small, incremental changes. It works for TDD; it can also work for legacy code. Taking larger steps will get you in trouble.

• Do one thing at a time. When tackling legacy code, avoid combining steps or goals. For example, don’t combine refactoring while at the same time trying to write tests.

• Accept that some incremental changes will make the code uglier. Remember, one thing at a time. You might require a few more hours to do the “right” thing. Don’t wait—commit the working solution now, because you might not end up having the full few hours you need.

  And don’t be too concerned about offending some design sensibilities in the meantime. You may eventually find the time to return to clean up the code. You may not, but it’s still an improvement. You’ve taken steps in the right direction, and you can prove that everything still works.

• Accommodate incremental improvements to the periphery of your change. Faced with a monstrous codebase, adding tests only when you touch relevant code won’t make a terribly large dent. More important is the mentality that everything new going in gets tested.

  With an always-test mentality in place, you can begin to take advantage of the tests you add. With every test you make pass, take a look around the area you just covered with tests. There’s almost always an opportunity for a small, safe bit of refactoring. You’ll also discover how much easier it is to write a second test once you’ve written a first. You can accommodate such little bits of improvement here and there without impacting your ability to deliver, and you’ll begin to make a larger dent in the challenging codebase.