Page 175 -

that will automatically import repositories from the most popular version systems into
Subversion. Either way, as long as the old repository is kept around in case of disaster,
migrating to Subversion can be done at any time, and it can bring immediate benefits to
both new and legacy projects.
Refactoring can also bring immediate benefits, but programmers should be careful about
how it is applied. It is generally safest to introduce refactoring in code reviews and bug
fixes. This will ensure that the benefits of refactoring are applied to where they will do the
most good: complex, difficult-to-maintain, or bug-ridden code. Refactoring can also be
implemented in new development tasks without much difficulty, as long as the program-
mers doing the refactoring feel comfortable with the task. However, it is usually a mistake
to just pick a block of code at random and try to refactor it. While the refactoring will
probably work just fine, the benefits will not be noticed by the programming team, and
they will start to question its usefulness.

Many people are uncomfortable introducing refactoring unless there are already unit tests
in place. Unit tests are often considered a necessary prerequisite for refactoring, because
they ensure that the refactoring does not change the behavior of the code. However, while
having unit tests in place is the ideal situation, it is still possible to gain many of the bene-
fits of refactoring without unit tests, as long as the refactored code is thoroughly reviewed
in order to find any defects that may have been introduced. This is another reason code
reviews and refactoring should be combined.

Unit testing should probably be avoided on large legacy code, and kept to new develop-
ment. While it is possible to develop unit tests for older code, and those tests will probably
catch defects, the process of building them will be very time consuming. This is because it’s
necessary to fully understand the behavior of a block of code before writing its unit tests,
and regaining that understanding usually requires a large ramp-up period for the pro-
grammer to familiarize herself with code that has not been touched recently. This ramp-
up will probably require a lot of reverse engineering, and may require the programmer to
dig around to recover requirements that are unclear from the code and were never writ-
ten down. Most programmers forced to go through this exercise will be turned off to unit
testing entirely. When unit testing is being introduced to an organization, it should gener-

ally be confined to new code until the programmers are comfortable using test-driven
development in their daily tasks.

Diagnosing Design and Programming Problems

There are several typical design and programming problems that can be avoided by using
the design and programming tools and techniques in this chapter. To illustrate these prob-
lems, the three following scenarios show how a programming team can grow increasingly
frustrated over the course of their software projects as a result of losing control over their
source code.

DESIGN AND PROGRAMMING 167