Big ball of mud
From CSSEMediaWiki
(Difference between revisions)
(New page: == Big ball of mud == In this [http://www.laputan.org/mud/mud.html paper], Brian Foote and Joseph Yoder present the de-facto standard software architecture. Several sub-pattern...) |
|||
Line 1: | Line 1: | ||
− | |||
== Big ball of mud == | == Big ball of mud == | ||
Line 27: | Line 26: | ||
== See also == | == See also == | ||
− | * [[ | + | * [[Antipatterns]] |
− | * [[ | + | * [[Refactoring]] |
Revision as of 02:45, 24 September 2008
Big ball of mud
In this paper, Brian Foote and Joseph Yoder present the de-facto standard software architecture. Several sub-patterns are presented.
The authors deny that they are presenting AntiPatterns:
- Some of these patterns might appear at first to be antipatterns [Brown et al. 1998] or straw men, but they are not, at least in the customary sense. Instead, they seek to examine the gap between what we preach and what we practice.
IMHO, Big Ball Of Mud is an antipattern. The sub-patterns can be characterised as patterns to help cope with the bigger antipattern.
Here's the abstract:
- While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
- These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.
- A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?
Subpatterns
- Throwaway code pattern
- Piecemeal growth pattern
- Keep it working pattern
- Shearing layers pattern
- Sweeping it under the rug pattern
- Reconstruction pattern