敏捷软件开发(影印版) - (2008 年度畅销榜NO.450 )

敏捷软件开发2003Jolt大奖 \r\n ·软件开发和管理人员必读经典 \r\n ·《Refactoring》作者Martin Fowler全力推荐 \r\n ·原汁原味，零距离领悟大师思想精髓 \r\n \r\n

Foreword\r\n Preface\r\n About the Authors\r\n List of Design Patterns\r\nSection 1 Agile Development\r\nSection 2 Agile Design\r\nSection 3 The Payroll Study\r\nSection 4 Packaging the Payroll System\r\nSection 5 The Weather Station Case Study\r\nSection 6 The ETS Case Study\r\n\r\n

Agile development is the ability to develop software quickly, in the face of rapidly changing requirements, In order to achieve this agility, we need to employ practices that provide the necessary discipline and feedback. We need to employ design principles that keep our software flexible and maintainable, and we need to know the design patterns that have been shown to balance those principles for specific problems. This book is an attempt to knit all three of these concepts together into a functioning whole. This book describes those principles, patterns, and practices and then demonstrates, how they are applied by walking through dozens of different case studies. More importantly, the case studies are not presented as complete works. Rather, they are designs in progress. You will see the designers make mistakes, and you will observe how they identify the mistakes and eventually correct them. You will see them puzzle over conundrums and worry over ambiguities and trade-offs. You will see the act of design. The Devil Is in the Details This book contains a lot of Java and C++ code. I hope you will carefully read that code since, to a large degree, the code is the point of the book. The code is the actualization of what this book has to say. There is a repeating pattern to this book. It consists of a series of case studies of varying sizes. Some are very small, and some require several chapters to describe. Each case study is preceded by material that is meant to prepare you for it. For example, the Payroll case study is preceded by chapters describing the object-oriented design principles and patterns used in the case study. The book begins with a discussion of development practices and processes. That discussion is punctuated by a number of small case studies and examples. From there, the book moves on to the topic of design and design principles, and then to some design patterns, more design principles that govern packages, and more patterns. All of these topics are accompanied by case studies. So prepare yourself to read some code and to pore over some UML diagrams. The book you are about to read is very technical, and its lessons, like the devil, are in the details. k Little History Over six years ago, I wrote a book entitled Designing Object-Oriented C++ Applications using the Booch Method. It was something of magnum opus for me, and I was very pleased with the result and with the sales. This book 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 chapters have been massively changed. The intent, spirit, and many of the lessons of the book are the same. And yet, I've learned a tremendous amount about software design and development in the six years since Designing came out. This bookreflects that learning. What a half-decade! Designing came out just before the Intemet collided with the planet. Since then, the number of abbreviations we have to deal with has doubled. We have Design Patterns, Java, EJB, RMI, J2EE, XML, XSLT, HTML, ASP, JSP, Servlets, Application Servers, ZOPE, SOAP, C#, .NET, etc., etc. Let me tell you, it's been hard to keep the chapters of this book reasonably cmrent! The Booch Connection In 1997, I was approached by Grady Booch tohelp 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 I had been an avid reader and contributor to his various works, including UML. So I accepted with glee. I 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 the contr