Customer Reviews

Agile Software Development, Principles, Patterns, and Practices

5 star:		(32)
4 star:		(2)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

I don't think I've given another design/programming book 5 stars before. This book deserves it-- it could easily replace a half dozen books on my shelf, and it probably will.

Martin focuses on the why's and the wherefores of current OOD methodologies. He doesn't try to sell Agile Processes in this book. Instead, he explains a number of current practices that might be loosely grouped under the 'Agile' name. He anchors his discussion in a set of principles that drive the design process. Then he shows how software patterns can be used to put these principles into practice.

Patterns are explained and demonstrated in the context of three case studies. The case studies (a payroll system, a weather monitoring system, and an exam testing system) have the feel of day-to-day problems. One of my chief complaints with other books has been the use of esoteric case studies-- unless I work for Microsoft, I'm not likely to write a word processor anytime soon. Okay, so maybe I won't write a weather station either, but it comes a lot closer to what I will do!

The patterns discussion in this book is down-to-earth and easily understood. I have struggled over the 'Gang of Four' book ('Gamma et Al, 'Design Patterns') for well over a year. Bob Martin's book has cut through a lot of the clutter and confusion. It has been a great help to me in understanding why, where, and when to use different patters. And the explanation of UML in the book's appendices is one of the best I have seen. I can't think of a better way to learn UML than to sit down with these Appendices and Martin Fowler's 'UML Distilled'.

This is one of the two books I would recommend to an OOD newbie. The other would be 'Object Design' by Rebecca Wirfs Brock and Alan McKean. These books provide a solid grounding in object-oriented design, while requiring a very reasonable expenditure of time and effort.

The bulk of this book describes OO design principles. They're presented in a readable, useful, and well-organized way. Often they just clarify and put a name to something you've probably been doing anyway. The standard Dependency Inversion Principle is there, for one. (I'm glad to see that other people have trouble with the name. By today's reckoning, there's nothing inverted about it, but the name dates back to less enlightened times.) Others, like the Interface Segregation Principle, are less well known but reinforce lots of other good practices, such as data hiding and prevention of "interface leakage".

The "Agile" section is blessedly short, and doesn't much contaminate the otherwise good presentation elsewhere in the book. There's a lot of good to be extracted from the agility movement, but there's a lot of rabid dogmatism too. Martin managed to keep it well under control. He presented the Manifesto (ugh) early on, but that was the worst of it.

A few points marred the book, but only slightly, The drawings came across as "cute" - unprofessional and tangential to the topics at hand. Semi-fictional conversations in books like this always seem fatuous to me, and Ch.6 was no exception. The technical content managed to withstand this presentation anyway.

This book has lots of good ideas. It relates those ideas well to common and useful design patterns. A few aspects of the book tried to be funny, but came across as more annoying than anything else. That was only a few, though - the meaningful content of the book came through despite those flaws.

I recommend this book to any serious student or practitioner of OO design and implementation. I really mean "any," since even project-scarred veterans are likely to see some of their hard won knowledge set into clear text and into the context of other ideas.

I knew the book would be a great one before read it. But now, after I read some of its chapters, I know I underestimated it.

I love to read Uncle Bob's books and articles. His previous book "Designing Object-Oriented C++ Application with Booch Method" is a real gem, I learn much a lot from it, maybe more than any other books on designing. The author's style is unique, he tries to guide readers to reach a good design instead of just putting the final solution in front of you. He presents the whole process of design, shows you how to think, how to verify, how to test and modify. His is a real mentor who gives you solid knowledge and solid experience by solid examples. So, I expected learn a lot from this new book.

The book shows that it's more than my expectation. It keeps the good style, plus very valuable contents. It present at least 4 aspects which are very important and useful for today's programmers:

* Agile method: The author show you you how to USE agile method. Still he tell you a lot about "Why". I'm not a XPer, but after reading the first several chapters, I think I'd give a try.

* Object-Oriented Design Principles: The book concludes 11 O-O design principles. Only these principles are worth the price of the book to me.

* Design patterns: This book teach you 23 design patterns with concrete examples -- 15 are GoF patterns, 8 are new. The emphasis is how to use patterns in real applications, instead of telling you what design patterns are and how to document them.

* UML: This book is not about UML, but it uses UML to demostrate designs. To make you feet wet, it includes two appendics, show you basic UML with, again, concrete example. I find it's much easier for me to learn UML this way.

Well, IMHO, this book is the best O-O design textbook this year, and I wonder whether there will be a better one in the next several years.

Many OO/Patterns books are written as an introduction to the concepts and gloss over the nuances of building software in the real world. This book takes on the nitty gritty of what most developers face day to day. While it does include the gratuitous "student registration" example, this book actually delves into issues such as integrating legacy code. It also actually implements bad design choices before moving on to better solutions, and even these solutions are described in terms of trade-offs between competing forces. Also, by discussing specific Design Patterns in more depth than the cannonical format, I had a few "a-ha" moments when patterns I never quite understood emerged. I would/should have given this book 5 stars, but I had problems with the layout (oversized pages/no margins), the inconsitencies of diagrams (clouds and UML), and the disjoint feeling that the book was a collection of separately written articles, although the author does tie them nicely together. All in all, this is a must have.

Brian
brian_x7@yahoo.com

This book is packed with software engineering practices. I expect to read it over and over again. I've been reading Robert's stuff ever since his book on C++/Booch. He has willingly shared his thoughts on [his website] and now a lot of it is gathered together in this book.

Principles. These principles are the foundation upon each pattern should rest, the reference frame for good software engineering.

Patterns. This is not just another GoF section. The patterns are discussed, in context, and related in a way that nicely complements GoF. Patterns not found in GoF are also presented.

Practices. I've been practicing light weight methods long before the boost of Agile methods happened (Fowler, Martin). The test first design is a very exiting approach to design, leaving you with something much more valuable than mere diagrams - unit tests.

The reason I like reading Robert's work is that one can tell he's a programmer (he's got code up to his elbows). I'm sure there is software engineers matching him out there but only a few that match his teaching skills and experience. Have you ever felt discouraged by books full of (UML) diagrams pretending that's all there is to software development? You won't feel that way reading this book. This is the revival of source code (complemented with conceptual diagrams), so be prepared to read some too. Isn't it great?

Agile Software Development is a great Object-Oriented Design book that presents it's subject in the context of Agile Development. The book delivers solid design and programming advice in a very "light" style. Not light in that it avoids technical detail! No, Bob seems to have taken the principles of agile development and applied them to the art of technical book writing.

The book is divided into six sections and has four appendices. There are numerous UML diagrams and many code examples in C++ and Java. If you don't know UML two of the appendices will introduce you to it.

The book takes a top down approach to presenting the material. You are first given a quick overview of agile development practices. I particularly liked the Testing and A Programming Episode chapters from this section. The second section presents five high-level design priciples that every developer should learn and apply.

Case studies dealing with a payroll system, weather station software, and testing software are then presented. Each case study section starts by discussing the design patterns that will be seen in the case study. Section Four discusses subdividing the payroll system into packages. Six principles and a set of package Dependency Management metrics (I've known them as the "Martin Metrics" for years) are covered. The book wraps up with the two UML appendices mentioned above, a comparison of two imaginary developments, and an interesting article by Jack Reeves.

In my opinion Agile Software Development Principles, Patterns, and Practices is the best OOD book out there.

My first thoughts were "Hmm.. Uncle Bob's written another book. Hmm... another Agile development book. Yup."

However, when I started into it, it was obvious that the real heart of this book was the 3 Ps: core OO design principles that, sadly, most programmers haven't even heard of; fundamental, and some novel, OO design patterns; and agile programming practices.

Section 1 talks about and overviews some of the core agile programming practices, and sets the stage for the bulk of the book. As a Test-driven Development (TDD) evangelist and author (with my own book on the subject pre-orderable at this point :-) I enjoyed the chapter on TDD, concise and clear. It should whet your appitite for more (hint, hint).

The principles are masterfully explained. I expecially appreciated the in depth discussion of package design... something that I haven't before seen dealt with at this depth and with this level of quality.

Sections 3-6 cover 3 case studies. Each is used as a platform for introducing and exploring an assortment of core design patterns. Included are standard GOF patterns as well as some from the PLOPD series of books. Again, these are masterfully done. You can tell that Uncle Bob lives & breathes this stuff, and has for quite a while.

The appendices on UML are useful to those readers unfamiliar with the notation (which is used throughout). And the inclusion of the Agile vs. Rigid project comparison is good for several chuckles. The inclusion of Jack Reeves' "The Source Code Is the Design" is an added bonus.

The physical aspects of the book are well done as well. The margins are small, with barely enough room for brief notes. There's a lot of material packed into those 500 and some pages. A hardcove is nice these days when most technical books are softcover. This one will lay open next to your keyboard without resorting to paperweights.

One thing that bothered me a bit at first, or at least was distracting, came from the variety of the material.. some is older and pre-test-first, some is new and test-driven, C++, Java, etc. But once I got used to the contexts shifts they weren't a problem.

Finally, as another reviewer mentioned, this book is full of code. Everything is illustrated with code.

My advice: buy it, read it, learn it, live it. Your software will be better for it.

I have to admit that I (mis)judged this book by its cover. I saw "Agile Software Development", and from that I figured it was a bunch of squishy, feel-good BS about XP and other bandwagons. When I opened it up I found that I couldn't have been more wrong. This book is simply packed full of great stuff. It provides a solid introduction to Agile Development and eXtreme Programming but, of more interest to me, it is a GREAT BOOK on object-oriented design.

This book has dozens and dozens of practical but concise examples illustrating everything from relatively simple object-oriented design concepts such as Meyer's Open/Closed Principle to subtle and complex issues with class and package dependencies. Examples are always accompanied by UML diagrams and Java or C++ code is brought in when appropriate.

My company provides training in object-oriented design and this book now sits at the top of my recommended reading list, the position formerly occupied by Larman's (also excellent) "Applying UML and Patterns".

As a manager, I'd have no hesitation to buy this book for any developer who'd take the time to read it, and I'd consider reading it "on the clock" to be time well spent.

I am not a XPer, and I am not convinced to be one after reading this book. The first section (Agile Development) sketches XP(Extreme Programming). It reads "Everybody works on the GUI. Everybody works on the middleware. Everybody works on the database..." Basically, everybody works on everything. Have a doudt yet? Here is more, "Individuals and interactions over process...Working software over comprehensive documentation".

It seems to me that XP team is an elite team, whose members are the industry experts with aboundant design knowledge and experience, they know OO technology deep inside and out. To form such a team is a luxury even if it is affordable. In normal corporate environment, team members are at different level with different specialties, it is more beneficial to the corporate to utilize these specialities, e.g., to ask a GUI person to design database or ask a server-side developer to write GUI would cause unnecessary slow-down (if not disaster) of the project.

Generally speaking, relying on individual over process is not a safe play for any companies. People on the team come and go, how do you keep the project going? How do you train the new comer to catch up with the project? Reading code is definitely one way, but a slow way I believe. Without have a big picture of whole application architecture, diving into thousands of lines of codes is intimidating and frustrating. Documentation is one important step in the software develop process. Design document (of course, keeps up with the design/code change) is a good way to start, diagams are far more easier to descibe the functionalities of the application, and its modules, and their interactivities. (A picture is worth a thousand lines of code :))

Some people (software people) compare building softwares with building houses, especially when talking about design patterns. Would you imagine that the builder would build a house without a blueprint (the document)? Would you also imagine every worker will work on everything, architecting, grounding, framing, electric, roofing, dry-wall etc.? People with different specialties work on different areas.

One more thing I think it is overemphsized is the refactoring. Refactoring is good price to pay when the original design deteriorated. But it does not mean you don't have to think about design at all when you do it the first time. It is not free, why pay this cost if you can get it right the first time? Without solidate design knowledge and abide by the design principles, refactoring can be hard or even impossible.

I do agree on some points presented, e.g., short cycles, test-driven development, continous integration, I see these methodologies applied in practice. I also see the author's points that I don't agree, but I think XPers are streching them, either over-emphsizing or under-emphsizing them.

Don't get me wrong. Having said a lot of different views about XP, the book well deserves 5-star for the rest of it. The design principles are invaluable heuristic conclusions from industry experts. It amazed me that how few developer are even familiar with these principles, though they are the essence and root of OO technology. One example, A lot of developers are obsessed with if/elseif checking on the run-time type, and they claim if a new type is to be supported, the "only" thing that is needed is to add a extra elseif. If they know what is OCP (open-close principle), they will never write the code same.

For those code lovers, they won't be disappointed. Three full-length case studies with a lot of Java/C++ code are included. If you think "Design Pattens" (by GoF) is dry, these rehashed patterns presented here will be juicy to chew on.

One particular point that the other authors seldom touch is the packaging. There are several principles for package dependency management. You would think it is unimportant until deployment time, all those tangled packages' dependency forced you to deploy everything (including both GUI and server) as a bulk jar. And isn't it intuitive to do a top-down package design? Until you find yourself in a awkward situation at the end. You will know why and how to avoid these pitfalls after reading these principles.

Lastly, it is fairly interesting that the author even supplies some formula to measure the abstraction, stability of the packages. Avoid the "Zone of pain and zone of useless", keep to the "Main sequence" if you want a painless and stable application.

The title of this book belies much of its content. While agile development practices are espoused, much of the content is concerned with the application of design patterns in accordance with Robert's OO design principles.

Robert does a wonderful job of explaining each design pattern, demonstrating their use through code, and placing them within the context of his design principles. The examples are numerous and, with a few exceptions, well written.

Robert's OO design principles are real gems. His pragmatic approach combined with codifying the principles he's derived over the years makes for a very enlightening read. He articulates those things that most experienced developers have a gut feel for but have difficulty putting in to words.

My only criticism is the need for a proofing scrub. There are inconsistencies between some of the class and method names used in the narrative versus those used in the accompanying diagrams and examples. In some cases, this is a bit confusing.