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

需积分: 15 3 浏览量更新于2024-07-18 收藏 12.97MB PDF 举报

"Agile Principles, Patterns, and Practices in C#" 是一本由 Robert C. Martin 和 Micah Martin 合著的专业书籍，旨在引导 .NET 开发人员理解和应用敏捷开发方法。这本书是面向 C# 编程语言的，为 .NET 程序员提供了关于敏捷原则、模式和实践的详细指南。书中的内容主要分为两部分：一是介绍敏捷开发的基本概念和原则，二是通过一系列的案例研究展示敏捷设计和开发的实践技巧。作者首先概述了敏捷运动的基础，包括敏捷开发的核心理念，然后逐步深入到实际的代码实现。书中利用 UML 模型作为起点，逐步过渡到真实的 C# 代码，使读者能够从理论到实践全面掌握敏捷方法。本书涵盖了敏捷开发的多个关键方面，包括： 1. **敏捷原则**：读者将了解到敏捷开发的基石，比如个体和互动高于流程和工具，可工作的软件高于详尽的文档，客户协作高于合同谈判，以及响应变化高于遵循计划。这些原则是敏捷方法的核心，指导着团队在项目中的行为。 2. **极限编程（XP）的十四项实践**：书中详细介绍了极限编程的实践，如持续集成、结对编程、单元测试、重构等，这些都是敏捷开发中常用且重要的技术手段。 3. **敏捷设计模式**：书中会讨论如何在 C# 中应用各种设计模式，这些模式有助于提高代码的灵活性、可读性和可维护性，是敏捷开发中保持代码质量的关键。 4. **案例研究**：通过具体的案例，读者可以学习如何在实际项目中运用敏捷原则和实践，看到它们如何解决具体问题，提升团队效率。 5. **源代码示例**：书中的所有代码示例都可以从作者的网站上下载，为读者提供了动手实践的机会，帮助他们更好地理解和应用所学知识。 "Agile Principles, Patterns, and Practices in C#" 是一本对于想要深入理解并实践敏捷开发的 .NET 程序员来说不可或缺的参考书籍。它不仅提供了理论基础，还通过丰富的实例和代码示例帮助读者将敏捷原则融入到日常开发工作中。无论是初学者还是经验丰富的开发者，都能从中获益，提升自己的敏捷开发技能。

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页未读，继续阅读

rmn190

粉丝: 316
资源: 7

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

[免费PDF高清]敏捷软件开发(英文版)Agile Principles, Patterns, and Practices in C#.rar

Agile software development principles, patterns, and practices

Agile+Principles,+Patterns,+and+Practices+in+C#(英文版，已重新编译)

推荐的代码规范学习资料

单一职责原则是从哪个概念演化来的

系统测试参考文献有哪些

给出一篇MVC模型的国外参考文献引用

单一职责原则从哪个概念演化来的

推荐几本提高代码质量的书籍

函数单合一职责原则从哪个概念演化而来

最新资源