AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
Thomas J. Mowbray
Format: PDF / Kindle (mobi) / ePub
"The AntiPatterns authors have clearly been there and done that when it comes to managing software development efforts. I resonated with one insight after another, having witnessed too many wayward projects myself. The experience in this book is palpable." -John Vlissides, IBM Research "This book allows managers, architects, and developers to learn from the painful mistakes of others. The high-level AntiPatterns on software architecture are a particularly valuable contribution to software engineering. Highly recommended!" -Kyle Brown Author of The Design Patterns Smalltalk Companion "AntiPatterns continues the trend started in Design Patterns. The authors have discovered and named common problem situations resulting from poor management or architecture control, mistakes which most experienced practitioners will recognize. Should you find yourself with one of the AntiPatterns, they even provide some clues on how to get yourself out of the situation." -Gerard Meszaros, Chief Architect, Object Systems Group Are you headed into the software development mine field? Follow someone if you can, but if you're on your own-better get the map! AntiPatterns is the map. This book helps you navigate through today's dangerous software development projects. Just look at the statistics:
* Nearly one-third of all software projects are cancelled.
* Two-thirds of all software projects encounter cost overruns in excess of 200%.
* Over 80% of all software projects are deemed failures.
While patterns help you to identify and implement procedures, designs, and codes that work, AntiPatterns do the exact opposite; they let you zero-in on the development detonators, architectural tripwires, and personality booby traps that can spell doom for your project. Written by an all-star team of object-oriented systems developers, AntiPatterns identifies 40 of the most common AntiPatterns in the areas of software development, architecture, and project management. The authors then show you how to detect and defuse AntiPatterns as well as supply refactored solutions for each AntiPattern presented.
Transfer important important marginal • Marginal. The impact can often be ignored, as it affects a minimal portion of the software. • Unimportant. The impact should not be considered. 18 • Management of functionality is a force best addressed at the application level. Developers are better able to effect functionality at its lowest level in response to (functional) requirements. • Management of performance is best addressed at both the application and the system levels. Frequently,
replicate their time−tested methods in an object−oriented architecture. Poltergeists: Poltergeists are classes with very limited roles and effective life cycles. They often start processes for other objects. The refactored solution includes a reallocation of responsibilities to longer−lived objects that eliminate the Poltergeists. Boat Anchor: A Boat Anchor is a piece of software or hardware that serves no useful purpose on the current project. Often, the Boat Anchor is a costly acquisition,
and discussing solutions. AntiPatterns, like their design pattern counterparts, define an industry vocabulary for the common defective processes and implementations within organizations. A higher−level vocabulary simplifies communication between software practitioners and enables concise description of higher−level concepts. AntiPatterns support the holistic resolution of conflicts, utilizing organizational resources at several levels, where possible. AntiPatterns clearly articulate the
The business viewpoint defines the user’s model of the information and processes. This is a model that domain experts can defend and explain (commonly called an analysis model). Analysis models are some of the most stable models of the information system and are worthwhile to maintain. Models can be less useful if they don’t focus on the required perspective(s). A perspective applies filters to the information. For example, defining a class model for a telephone exchange system will vary
have taken charge of the asylum.” 102 —Richard Rowland • No designated project architect. • A degenerate or ineffective software process. • Bad meeting processes, marked by lack of facilitation or ineffective facilitation. The meetings are bull sessions; the loudest people win and the level of discourse is the lowest common denominator of sophistication. • Gold plating—that is, features are added to the specification based on proprietary interests. This can happen for many reasons: