Creating great software is an art. If you ask a dozen programmers to solve a particular problem, you are likely to get a dozen radically different solutions. If you observe how these programmers reach their solutions, you will note that each programmer has her own favorite set of tools. One programmer may start by designing the application architecture using a UML CASE tool. Another may use wizards included with a fancy IDE, while another is perfectly content to use Emacs or vi.
Differences in opinion also manifest themselves at the team and company level. Some companies feel most comfortable with enterprise class commercial tools, while others are perfectly happy to build their development environment using a variety of open source tools. XP works regardless of which tools you choose, provided that your tools support continuous integration and automated unit testing. These concepts are detailed in the next chapter.
Warning
We are very skeptical of the term "enterprise class.” This tends to be a marketing ploy, and actually means “the features you really need,” such as integrated support for free tools like JUnit, Ant, and CVS.
Many commercial IDEs focus very heavily on graphical “wizards” that help you automatically generate code, hide complexity from beginners, and deploy to application servers. If you choose such a tool, make sure it also allows for command-line operation so you can support continuous integration and automated unit testing. If you are forced to use the graphical wizards, you will be locked into that vendor’s product and unable to automate your processes. We strongly recommend XDoclet, Covered in Chapter 9, for automated code generation. This is a free alternative to wizard-based code generation and does not lock you into a particular vendor’s product.[2]
This book does not cover commercial development environments and tools. Instead, we show how you can use free tools to build your own development environment and support XP practices. Perhaps in a sign of things to come, more and more commercial development environments now provide direct support for the open source tools covered in this book. With free IDEs like Eclipse and Netbeans growing in popularity and functionality, you will soon be hard-pressed to justify spending thousands of dollars per developer for functionality you can get for free.[3]
Regardless of whether you choose to use open source or commercial tools, XP works most effectively when your tool selection supports the concepts mentioned at the beginning of this chapter. These three concepts are automation, regression testing, and consistency among developers.
XP requires automation. In an XP project, programmers are constantly pairing up with one another and working on code from any given part of the application. The system is coded in small steps, with many builds occurring each day. You simply cannot be successful if each programmer must remember a series of manual steps in order to compile, deploy, and test different parts of the application.
People often talk about “one-button
testing” in XP, meaning that you should be able to
click a single button—or type a simple command like
ant
junit—in
order to compile everything, deploy to the app server, and run all
tests.
Automation also applies to repetitive, mundane coding tasks. You increase your chances of success by identifying repeating patterns and then writing or using tools to automatically generate code. Automation reduces chances for human error and makes coding more enjoyable because you don’t have to spend so much time on the boring stuff.
Automated regression testing is the building block that makes XP possible, and we will spend a lot more time talking about it in the next chapter. Testing, most notably unit testing, is tightly coupled with an automated build process. In XP, each new feature is implemented along with a complementary unit test. When bugs are encountered, a test is written to expose the bug before the bug is fixed. Once the bug is fixed, the test passes.
Tools must make it easy for programmers to write and run tests. If tests require anything more than a simple command to run, programmers will not run the tests as often as they should. JUnit makes it easy to write basic unit tests, and more specialized testing frameworks make it possible to write tests for web applications and other types of code. JUnit has been integrated with Ant for a long time, and most recent IDEs make it easy to run JUnit tests by clicking on a menu and selecting “run tests.”
In a true XP
environment, developers are
constantly shuffling from machine-to-machine, working with new
programming partners, and making changes to code throughout a system.
To combat the chaos that might otherwise occur, it is essential that
tools make every developer’s personal build
environment identical to other team members’
environments. If Alex types ant
junit and all tests pass, Andy and Rachel
should also expect all tests to run when they type the same command
on their own computers.
Providing a consistent environment seems obvious, but many IDEs do
not support consistent configuration across a team of developers. In
many cases, each developer must build his own personal project file.
In this world it becomes very difficult to ensure that Andy and
Rachel are using the same versions of the various JAR files for a
project. Andy may be using an older version of
xalan.jar than everyone else on the team. He may
then commit changes that break the build for everyone else on the
team for a few hours while they figure out the root of the problem.
[2] XDoclet allows you to generate any kind of code and thus works with any application server.
[3] Both authors use IntelliJ IDEA, a commercial IDE available at http://www.intellij.com. Although it costs around $400, we feel its refactoring support easily adds enough productivity to justify the cost.
Get Java Extreme Programming Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
