Page 140 -

T HERE’S A FAMOUS QUOTE ATTRIBUTED TO KENT BECK, a widely respected software engineer

who’s responsible for many advances in the field: “I’m not a great programmer; I’m just a
good programmer with great habits.” This chapter is about introducing some of those great
habits. A good programmer who adopts these habits will build better software.
Programmers spend their time designing and building software, and all of their project
work revolves around the source code. But many programming teams find that they lose
control of their own code. Sometimes they lose track of the changes that they make; new
additions might occasionally disappear, and old bugs routinely pop up. They might lose
control of the design of the code, finding that no matter how much care they put into
designing the software well, they still end up with messy code that’s difficult to maintain.
Some programmers have never known any other way, and don’t realize that these prob-
lems can be eased. A project manager can improve the code by helping the team adopt
good programming practices.

While many development problems originate outside of the programming team, there are
some basic changes that the programmers can make that will improve the quality of the
code they produce. Most teams, even ones with skilled and talented programmers, are
vulnerable to the same design and programming problems. These problems can be
addressed with a few basic tools and techniques—which can often be put in place entirely
within the programming team, without involving anyone else in the organization.
A programming team that adopts the tools and techniques in this chapter will avoid many
common project pitfalls. This chapter only covers their most fundamental use—there are
many advanced operations that can be done with all of them that are not covered here.
With these practices in place, the team will find that they have a much firmer grasp on
their own source code. If these tools are not yet in place, working with the programmers
to implement them should be high on the project manager’s priority list.

Much of this chapter is an introduction to refactoring and unit testing. Many experi-
enced programmers will recognize that refactoring and unit testing are important skills
that require practice, reading, and training. We tried to write this book in such a way
that someone could read each chapter and immediately use the tools and techniques on
a project. Unlike the other practices, however, we don’t expect the reader to be able to

fully develop unit tests or refactor code after reading this chapter, any more than we
would expect to be able to give a thorough presentation of object-oriented programming
in one section of a chapter. Instead, our goal is to give the reader an introduction to the
theory and practice of both refactoring and unit testing, illustrated with simple examples
of each.

132 CHAPTER SEVEN