[转贴]What is AntiPattern 什么是反模式

An Anti-Pattern is a pattern that tell you how to go from a bad solution.      
Contrast to an ameliorative pattern,which is a pattern that tells how to go from a bad solution to a good solution.
反模式：告诉你在开发、设计、管理中不要采用的糟糕的解决方案。
与优秀的改进型模式相反，反模式告诉我们避免这些糟糕的模式采用优秀的模式。

Content flowing Copy from http://en.wikipedia.org/wiki/Anti-patternAnti-pattern

Contents
1 Known anti-patterns
1.1 Organizational anti-patterns
1.2 Project management anti-patterns
1.3 Analysis anti-patterns
1.4 Software design anti-patterns
1.4.1 Object-oriented design anti-patterns
1.5 Programming anti-patterns
1.6 Methodological anti-patterns
1.7 Configuration management anti-patterns
2 See also
3 References
4 Further reading
5 External links
 

Known anti-patterns

Organizational anti-patterns
Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
Cash cow: A profitable legacy product that often leads to complacency about new products
Design by committee: The result of having many contributors to a design, but no unifying vision
Escalation of commitment: Failing to revoke a decision when it proves wrong
Management by perkele: Authoritarian style of management with no tolerance for dissent
Moral hazard: Insulating a decision-maker from the consequences of his or her decision.
Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)
Stovepipe: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
Vendor lock-in: Making a system excessively dependent on an externally supplied component[4]

Project management anti-patterns
Death march: Everyone knows that the project is going to be a disaster – except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.
Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking.
Smoke and mirrors: Demonstrating how unimplemented functions will appear
Software bloat: Allowing successive versions of a system to demand ever more resources

 Analysis anti-patterns
Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people.

Software design anti-patterns

Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
Big ball of mud: A system with no recognizable structure
Database-as-IPC: Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
Gas factory: An unnecessarily complex design
Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value
Inner-platform effect: A system so customizable as to become a poor replica of the software development platform
Input kludge: Failing to specify and implement handling of possibly invalid input
Interface bloat: Making an interface so powerful that it is extremely difficult to implement
Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.
Race hazard: Failing to see the consequence of different orders of events
Stovepipe system: A barely maintainable assemblage of ill-related components

Object-oriented design anti-patterns
Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
BaseBean: Inheriting functionality from a utility class rather than delegating to it
Call super: Requiring subclasses to call a superclass's overridden method
Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
Constant interface: Using interfaces to define constants
God object: Concentrating too many functions in a single part of the design (class)
Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
Poltergeists: Objects whose sole purpose is to pass information to another object
Sequential coupling: A class that requires its methods to be called in a particular order
Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Programming anti-patterns
Accidental complexity: Introducing unnecessary complexity into a solution
Action at a distance: Unexpected interaction between widely separated parts of a system
Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
Boat anchor: Retaining a part of a system that no longer has any use
Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
Caching failure: Forgetting to reset an error flag when an error has been corrected
Cargo cult programming: Using patterns and methods without understanding why
Coding by exception: Adding new code to handle each special case as it is recognized
Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message
Expection handling: (From Exception + Expect) Using a language's error handling system to implement normal program logic
Hard code: Embedding assumptions about the environment of a system in its implementation
Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences[5][6]
Loop-switch sequence: Encoding a set of sequential steps using a loop over a switch statement
Magic numbers: Including unexplained numbers in algorithms
Magic strings: Including literal strings in code, for comparisons, as event types etc.
Soft code: Storing business logic in configuration files rather than source code[7]
Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures

Methodological anti-patterns
Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)
Improbability factor: Assuming that it is improbable that a known error will occur
Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
Programming by permutation (or "programming by accident"): Trying to approach a solution by successively modifying the code to see if it works
Reinventing the wheel: Failing to adopt an existing, adequate solution
Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
Tester Driven Development: Software projects in which new requirements are specified in bug reports

Configuration management anti-patterns
Dependency hell: Problems with versions of required products
DLL hell: Overutilization of the dynamic-link libraries (DLLs), specifically on Microsoft Windows
Extension conflict: Problems with different extensions to pre-Mac OS X versions of the Mac OS attempting to patch the same parts of the operating system
JAR hell: Overutilization of the multiple JAR files, usually causing versioning and location problems because of misunderstanding of the Java class loading model

See also
Code smell – symptom of unsound programming
List of software development philosophies – approaches, styles, maxims and philosophies for software development
Software Peter principle

References
^ Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. pp. 225. ISBN 0-201-72219-4. http://books.google.com/books?id=bnY3vb606bAC&pg=PA225&dq=%22anti-pattern%22+date:1990-2003&lr=&as_brr=3&sig=r9gtkcqzMJILx1_JnUQ5yF1kx5s#PPA225,M1.  "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
^ Scott W. Ambler (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. pp. 4. ISBN 0-521-64568-9. http://books.google.com/books?id=qJJk2yEeoZoC&pg=PA4&dq=%22anti-pattern%22+date:1990-2001&lr=&sig=NExBN4vweIRBnMfR223RG0R-dVo.  "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."
^ Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8, (1): 46–48. ; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. pp. 387. ISBN 0-521-64818-1. http://books.google.com/books?id=HBAuixGMYWEC&pg=PT1&dq=0-521-64818-1&lr=&as_brr=3&sig=Fb61zp1zqrcOZYysT7QjIXsuBvo#PPA387,M1.  "Anti-pattern is just like pattern, except that instead of solution it gives something thats looks superficially like a solution, but isn't one."
^ Vendor Lock-In at antipatterns.com
^ Lava Flow at antipatterns.com
^ Undocumented 'lava flow' antipatterns complicate process
^ Soft Coding

 Further reading
Laplante, Phillip A.; Colin J. Neill (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9. 
Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Scott W. Thomas, Theresa Hudson (ed). (2000). Anti-Patterns in Project Management. John Wiley & Sons, ltd. ISBN 0-471-36366-9. 

 External links
Anti-pattern at WikiWikiWeb
Anti-patterns catalog
AntiPatterns.com Web site for the AntiPatterns book
Patterns of Toxic Behavior
Retrieved from "http://en.wikipedia.org/wiki/Anti-pattern"