William Brown 1998
m (→Details) |
(Short review on Anti Patterns - Refactoring Software, Architectures, and Projects in Crisis) |
||
(3 intermediate revisions by one user not shown) | |||
Line 1: | Line 1: | ||
− | This is a useful text that describes a range of [[Antipatterns]]. The authors claim to cut out the hype from the material they cover | + | This is a useful text that describes a range of [[Antipatterns]]. The authors claim to cut out the hype from the material they cover. |
== Details == | == Details == | ||
Line 17: | Line 17: | ||
== Content Covered == | == Content Covered == | ||
− | Antipatterns... | + | [[Antipatterns]] of management, architectural and development varieties. |
+ | |||
+ | Also in the introductory chapters, a distinction is drawn between vertical and horizontal concepts in application design. Vertical aspects are those that correspond to domain specific concepts. Horizontal aspects are those that can apply to multiple domains. | ||
+ | |||
+ | == An Honest Review == | ||
+ | |||
+ | The text has a large number of anti patterns related to software development, software architecture and software project management. Each pattern is introduced with a heading describing the Anti-pattern and its root causes. There is then discussion on what the pattern is, its exceptions and variations and how it can be fixed (A 'refactored solution'). | ||
+ | |||
+ | Although this text is of some benefit, there are a few areas of major concern. These include | ||
+ | |||
+ | * Repackaged Anti-Patterns labelled with a different name. For example, [[God Class]] named The Blob. | ||
+ | * Anti-Patterns that offer little or provide unnecessary names to common sense issues. For example there is a pattern named Email is Dangerous which says only communicating via email is bad. Another Anti-Pattern named Golden Hammer just suggests that one solution should not be used in all situations. | ||
+ | * Some Anti-Patterns are too vague to be of use. Spaghetti Code is one such example. It essentially describes ugly code. Mentioned attributes of this 'Anti-Pattern' include too many globals, minimal object relationships and lack of object orientated benefits. In my opinion, broad Anti-Patterns such as this only cause harm as they do nothing to articulate the problem to the developer or help them solve the issue. | ||
+ | * This is my major problem with this book. It takes commonly used software engineering terms such as refactoring and anti-pattern and misuses them. Although it may be a common theme to see people write ugly code this is not really an anti-pattern. Breaking this down further you may discover various Anti-Patterns such as using too many globals but if you cannot describe a fine grained problem then I do not think it deserves to be called an anti-pattern. The term refactored solution is used as a section heading where ways to fix the Anti-Pattern are proposed. However, some of these do not involve refactoring at all. For example, the 'Refactored Solution' for Email is Dangerous is essentially to not do it. | ||
+ | |||
+ | When I read this text I hoped to learn some new Anti-Patterns that would help me avoid technical blunders in code and development. Although I was able to review some common sense maxims I did not feel this book really advanced my knowledge of software development Anti-Patterns. I would not reccommend this book to others. ([[User:BenjaminTaylor]]) | ||
== See also == | == See also == | ||
* [[Antipatterns]] | * [[Antipatterns]] | ||
+ | * [[Separation of concerns]] | ||
+ | * [[Establishing priorities]] | ||
[[Category: Resources]] | [[Category: Resources]] |
Latest revision as of 06:35, 13 October 2009
This is a useful text that describes a range of Antipatterns. The authors claim to cut out the hype from the material they cover.
Contents |
Details
Title: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis.
Author: Brown, William J., Malveau, Raphael C., McCormick III, Hays W. "Skip", Mowbray, Thomas J.
Year: 1998
Publisher: Wiley Computer Publishing
Link: On Amazon
Copies: In the PSL.
Content Covered
Antipatterns of management, architectural and development varieties.
Also in the introductory chapters, a distinction is drawn between vertical and horizontal concepts in application design. Vertical aspects are those that correspond to domain specific concepts. Horizontal aspects are those that can apply to multiple domains.
An Honest Review
The text has a large number of anti patterns related to software development, software architecture and software project management. Each pattern is introduced with a heading describing the Anti-pattern and its root causes. There is then discussion on what the pattern is, its exceptions and variations and how it can be fixed (A 'refactored solution').
Although this text is of some benefit, there are a few areas of major concern. These include
- Repackaged Anti-Patterns labelled with a different name. For example, God Class named The Blob.
- Anti-Patterns that offer little or provide unnecessary names to common sense issues. For example there is a pattern named Email is Dangerous which says only communicating via email is bad. Another Anti-Pattern named Golden Hammer just suggests that one solution should not be used in all situations.
- Some Anti-Patterns are too vague to be of use. Spaghetti Code is one such example. It essentially describes ugly code. Mentioned attributes of this 'Anti-Pattern' include too many globals, minimal object relationships and lack of object orientated benefits. In my opinion, broad Anti-Patterns such as this only cause harm as they do nothing to articulate the problem to the developer or help them solve the issue.
- This is my major problem with this book. It takes commonly used software engineering terms such as refactoring and anti-pattern and misuses them. Although it may be a common theme to see people write ugly code this is not really an anti-pattern. Breaking this down further you may discover various Anti-Patterns such as using too many globals but if you cannot describe a fine grained problem then I do not think it deserves to be called an anti-pattern. The term refactored solution is used as a section heading where ways to fix the Anti-Pattern are proposed. However, some of these do not involve refactoring at all. For example, the 'Refactored Solution' for Email is Dangerous is essentially to not do it.
When I read this text I hoped to learn some new Anti-Patterns that would help me avoid technical blunders in code and development. Although I was able to review some common sense maxims I did not feel this book really advanced my knowledge of software development Anti-Patterns. I would not reccommend this book to others. (User:BenjaminTaylor)