1.2 Tools and Philosophies
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.
|
1.2.1 The IDE Philosophy
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]
[2] XDoclet allows you to generate any kind of code and thus works with any application server.
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]
[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.
1.2.2 Minimum Tool Requirements
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.
1.2.2.1 Automation
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 buttonor type a simple command like ant junitin 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.
1.2.2.2 Regression testing
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."
1.2.2.3 Consistency among developers
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.
