解析极限编程(影印版)

解析极限编程(影印版)
作 者: 贝克
出版社: 中国电力出版社
丛编项: 拥抱变化
版权说明: 本书为出版图书,暂不支持在线阅读,请支持正版图书
标 签: 建模
ISBN 出版时间 包装 开本 页数 字数
未知 暂无 暂无 未知 0 暂无

作者简介

  Kent Beck:拥有并经营着First Class软件公司,在这里他把主要精力放在两个最大的兴趣上——模式和极限编程。他一直在研究软件开发的先驱模式、CRC卡、HotDraw画图编辑器框架、xUnit单元测试框架以及测试为先的编程。他发表了五十多篇关于编程的文章。

内容简介

本书由国际知名的微软技术专家撰写,主要探讨由.NET框架所提供的XML工具集。全书共分四个部分,第一部分深入讨论在.NET平台中实现XML的各个核心类,同时介绍读取器和编写器、数据验证以及XML模式方面的一些例子和参考信息;第二部分讨论XML数据操作,包括XMLDOM、XPath、XSLT等。第三部分介绍XML与数据访问,讲述XML与数据库之间的互操作;最后集中讨论应用程序与互操作性,并简要讨论SQLServer2及其XML扩展、.NET远程化、XMLWeb服务,并包括两个介绍XML配置文件、XML数据岛以及浏览器/部署托管控件的章节。本书条理清晰,实例丰富,适合学习XML的开发人员阅读,尤其适合.NET框架下的XML开发人员参考。在Microsoft.NET框架中,从远程化到Web服务,从数据访问到配置,XML无所不在。通过本书可以深入了解.NET中的大量XML核心类,学习使用解析器进行编程,本书是由MicrosoftASP.NET及MicrosoftADO.NET等前沿技术的知名专家撰写。在这里,你可以找到有关技术(如XML模式,XML转换以及XPath方面)的权威解释,还可发现有关数据访问的问题(如同步与串行化、DiffGram格式以及MicrosoftSQLServer2中的XML扩展方面)的广泛探讨。可以学会如何在.NET中从XML获取景佳的性能,也可以得到类似”什么时候应该使用XMLWeb服务而不是远程化”这些常见问题的答案。NET框架中的XML核心类.NETXML解析模型XML读取器与编写器验证读取器与编写器XML模式XML数据操作.NET中的XMLDOMXPathXSLTXML与数据访问SQLServer2中的XML扩展DataSet串行化DiffGram格式应用程序互操作性XML串行器.NET远程化XMLWeb服务XML数据岛配置文件。

图书目录

Section 1 The Problem

Chapter 1 Risk: The Basic Problem

Software development fails to deliver, and fails to deliver value. This

failure has huge economic and human impact. We need to find a new

way to develop software.

Chapter 2 A Development Episode

Day-to-day programming proceeds from a task clearly connected to a

feature the customer wants, to tests, to implementation, to design, and

through to integration. A little of each of the activities of software

development are packed into each episode.

Chapter 3 Economics of Software Development

We need to make our software development economically more valuable

by spending money more slowly, earning revenue more quickly, and

increasing the probable productive lifespan of our project. But most of

all we need to increase the options for business decisions.

Chapter 4 Four Variables

We will control four variables in our projects---cost, time, quality, and

scope. Of these, scope provides us the most valuable form of control.

Chapter 5 Cost of Change

Under certain circumstances, the exponential rise in the cost of changing

software over time can be fiattened. If we can fiatten the curve, old

assumptions about the best way to develop software no longer hold.

Chapter 6 Learning to Drive

We need to control the development of software by making many small

adjustments, not by making a few large adjustments, kind of like driving

a car. This means that we will need the feedback to know when we are a

little off, we will need many opportunities to make corrections, and we will

have to be able to make those corrections at a reasonable cost.

Chapter 7 Four Values

We will be successful when we have a style that celebrates a consistent set of

values that serve both human and commercial needs: communication,

simplicity, feedback, and courage.

Chapter 8 Basic Principles

From the four values we derive a dozen or so basic principles to guide our

new style. We will check proposed development practices to see how they

measure up to these principles.

Chapter 9 Back to Basics

We want to do everything we must do to have stable, predictable software

development. But we don't have time for anything extra. The four basic

activities of development are coding, testing, listening, and designing.

Section 2 The Solution

Chapter 10 Quick Overview

We will rely on the synergies between simple practices, practices that often

were abandoned decades ago as impractical or naive.

Chapter 11 How Could This Work ?

The practices support each other. The weakness of one is covered by the

strengths of others.

Chapter 12 Management Strategy

We will manage the overall project using business basics--phased delivery,

quick and concrete feedback, clear articulation of the business needs of the

system, and specialists for special tasks.

Chapter 13 Facilities Strategy

We will create an open workspace for our team, with small private spaces

around the periphery and a common programming area in the middle.

Chapter 14 Splitting Business and Technical Responsibility

One key to our strategy is to keep technical people focused on technical

problems and business people focused on business problems. The project

must be driven by business decisions, but the business decisions must be

informed by technical decisions about cost and risk.

Chapter 15 Planning Strategy

We will plan by quickly making an overall plan, then refining it further

and further on shorter and shorter time horizons--years, months weeks,

days. We will make the plan quickly and cheaply, so there will be little

inertia when we must change it.

Chapter 16 Development Strategy

Unlike the management strategy, the development strategy is a radical

departure from conventional wisdom--we will carefully craB a solution

for today's problem today, and trust that we will be able to solve tomor-

row's problem tomorrow.

Chapter 17 Design Strategy

We will continually refine the design of the system, starting from a very

simple beginning. We will remove any fiexibility that doesn't prove useful.

Chapter 18 Testing Strategy

We will write tests before we code, minute by minute. We will preserve these

tests forever, and run them all together frequently. We will also derive tests

from the customer's perspective.

Section 3 Implementing XP

Chapter 19 Adopting XP

Adopt XP one practice at a time, always addressing the rnost pressing

problem for your team. Once that's no longer your most pressing problem,

go on to the next problem.

Chapter 20 Retrofitting XP

Projects that want to change their existing culture are far more common

than projects that can create a new culture from scratch. Adopt XP on

running projects a little at a time, starting with testing or planning.

Chapter 21 Lifecycle of an Ideal XP Project

The ideal XP project goes through a short initial development phase,

followed by years of simultaneous production support and refinement,

and finally graceful retirement when the project no longer makes sense.

Chapter 22 Roles for People

Certain roles have to be filled for an extreme team to work-programmer,

customer, coach, tracker.

Chapter 23 20-80 Rule

The full value of XP will not come until all the practices are in place.

Many of the practices can be adopted piecemeal, but their effects will be

multiplied when they are in place together.

Chapter 24 What Makes XP Hard

Even though the individual practices can be executed by blue-collar

programmers, putting all the pieces together and keeping them together is

hard. It is primarily emotions---especially fear--that make XP hard.

Chapter 25 When You Shouldn't Try XP

The exact limits of XP aren't clear yet. But there are some absolute show-

stoppers that prevent XP from working--big teams, distrustful customers,

technology that doesn't support graceful change.

Chapter 26 XP at Work

XP can accommodate the common forms of contract, albeit with slight

modifications. Fixed price/fixed scope contracts, in particular, become

fixed price/fixed date/roughly fixed scope contracts when run with the

Planning Game.

Chapter 27 Conclusion

Annotated Bibliography

Glossary

Index