精通极限编程的Java工具

需积分: 0 146 浏览量更新于2024-07-24 收藏 3.27MB PDF 举报

"《Java极限编程》是一本面向Java软件开发人员的参考书籍，详细阐述了J2EE环境下的极限编程（XP）实践，特别关注测试、整合和部署等难点。作者通过基础理论介绍、示例分析，特别是对宠物商店应用的实例解析，帮助读者逐步掌握极限编程的关键技术和工具。书中涵盖了Ant进行持续集成与构建、JUnit单元测试、Cactus测试容器服务、HttpUnit的功能性测试、JMeter应用性能测量以及JUnitPerf的负载测试等多个方面。此外，还提供了Ant、JUnit、Cactus、HttpUnit和JUnitPerf的API和标签参考，为开发者提供了全面的参考资料。" 《Java极限编程》深入浅出地介绍了极限编程这一敏捷开发方法，首先简要概述了极限编程的基本理念和技术，包括其核心价值观和实践原则。然后，为了帮助有经验的Java程序员更好地理解，书中通过一个贯穿始终的应用程序示例——宠物商店，展示了工具的实际应用和开发过程中的实践操作。 Part I "Introduction and Key Concepts" 引导读者进入主题，讲解极限编程的基础知识和J2EE部署的概念，让读者对极限编程有一个初步的认识。 Part II "Mastering the Tools" 是本书的核心部分，详细介绍了各种用于极限编程的关键工具： - Chapter 4 "Continuous Integration with Ant" 详细讨论了Ant如何用于实现持续集成，这是极限编程中的重要一环，通过自动化构建来确保代码质量。 - Chapter 5和6 "Building Java Applications with Ant" 和 "Building J2EE Applications with Ant" 进一步探讨Ant在构建Java和J2EE应用中的应用，展示了如何利用Ant进行项目管理。 - Chapter 7 "Unit Testing with JUnit" 介绍了JUnit这个流行的单元测试框架，通过编写和执行测试用例，确保代码的正确性。 - Chapter 8 "Testing Container Services with Cactus" 讨论了如何使用Cactus在应用服务器内部进行测试，有效地测试和调试J2EE组件。 - Chapter 9 "Functional Testing with HttpUnit" 阐述了HttpUnit的使用，它允许开发者模拟用户对Web应用程序的交互进行功能测试。 - Chapter 10 "Measuring App. Performance with JMeter" 和 Chapter 11 "Load Testing with JUnitPerf" 分别介绍了JMeter性能测试工具和JUnitPerf负载测试工具，用于评估应用程序的性能和稳定性。 Part III "API and Tag Reference" 提供了Ant、JUnit、Cactus、HttpUnit和JUnitPerf的API和标签参考，对于开发者来说，这是一个宝贵的查阅资源，有助于他们在实际项目中更高效地使用这些工具。《Java极限编程》是一本全面的指南，旨在帮助Java开发者理解和实施极限编程，通过实战案例和详细的工具指南，提升开发效率和软件质量。无论你是初涉极限编程，还是希望进一步提升技能，这本书都将为你提供宝贵的洞见和实践指导。

Collective Ownership

The XP practice of collective ownership states that anyone can make a change to the system. You don't have

to wait. No one owns a class. Everyone contributes, and if you need to make a change or refactor something

to get it to work with a new feature, you can. Besides, you have the tests to make sure your changes did not

break the system, and the old version is still in source control if anyone needs to refer to it, which is rare.

In addition, because many classes have corresponding automated test code, anyone can see how the code

and API of classes were supposed to work. So, collective programming goes hand in hand with automated

testing. Testing is part of what makes collective ownership possible.

Some developers will know some sections better than other developers, but all take ownership and

responsibility for a system. If no one knows a particular part, the unit tests exercise the API and check that you

did not break the system with your changes. Thus, you do not have to wait for another team member (let's call

him Jon) to fix something. If Jon is busy helping Doug, you will fix the system with Nick, your pair-programming

partner. If Jon is sick, the knowledge of a particular subsystem is not lost. Because Jon was pair programming

with Andy, Andy knows about the system—and, in fact, so does Paul.

In addition, if you did not practice collective ownership and you had some critical parts of the system, then

everyone would need to wait until you were done.

Or, you would have to work a very long week to accomplish the task so you wouldn't hold up Paul, Doug,

Andy, and Nick. Your family would like you to spend more time with them, and you want to work a 40-hour

week.

40-Hour Week

The 40-hour week practice states that if you cannot do your work in a 40-hour week, then something is wrong

with the project. Let's face it, burned-out developers make lots of mistakes. No one is saying that you should

never put in a 90-, 80-, 70-, or 60-hour week, but such a schedule should not be the norm. An unstated reality

to this practice is to make your time count by working hard and getting the most out of your time. Long

meetings should be rare, as should unnecessary red tape. Any activity that gets in the way of providing the

most business value into the next release of your current projects should be avoided like the plague. Make the

most of your time, and 40-hour weeks will be enough most of the time. In addition, keeping normal office hours

will give you more opportunity to talk about features with your 9-to-5 customers.

On-Site Customer

The on-site customer practice states that if at all possible, the customer should be available when the

developers need to ask questions. And, if at all possible, the customer should be physically located with the

developers.

The customer must be available to clarify feature stories. The customer is also involved in the planning game,

and this process is easier if the customer is not remote. The developers work with the customer to decide

which stories are implemented for that iteration. The customer also helps write and refine the stories—which

typically involves ad hoc and planned discussions with the developers. The stories, which are recorded on

index cards, are written in a simple dialect that both the developers and customer understand, using a

common metaphor.

Metaphor

A metaphor is a common language and set of terms used to envision the functionality of a project. These

terms can equate to objects in the physical world, such as accounts or objects. Other times, metaphors can be

more abstract, like windows or cells. The idea is for the customer and developers to have the same vision of

the system and be able to speak about the system in a common dialect.

Coding Standard

XPers should follow the practice of using a coding standard. You must be able to understand one another's

code. Luckily for us Java developers, we have the coding standard set by Sun; you should be able to make

some light adjustments and make this coding standard your coding standard.

Your coding standard should state the proper use of threads, language constructs, exception use, no duplicate

code logic, and so on. The coding standard should be more than just a guide on where to put your curly brace;

it should denote style and common practices and conventions that your team will follow. Java developers have

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.

Chapter 2: J2EE Deployment Concepts

Overview

This chapter is an overview of several key concepts for assembling and deploying J2EE applications. In

Chapter 6

, "Building J2EE Applications with Ant," we use Ant to create Java ARchive (JAR) files, Web

ARchive (WAR) files, and Enterprise JavaBean (EJB) JARs, so you will need to have a background in the

various deployment descriptors for these modules. If you already have considerable experience with J2EE

applications, you may want to skip to Chapter 3

, "Example Applications."

The J2EE platform provides component models for assembling applications. J2EE lets you "divide and

conquer" an application by buying and building components and wiring them together into an application. Java

and J2EE support the following components:

Client Components

 JavaBeans

 Applets

Web Application Components

 Servlets

 JSPs

 TagLibs

Enterprise JavaBeans

 Session beans

 Stateless session beans

 Entity beans

Each component executes in a container. To interoperate with various containers, these components require

deployment descriptor files, configuration files, property files, and/or metadata files, and other configuration

files. All these files describe the components and how they will interact with other components and their

container environment.

Deployment can be a complex matter. A typical deployment might involve creating an Enterprise ARchive

(EAR) file that can contain JAR and WAR files. The JAR files can in turn contain enterprise beans. The WAR

file can in turn contain Web components (servlets, TagLibs, JavaBeans, and JSP), HTML pages, images, Java

class files, and other JAR files that contain application components (JavaBeans, client-side remote references

to enterprise beans and applets). The deployment descriptor for a Web application (which we will cover later)

may contain env-entry elements that are mapped to the Java Naming and Directory Interface (JNDI) names

java:comp/env (the context), ejb-ref (describes enterprise beans), and resources-ref (maps Java Messaging

Service, Java Database Connectivity, and mail resources so that the Web application can use them).

Figures 2.1

and 2.2 show block diagrams of the two J2EE applications that we build, test, and deploy

throughout this book (see Chapter 3

for details on these applications). As you can see, several different types

of components need to be deployed to multiple servers and containers.

Figure 2.1: The HelloWorld Application.

Figure 2.2: The Pet Store Application.

To say that configuration management of a typical J2EE enterprise application is complex is an

understatement. In Chapters 5

and 6 we will use Ant to help facilitate this process. Otherwise, continuous

integration would be pretty tough with the complexities of the J2EE deployment environment.

The remainder of this chapter describes the basic J2EE components and how they are deployed. We also

explain the JAR file format, because many components and sets of components are packaged in either a JAR

file or some variation of a JAR file.

The JAR File

JAR stands for Java ARchive, although it seems to be an obvious pun on the fact that Java components are

called beans ("a jar of beans"). A JAR file is a collection of other files. JAR files use the ZIP file format, which

supports compression.

Many components, subsystems, and modules are deployed in JAR files or some variation of a JAR file. There

are JAR files for JavaBeans and applets. Other JAR files contain libraries of Java code. There are JAR files

that contain Enterprise JavaBeans. Then there are variations of JAR files that contain other JAR files and

JavaServer Pages (JSPs) like the WAR files. The king of all JAR files, the EAR file, can contain other JAR

files, EJB JAR files, and WAR files.

Each JAR file contains a manifest file called MANIFEST.MF, which is located in the JAR file's META-INF

directory. The manifest file is a text file that consists of entries that describe the contents of the JAR file. The

main section of the manifest file contains configuration information and specifies the application or extension

the JAR file is associated with.

JAR files were originally developed to package Java applets and their requisite components (.class files,

images, and sounds). The boon to applet development was that the applet could be downloaded to a browser

in a single file, so the browser didn't have to download many files—a major boost to efficiency and speed.

JAR Files and Applets

For applets, JAR files are specified in the HTML applet tag's "archive" parameter. This parameter causes the

browser to load the JAR file, which contains the applet code. For example:

<applet

code= "xptoolkit.applet.HelloWorldApplet"

archive="helloapplet.jar"

width=200 height=200>

</applet>

Applet Delivery has Complex Problems and Solutions

It's supposed to be easy to request a browser to open a JAR file. The problem is that one major Web

browser vendor decided not to support Java any longer. The vendor froze its version of Java at version JDK

1.1.5. Thus, you can use the applet tag we just described if you do not use any features of Java newer than

JDK 1.1.5.

Another major vendor of Web browsers supported the later versions of Java, but at the time its browser

support of Java was not very robust. Thus, Sun had two choices: It could wait for the browser to catch up or

write its own Java plug-in for the major browsers. The good folks at Sun decided to write their own plug-in for

Java. A tag that supports both Netscape and Microsoft may look like this:

codebase="http://java.sun.com/products/plugin/1.2.2/

jinstall-1_2_2-win.cab#Version=1,2,2,0"

height="200" width="200" align="center">

<param name="java_code"

value="xptoolkit.applet.HelloWorldApplet">

codebase="http://java.sun.com/products/plugin/"

height="200"

width="200"

align="center"

java_code="xptoolkit.applet.HelloWorldApplet"

java_archive="helloapplet.jar">

</comment>

<p> Java is cool. Get a browser that supports the plugin.

</ br>

</p>

</noembed>

</embed>

</object>

剩余416页未读，继续阅读

bulefate

粉丝: 0
资源: 1

精通极限编程的Java工具

Java极限编程

Java_极限编程Java_极限编程

Java极限编程_src源码源码整理

Java极限编程：学习与实践

敏捷开发方法论：Scrum、看板和极限编程

Java并发编程中的性能测试与分析方法

敏捷开发实践指南：Scrum、Kanban和极限编程，提升团队协作和软件交付效率

java极限编程.pdf23.96 mb

解析极限编程 pdf

简述极限编程模型及其特点，简述极限编程模型和增量迭代编程模的优缺点

最新资源