C#中的敏捷开发：原则、模式与实践

5星 · 超过95%的资源需积分: 50 126 浏览量更新于2024-07-28 4 收藏 12.97MB PDF 举报

"敏捷软件开发:原则、模式与实践(英文版)" 是一本由 Martin C. Robert 和 Martin Micah 合著的经典书籍，主要探讨敏捷软件开发的理念、模式及实践，特别关注面向对象的设计和编程。书中以 C# 语言为例，但其内容同样适用于 Java 和 C++ 等其他面向对象语言。该书出版于2006年，由 Prentice Hall 出版社发行，共有768页，包含了详细的目录和索引，并提供了可下载的源代码示例。在本书中，作者们通过一系列案例研究介绍了敏捷开发的基础和敏捷设计的核心概念，从 UML 模型过渡到实际的 C# 代码。初期章节介绍了敏捷运动的基本原理，随后的章节展示了经过验证的敏捷技术的实际应用。读者将从本书中学到以下关键知识点： 1. **敏捷原则**：书中详细阐述了敏捷开发的核心原则，包括快速响应变化、密切合作、持续集成、客户参与等，这些原则是敏捷方法论的基础，旨在提高软件开发的灵活性和效率。 2. **极限编程（XP）的十四项实践**：极限编程是敏捷开发的一种具体实现方式，书中详细讲解了其包括计划游戏、小批量、结对编程、持续集成、单元测试、重构等在内的十四项实践，这些实践方法旨在提高团队的生产力和软件质量。 3. **设计模式**：书中讨论了面向对象设计中的各种模式，如工厂模式、单例模式、观察者模式等，这些模式是解决常见问题的标准化解决方案，有助于提升代码的可维护性和可扩展性。 4. **Spiking 和 Splitting**：Spiking 是一种探索性技术，用于预估任务复杂性和风险；Splitting 则是将大型任务分解为更小、更易管理的部分，这两种方法在敏捷项目管理中非常重要，有助于优化工作流程和团队效率。 5. **速度（Velocity）追踪**：速度是衡量团队生产力的关键指标，书中讨论了如何跟踪和利用速度数据来预测未来的工作量，从而更好地计划迭代和项目进度。 6. **案例研究**：书中的案例研究提供了实际场景，帮助读者理解如何在真实的开发环境中应用敏捷原则和实践，增强理论与实践之间的联系。通过阅读本书，无论是初学者还是经验丰富的开发者，都能深入理解和掌握敏捷开发的精髓，提升个人和团队的软件开发能力。

Foreword

From Agile Software Development: Principles, Patterns

and Practices

I'm writing this foreword right after having shipped a major release of the Eclipse open source

project. I'm still in recovery mode, and my mind is bleary. But one thing remains clearer than ever:

that people, not processes, are the key to shipping a product. Our recipe for success is simple: work

with individuals obsessed with shipping software, develop with lightweight processes that are tuned

to each team, and adapt constantly.

Double-clicking on developers from our teams reveals individuals who consider programming the

focus of development. Not only do they write code; they digest it constantly to maintain an

understanding of the system. Validating designs with code provides feedback that's crucial for getting

confidence in a design. At the same time, our developers understand the importance of patterns,

refactoring, testing, incremental delivery, frequent builds, and other best-practices of XP that have

altered the way we view methodologies today.

Skill in this style of development is a prerequisite for success in projects with high technical risk and

changing requirements. Agile development is low-key on ceremony and project documentation, but

it's intense when it comes to the day-to-day development practices that count. Putting these

practices to work is the focus of this book.

Robert is a longtime activist in the object-oriented community, with contributions to C++ practice,

design patterns, and object-oriented design principles in general. He was an early and vocal advocate

of XP and agile methods. This book builds on these contributions, covering the full spectrum of agile

development practice. It's an ambitious effort. Robert makes it more so by demonstrating everything

through case studies and lots of code, as befits agile practice. He explains programming and design

by actually doing it.

This book is crammed with sensible advice for software development. It's equally good whether you

want to become an agile developer or improve the skills you already have. I was looking forward to

this book, and I wasn't disappointed.

Erich Gamma

Object Technology International

Micah's Introduction

In early 2005, I was on a small development team that began work on a .NET application to be

written in C#. Using agile development practices was mandatory, which is one of the reasons I was

involved. Although I had used C# before, most of my programming experience was in Java and C++.

I didn't think that working in .NET would make much difference; in the end it didn't.

Two months into the project, we made our first release. It was a partial release containing only a

fraction of all the intended features, but it was enough to be usable. And use it they did. After only

two months, the organization was reaping the benefits of our development. Management was so

thrilled that it asked to hire more people so we could start more projects.

Having participated in the agile community for years, I knew a good many agile developers who could

help us. I called them all and asked them to join us. Not one of my agile colleagues ended up joining

our team. Why not? Perhaps the most overwhelming reason was the fact that we were developing in

.NET.

Almost all agile developers have a background in Java, C++, or Smalltalk. But agile .NET

programmers are almost unheard of. Perhaps my friends didn't take me seriously when I said we

were doing agile software development with .NET, or maybe they were avoiding association with

.NET. This was a significant problem. It was not the first evidence I'd seen of this problem, either.

Teaching week-long courses on various software topics allows me to meet a wide cross-section of

developers from around the world. Many of the students I've instructed were .NET programmers, and

many were Java or C++ programmers. There's no gentle way to put this: In my experience, .NET

programmers are often weaker than Java and C++ programmers. Obviously, this is not always the

case. However, after observing it over and over in my classes, I can come to no other conclusion:

.NET programmers tend to be weaker in agile software practices, design patterns, design principles,

and so on. Often in my classes, the .NET programmers had never heard of these fundamental

concepts. This has to change.

The first edition of this book, Agile Software Development: Principles, Patterns, and Practices, by

Robert C. Martin, my father, was published in late 2002 and won the 2003 Jolt Award. It is a great

book, celebrated by many developers. Unfortunately, it had little impact on the .NET community.

Despite the fact that the content of the book is equally relevant to .NET, few .NET programmers have

read it.

It is my hope that this .NET edition acts as a bridge between .NET and the rest of the developer

community. I hope that programmers will read it and see that there are better ways to build

software. I hope that they will begin using better software practices, creating better designs, and

raising the bar for quality in .NET applications. I hope that .NET programmers will not be weaker than

other programmers. I hope that .NET programmers achieve a new status in the software community

such that Java developers are proud to join a .NET team.

Throughout the process of putting this book together, I struggled many times with the concept of my

name being on the cover of a .NET book. I questioned whether I wanted my name associated with

.NET and all the negative connotations that seemed to come with it. Yet I can no longer deny it. I am

a .NET programmer. No! An agile .NET programmer. And I'm proud of it.

About This Book

A Little History

In the early 1990s I (Bob) wrote Designing Object-Oriented C++ Applications Using the Booch

Method. That book was something of a magnum opus for me, and I was very pleased with the result

and the sales.

The book you are reading started out as a second edition to Designing, but that's not how it turned

out. Very little remains of the original book in these pages. Little more than three chapters have been

carried through, and those have been massively changed. The intent, spirit, and many of the lessons

of the book are the same. In the decade since Designing came out, I've learned a tremendous

amount about software design and development. This book reflects that learning.

What a decade! Designing came out just before the Internet collided with the planet. Since then, the

number of acronyms we have to deal with has doubled. We have EJB, RMI, J2EE, XML, XSLT, HTML,

ASP, JSP, ZOPE, SOAP, C#, and .NET, as well as Design Patterns, Java, Servelets, and Application

Servers. Let me tell you, it's been difficult to keep the chapters of this book current.

The Booch connection

In 1997, I was approached by Grady Booch to help write the third edition of his amazingly successful

Object-Oriented Analysis and Design with Applications. I had worked with Grady before on some

projects and had been an avid reader and contributor to his various works, including UML. So I

accepted with glee and asked my good friend Jim Newkirk to help out with the project.

Over the next two years, Jim and I wrote a number of chapters for the Booch book. Of course, that

effort meant that I could not put as much effort into this book as I would have liked, but I felt that

the Booch book was worth contributing to. Besides, at the time, this book was simply a second

edition of Designing, and my heart wasn't in it. If I was going to say something, I wanted to say

something new and different.

Unfortunately, the Booch book was not to be. It is difficult to find the time to write a book during

normal times. During the heady days of the dot-com bubble, it was nearly impossible. Grady got ever

busier with Rational and with new ventures such as Catapulse. So the project stalled. Eventually, I

asked Grady and Addison-Wesley whether I could have the chapters that Jim and I wrote to include

in this book. They graciously agreed. So several of the case study and UML chapters came from that

source.

The impact of Extreme Programming

In late 1998, XP reared its head and challenged our cherished beliefs about software development.

Should we create lots of UML diagrams prior to writing any code? Or should we eschew any kind of

diagrams and simply write lots of code? Should we write lots of narrative documents that describe

our design? Or should we try to make the code narrative and expressive so that ancillary documents

aren't necessary? Should we program in pairs? Should we write tests before we write production

code? What should we do?

This revolution came at an opportune time. During the middle to late 1990s, Object Mentor was

helping quite a few companies with OO design and project management issues. We were helping

companies get their projects done. As part of that help, we instilled into the teams our own attitudes

and practices. Unfortunately, these attitudes and practices were not written down. Rather, they were

an oral tradition that was passed from us to our customers.

By 1998, I realized that we needed to write down our process and practices so that we could better

articulate them to our customers. So I wrote many articles about process in the C++ Report.

[1]

These articles missed the mark. They were informative and in some cases entertaining, but instead of

codifying the practices and attitudes that we used in our projects, they were an unwitting

compromise to values that had been imposed on me for decades. It took Kent Beck to show me that.

[1]

These articles are available in the publications section of www.objectmentor.com. There are four articles. The first three are

entitled "Iterative and Incremental Development" (I, II, III). The last is entitled "C.O.D.E Culled Object Development process."

The Beck connection

In late 1998, at the same time I was fretting over codifying the Object Mentor process, I ran into

Kent's work on Extreme Programming (XP). The work was scattered through Ward Cunningham's

wiki

[2]

and was mixed with the writings of many others. Still, with some work and diligence, I was

able to get the gist of what Kent was talking about. I was intrigued but skeptical. Some of the things

that XP talked about were exactly on target for my concept of a development process. Other things,

however, such as the lack of an articulated design step, left me puzzled.

[2]

The website http://c2.com/cgi/wiki. contains a vast number of articles on an immense variety of subjects. Its authors number in

the hundreds or thousands. It has been said that only Ward Cunningham could instigate a social revolution using only a few lines

of Perl.

Kent and I could not have come from more disparate software circumstances. He was a recognized

Smalltalk consultant, and I was a recognized C++ consultant. Those two worlds found it difficult to

communicate with each other. There was an almost Kuhnian

[3]

paradigm gulf between them.

[3]

Any credible intellectual work written between 1995 and 2001 must use the term Kuhnian. It refers to the book The Structure of

Scientific Revolutions, by Thomas S. Kuhn, University of Chicago Press, 1962.

Under other circumstances, I would never have asked Kent to write an article for the C++ Report.

But the congruence of our thinking about process was able to breech the language gulf. In February

1999, I met Kent in Munich at the OOP conference. He was giving a talk on XP in the room across

from where I was giving a talk on principles of OOD. Being unable to hear that talk, I sought Kent out

at lunch. We talked about XP, and I asked him to write an article for the C++ Report. It was a great

article about an incident in which Kent and a coworker had been able to make a sweeping design

change in a live system in a matter of an hour or so.

Over the next several months, I went through the slow process of sorting out my own fears about

XP. My greatest fear was in adopting a process in which there is no explicit upfront design step. I

found myself balking at that. Didn't I have an obligation to my clients, and to the industry as a whole,

to teach them that design is important enough to spend time on?

Eventually, I realized that I did not really practice such a step myself. Even in all the article and

books I had written about design, Booch diagrams, and UML diagrams, I had always used code as a

剩余943页未读，继续阅读

kinglear

粉丝: 21
资源: 41

C#中的敏捷开发：原则、模式与实践

C#中的敏捷软件开发：原则、模式与实践

C#版敏捷软件开发：原则、模式与实践

C#版敏捷开发：原则、模式与实践详解

敏捷软件开发：原则 模式与实践 C#版

敏捷软件开发：原则模式与实践

敏捷软件开发:原则模型与实践

深入解读《敏捷软件开发原则、模式与实践》读书笔记

[机械毕业设计方案]HDK640微型客车设计总体、车架、制动系统设计.zip.zip

这是一个基于Rust实现的字节流结构化序列化/反序列化通用库，可以应用于网络数据包解析、网络数据包组包、网络通信、文件内容解析等

医院管理系统-毕业设计，基于Python+Django+Vue+MySql开发，前后端分离，源码+数据库+毕业论文+视频演示

最新资源

敏捷软件开发：原则模式与实践 C#版