Anti-pattern: Difference between revisions

Content deleted Content added
m fmt
mNo edit summary
 
Line 1:
{{Short description |Solution to a problem that may be commonly used but is generally a bad choice}}
In [[computer science]], '''anti-patterns''' are problems that happen frequently in [[computer programming]] and that should be avoided in [[programming practice|good practice]].
An '''anti-pattern''' is a solution to a class of problem that although may be commonly used, is likely to be ineffective or counterproductive.{{sfn|Budgen|2003|p=225}}{{sfn|Ambler|1998|p=4}} The term, coined in 1995 by [[Andrew Koenig (programmer)|Andrew Koenig]], was inspired by the book ''[[Design Patterns]]'' which highlights [[software development]] [[design pattern]]s that its authors consider to be reliable and effective.{{sfn|Neill|Laplante|DeFranco|2011|p=4}}
A paper in 1996 presented by Michael Ackroyd at the Object World West Conference described anti-patterns.{{sfn|Neill|Laplante|DeFranco|2011|p=4}} It was, however, the 1998 book ''[[AntiPatterns]]'' that both popularized the idea and extended its scope beyond the field of software design to include software architecture and project management.{{sfn|Neill|Laplante|DeFranco|2011|p=4}}
Other authors have extended it further since to encompass environmental, organizational, and cultural anti-patterns.{{sfn|Neill|Laplante|DeFranco|2011|p=5}}
 
According to the authors of ''Design Patterns'', there are two key aspects of an anti-pattern that distinguish it from a bad habit, bad practice, or bad idea. First, an anti-pattern is a commonly used process, structure or pattern of action that, despite initially appearing to be appropriate and effective, has more bad consequences than good ones. Second, another solution exists to the problem that the anti-pattern is attempting to address. This solution is documented, repeatable, and proven to be effective where the anti-pattern is not.
The term comes from the Gang of Four's ''[[Design Patterns]]'' book, which laid out examples of good programming practise. The authors termed these good methods "[[design pattern (computer science)|design patterns]]", while "anti-patterns" are the opposite.
 
A guide to what is commonly used is a "rule-of-three" similar to that for patterns: to be an anti-pattern it must have been witnessed occurring at least three times.{{sfn|Neill|Laplante|DeFranco|2011|p=6}}
Anti-patterns can also be referred to as '''pitfalls''', to emphasise that they are a dangerous trap which an unwary [[programmer]] might find themselves in.
 
Documenting anti-patterns can be an effective way to analyze a problem space and to capture expert knowledge.{{sfn|Jimenez|2006}} While some anti-pattern descriptions merely document the adverse consequences of the pattern, good anti-pattern documentation also provides an alternative, or a means to ameliorate the anti-pattern.{{sfn|Demeyer|2008|p=102}}
Among them are:
 
==Examples==
* [[abstraction inversion]]
 
* [[accidental complexity]]
===In software engineering===
* [[Action at a distance (computer science)|action at a distance]]
In software engineering, anti-patterns include:{{sfn|Demeyer|2008|p=102}}
* [[accumulate and fire]]
 
* [[ambiguous viewpoint]]
; [[God object]]: A single [[class (programming)|class]] handles all control in a [[computer program |program]] rather than control being distributed across multiple classes.
* [[analysis paralysis]]
 
* [[big ball of mud]]
; [[Magic number (programming)|Magic number]]: A literal value with an important yet unexplained meaning which could be replaced with a named constant.
* [[blind faith (computer science)|blind faith]]
 
* [[boat anchor]]
; [[Poltergeist (computer programming)|Poltergeist]]: Ephemeral controller classes that only exist to invoke other methods on classes.
* [[busy spin]]
 
* [[caching failure]]
; [[Big Ball of Mud]]: A [[software system]] that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer [[Turnover (employment)|turnover]] and [[Software entropy]].
* [[checking type instead of membership]]
 
* [[code momentum]]
===In project management===
* [[code smell]]
Project management anti-patterns included in the ''Antipatterns'' book include:{{sfn|Neill|Laplante|DeFranco|2011|p=5}}
* [[continuous obsolescence]]
 
* [[copy and paste programming]]
; Blowhard Jamboree: An excess of industry pundits
* [[creeping featurism]]
 
* [[Dead End (Anti-Pattern)|dead end]]
*; [[designAnalysis by committeeparalysis]]
 
* [[DLL hell]]
; Viewgraph Engineering: Too much time spent making presentations and not enough on the actual software.
* [[double-checked locking]]
 
* [[empty subclass failure]]
; Death by Planning: Spending too much effort planning.
* [[God object]]
 
* [[input kluge]]
; Fear of Success: Irrational fears near to project completion.
* [[interface bloat]]
 
* [[hard code]]
; The Corncob: Difficulties with people.
* [[lava flow]]
 
* [[magic number (programming)#Magic numbers in code|magic numbers]]
; Intellectual Violence: Intimidation through use of jargon or arcane technology
* [[magic pushbutton]]
 
* [[mushroom management]]
; Irrational Management: Bad management habits.
* [[poltergeist (computer science)|poltergeists]]
 
* [[premature optimization]]
; [[Smoke and mirrors|Smoke and Mirrors]]: Excessive use of demos and prototypes by salespeople.
* [[procedural code]]
 
* [[reinventing the wheel]]
; Throw It Over the Wall: Forcing fad software engineering practices onto developers without buy-in.
* [[Reinventing the Square Wheel]]
 
* [[smoke and mirrors]]
; Fire Drill: Long periods of monotony punctuated by short crises.
* [[software bloat]]
 
* [[spaghetti code]]
; The Feud: Conflicts between managers.
* [[stovepipe system]]
 
* [[vendor lock-in]]
; e-mail Is Dangerous: Situations resulting from ill-advised e-mail messages.
* [[warm bodies]]
 
== See also ==
*{{annotated link|Code smell}}
*{{annotated link|Design smell}}
*{{annotated link|Dark pattern}}
*{{annotated link|List of software development philosophies}}
* {{annotated link|List of tools for static code analysis}}
* {{annotated link|Software rot}}
*{{annotated link|Software Peter principle}}
*{{annotated link|Capability Immaturity Model}}
*{{annotated link|List_of_ISO_standards_28000–29999|ISO/IEC 29110}}: Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)
*[[List of software anti-patterns]]
*''{{annotated link|The Innovator's Dilemma}}''
 
== References ==
=== What supports what ===
* [[Perl Design Patterns Book]]
{{Reflist|25em}}
=== Sources ===
{{refbegin}}
* {{cite book|title=Antipatterns: Managing Software Organizations and People|edition=second|series=Applied Software Engineering Series|author1-first=Colin J.|author1-last=Neill|author2-first=Philip A.|author2-last=Laplante|author3-first=Joanna F.|author3-last=DeFranco|publisher=CRC Press|year=2011|isbn=9781439862162}}
* {{cite book |author-last=Budgen|author-first=D. |title=Software design |year=2003 |publisher=Addison-Wesley |___location=Harlow, Eng. |isbn=0-201-72219-4 |page=225 |url=https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225 |quote="As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."}}
* {{cite book |author-first=Scott W.|author-last=Ambler |author-link= Scott W. Ambler |title=Process patterns: building large-scale systems using object technology |year=1998 |publisher=Cambridge University Press |___location=Cambridge, UK |isbn=0-521-64568-9 |page=4 |url=https://books.google.com/books?id=qJJk2yEeoZoC&q=%22anti-pattern%22+date:1990-2001&pg=PA4 |quote="...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."}}
* {{cite web |last1=Jimenez |first1=Edward |date=2006-04-24 |title=AntiPatterns |url=http://antipatterns.com/EdJs_Paper/Antipatterns.html |website=AntiPatterns |access-date=24 April 2006}}
* {{cite book|title=Software Evolution|editor1-first=Tom|editor1-last=Mens|editor2-first=Serge|editor2-last=Demeyer|publisher=Springer Science + Business Media|year=2008|isbn=9783540764403|chapter=ObjectOriented Reengineering|author1-first=Serge|author1-last=Demeyer}}
{{refend}}
 
== Further reading ==
* {{cite journal|title=Patterns and Antipatterns|journal=Journal of Object-Oriented Programming|date=March–April 1995|first=Andrew|last=Koenig|volume=8 |issue=1|pages=46–48}}
** Later re-printed in: {{cite book |author=Rising, Linda |title=The patterns handbook: techniques, strategies, and applications |year=1998 |publisher=Cambridge University Press |___location=Cambridge, U.K. |isbn=0-521-64818-1 |page=387 |url=https://books.google.com/books?id=HBAuixGMYWEC&q=0-521-64818-1&pg=PT1 |quote="An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one."}}
*{{cite book |last1=Laplante |first1=Phillip A. |last2=Neill |first2=Colin J. |year=2005 |title=Antipatterns: Identification, Refactoring and Management |publisher=Auerbach Publications |isbn=0-8493-2994-9}}
*{{cite book |last1=Brown |first1=William J. |last2=Malveau |first2=Raphael C. |last3=McCormick |first3=Hays W. |last4=Thomas |first4=Scott W. |editor-last=Hudson |editor-first=Theresa Hudson |title=Anti-Patterns in Project Management |publisher=[[John Wiley & Sons]] |year=2000 |isbn=0-471-36366-9}}
*{{cite journal|journal=Journal of Systems and Software|volume=83|issue=1|date=January 2010|pages=52–59|title=Software project management anti-patterns|author1-first=Ioannis|author1-last=Stamelos|doi=10.1016/j.jss.2009.09.016}}
 
==External links==
{{Commons category|Anti-patterns}}
*[http://c2.com/cgi/wiki?AntiPattern Anti-pattern] at [[WikiWikiWeb]]
 
{{Authority control}}
[[es:Antipatrón de diseño]]
[[fr:Antipattern]]
 
[[Category:Programming]]
[[Category:Anti-patterns| ]]
[[Category:Software architecture]]
[[Category:Design]]
[[Category:Industrial and organizational psychology]]
[[Category:Organizational behavior]]
[[Category:Anti-social behaviour]]
[[Category:Workplace]]
[[Category:1995 neologisms]]