![](https://csdnimg.cn/release/download_crawler_static/6961433/bg11.jpg)
16
tons of reference material for coding style and standards. Like many things, developers will follow the standard
if they voluntarily create it and buy into it.
Adopting XP?
As we've stated before, you do not have to adopt XP to get value out of this book. For example, automated
testing can help you refactor code regardless of whether you are doing pair programming.
Here's another example: If you use Unified Modeling Language (UML) use cases with a CASE tool instead of
stories written on index cards, continuous integration and small release cycles will still be beneficial for getting
rapid feedback. The point is, you may decide to do things in addition to the process. Or, your corporate culture
may have an adverse reaction to things like pair programming.
UML and CASE Tools
Some XP advocates swear by never using CASE tools. They say that the only UML should be written with a
pencil on an index card. I don't agree. As long as the CASE tool can continually keep the model in sync with
the code, the tool can be very beneficial. In addition, some CASE tools can speed development by
generating the necessary boilerplate code for design patterns.
Beck notes that whether you draw diagrams that generate code or write out code, it is still code.
One of the first areas to focus on when adopting XP is automated testing. Begin by writing tests for code that
you are about to add functionality to, refactor, or fix. The key is to add automated tests slowly to code written
before you adopted XP, and always employ automated testing with newly developed code. Do not write tests
for code you are not working on. Later, when you begin doing integration tests, you will want to automate the
build, test, and integration cycle.
My company has adopted XP. We adhere to the 12 XP practices. However, I am not a purist. I believe that
other software processes can benefit from automated testing, simple designs, continuous integration,
incremental releases, and constant refactoring.
Beck states that XP's 12 practices will not fit every project. XP also will not fit every organization's culture.
Regardless, J2EE development can benefit from automated testing, simple designs, continuous integration,
incremental releases, and constant refactoring. This book focuses on tools to perform automated testing and
continuous integration for J2EE to enable refactoring and incremental releases.
Summary
XP is a lightweight methodology that focuses on coding as the main task. XP is based on four values:
communication, simplicity, feedback, and courage. Communication is facilitated through pair programming,
task estimation, iteration planning, and more. Simplicity means avoiding making things overly complicated and
insisting that the basics be addressed first and foremost. Feedback is given by way of testing, customer
stories, small iterations/frequent deliveries, pair programming/constant code reviews, and so on. Courage
means the courage to do what is right whether you have to refactor a working system, throw code away,
cancel a project, or insist on quality.
XP is based on five principles: rapid feedback, assuming simplicity, making incremental changes, embracing
change, and doing quality work. In his landmark book on XP, Beck iterated four basic practices: coding,
testing, listening, and designing. These practices are expressed further in 12 major areas of practice: the
planning game, small releases, simple design, (automated) testing, continuous integration, refactoring, pair
programming, collective ownership, a 40-hour week, an on-site customer, metaphor, and adherence to a
coding standard. This book focus on two practices of XP: automated testing and continuous integration.
XP encourages full integration testing not on a weekly or monthly basis or at the end of a project, but daily.
Daily integration and integration/functional testing ensure that you'll catch problems early. Such testing is hard
to do with J2EE.
Thus, in order to provide continuous integration and automatic testing, you will need tools to help with the
deployment of J2EE applications. To accomplish continuous integration in this complex system, you need a
way to automate the integration process. You need to automate the build, test, and deployment cycle.
Up next is Chapter 2
, "J2EE Deployment Concepts," which covers the J2EE component model, deployment
descriptors, and the challenges of deploying and testing in a J2EE environment.