极限编程实践：Java工具与框架应用

PDF文件

下载需积分: 0 | 3.27MB | 更新于2024-07-27 | 134 浏览量 | 举报收藏

立即下载

"Java 极限编程" 是一本专注于如何运用极限编程(eXtreme Programming, XP)理论来提升Java开发效率和质量的书籍。书中通过介绍一系列开源Java开发工具，如Ant、JUnit、Cactus等，以及详细的实例，帮助读者理解和实践极限编程的理念。在Part I“Introduction and Key Concepts”中，作者首先介绍了极限编程的基本概念和原则，包括快速反馈、轻量级过程、客户参与等核心思想。第一章“Introduction to Extreme Programming”深入浅出地解释了XP的核心理念，如小步前进、测试驱动开发(TDD)和结对编程等。第二章“J2EE Deployment Concepts”则关注于J2EE应用的部署策略，帮助开发者理解在企业级环境中如何有效地部署和管理Java应用程序。 Part II“Mastering the Tools”是书中的重点部分，详细讲解了一系列关键的Java开发工具。第四章至第六章围绕Ant构建工具，讲述了如何实现持续集成、构建Java和J2EE应用。Ant是一种广泛使用的自动化构建工具，对于实现XP中的快速反馈循环至关重要。第七章至第九章涉及测试工具，包括单元测试工具JUnit、用于测试容器服务的Cactus以及功能测试工具HttpUnit，它们是实现XP中“先测试后编码”原则的关键工具。第十章和第十一章讲解了性能测试工具JMeter和JUnitPerf，它们用于度量应用性能和进行负载测试，确保系统在高压力下仍能稳定运行。 Part III“API and Tag Reference”提供了Ant、JUnit、Cactus、HttpUnit和JUnitPerf的API及标签参考，这些详细的技术文档对开发者来说是日常工作的必备参考资料。本书由Richard Hightower和Nicholas Lesiecki撰写，旨在帮助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页未读，继续阅读

nacey5201

粉丝: 30

极限编程实践：Java工具与框架应用

Java极限编程.rar

Java 极限编程-英文版-高清无书签

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

Java极限编程

rust-std-static-1.54.0-3.module_el8.5.0+1023+0c63d3d6.tar.gz

获取本机公网IP发送到飞书群脚本

SimulinkSF平台下纯电动+四档变速箱动力性与经济性仿真模型及其应用 · 电动汽车 完整版

【超表面】基于matlab生成超表面布局并模拟超透镜作为点源的叠加【含Matlab源码 13984期】.zip

西门子S1200与霍尼韦尔电动比例阀PID控制恒温恒压供冷却水系统方案及Eplan电气图纸详解 工业自动化 高效版

基于Comsol流-固耦合煤层瓦斯抽采数值模拟技术及案例研究

信息学科平台系统源码-基于Web的信息学科平台系统设计与实现-信息学科平台网站代码-信息学科平台项目代码

基于Excel的乘用车商用车油刹制动系统计算模板：涵盖多车型及手刹EPB技术解析 必备版

按键精灵电脑版250319(包含各种源码和插件).7z

前端分析-2023071100789s

公寓报修管理系统源码-基于Web的公寓报修管理系统设计与实现-公寓报修管理网站代码-公寓报修管理项目代码

python项目之django基于大数据的职业方向推荐系统的设计与实现（完整项目源码+mysql+说明文档）计算机毕业设计源码.zip

ruby-doc-2.5.9-107.module_el8.4.0+847+ee687b6c.tar.gz

一个基于纯前端技术实现的五子棋游戏，无需后端服务，直接在浏览器中运行

算法---LeetCode 98. 验证二叉搜索树

煤气发电(燃气锅炉、汽轮机组)自动化控制.doc

最新资源

SimulinkSF平台下纯电动+四档变速箱动力性与经济性仿真模型及其应用 · 电动汽车完整版

西门子S1200与霍尼韦尔电动比例阀PID控制恒温恒压供冷却水系统方案及Eplan电气图纸详解工业自动化高效版

基于Excel的乘用车商用车油刹制动系统计算模板：涵盖多车型及手刹EPB技术解析必备版