design and development
| » asp net data web co... |
| « advanced macromedia... |
| SERCountTM Ratings | |
|---|---|
| Popularity | 731 |
AntiPatterns Refactoring Software Architectures
The following report compares books using the SERCount Rating (base on the result count from the search engine).
Rating: 3.24/5 from 37 reviews An amazing look at how object orientation is misusedThis is NOT a book on architectural patternsBE WARNED: - This book is on process and *NOT* architecture. Anyone looking for a companion to the GoF Design Patterns book will be *sorely* disappointed in AntiPatterns. This is not a "bad apples" version of architecture patterns. Instead, it devotes itself to describing symptoms resulting from failed or missing processes. As far as being a process book, it's barely average. It has some good insights and might help a manager spot emerging problems, but much of the advise is too generalized to be of much applied use. You can tell that this book was written by four seperate people. One of them did an outstanding job (making about 1/4 of the book 5 stars). He describes solutions with detail and clarity. One does a decent job. Two of them are clearly jargon blowhards who have trouble completing a thought. Their chapters offer no detailed advice on what action to take but rather generalize and summarize on vague remedies. For instance, "put more money into architecture" is one fortune cookie they offer. I wish they had a critical eye preview the book and point out all of their holes -- both in supportive argument and in solution description. Often times a paragraph introduces a concept, and the author neither explains it nor offers any futher reading. The book is spotted with questionable "evidence" supporting their opinions. Here is my favorite quote of the book, "Meeting productivity gains are must more dramatic,... and we have seen productivity gains over 100,000:1." They have seen fifty years of work performed in an hour! Talk about overselling a process improvement! And don't get me started on their misuse of the term "refactor." A good startNow that Design Patterns have been in the main stream for a decade or so, the idea is ready for rejuvenation. "Antipatterns" does a good job at its part of that update. The full analytic technique should include -- patterns (what works well) -- antipatterns (what fails miserably, sooner or later), and -- refactoring or reengineering (connecting the two). So far, that trio hasn't been put together in a systematic way. This book is a fair first stab at the list of common offenders, though. It has an exploratory style - it distinguishes major and minor (mini) problems, while trying out different ways of expressing evils of different scales. It proposes a systematic way to diagnose each problem, identify causes, and overcome the problem that left the mess in the first place. This is all good, even if Brown et al. haven't left the study in its final form. This book may have lasting value, if only because it's the first to use the "patterns" methodology in studying what not to do. It's good for beginners who haven't seen the messes first-hand, and good for experienced developers who want to systematize their scars and war stories. | ||||||||||||||||||||
It turns out that people misuse object oriented technology in similar ways, forming not "patterns", but rather "AntiPatterns." The AntiPatterns book is like a pathology textbook for software engineering: It helps you identify projects gone awry, what were the basic reasons for the program to have developed the way it did, what are the consequences of such pathological development, and how to fix things. The idea is not to have to do a complete re-write, but to either isolate the working-but-malstructured parts of the program or fix them gently, a small piece at a time, or both. The book will also teach you how NOT to think about patterns and object orientation.