안티패턴

Anti-pattern

소프트웨어 엔지니어링, 프로젝트 관리 및 비즈니스 프로세스에서 안티 패턴은 일반적으로 비효율적이고 매우 [1][2]역효과를 초래할 수 있는 반복적인 문제에 대한 일반적인 대응입니다.컴퓨터 프로그래머 Andrew Koenig에 의해 1995년에 만들어진 이 용어는 Design Patterns (그 책의 저자들이 매우 신뢰성과 효과가 있다고 간주한 소프트웨어 개발의 많은 디자인 패턴을 강조함)에서 영감을 얻어 그의 Journal of Object-Oriented Programming [3]기사에서 처음 발표되었습니다.1996년 오브젝트 월드 웨스트 컨퍼런스에서 마이클 애크로이드(Michael Ackroyd)가 발표한 추가 논문에서도 반패턴이 [3]기록되었다.

그러나 1998년에 출간된 책 AntiPatterns는 아이디어를 대중화하면서 소프트웨어 설계 분야를 넘어 소프트웨어 아키텍처와 프로젝트 [3]관리 분야까지 영역을 확장했습니다.다른 저자들은 환경적/조직적/[4]문화적 반패턴을 포함하도록 그 이후 더 확장하였다.

정의.

Design Patterns의 저자에 따르면, 안티 패턴에는 나쁜 습관, 나쁜 관행 또는 나쁜 아이디어와 구별되는 두 가지 핵심 요소가 있습니다.

  1. 안티 패턴은 일반적으로 사용되는 프로세스, 구조 또는 행동 패턴으로, 처음에는 문제에 대한 적절하고 효과적인 대응으로 보이지만 좋은 결과보다 나쁜 결과가 더 많습니다.
  2. 안티패턴이 대처하려고 하는 문제에 대한 다른 해결책이 있습니다.이 솔루션은 문서화되어 반복 가능하며 안티패턴이 없는 경우에도 효과적이라는 것이 입증되었습니다.

일반적으로 사용되는 것에 대한 가이드는 패턴과 유사한 "3의 법칙"입니다. 안티 패턴이 되려면 적어도 [5]세 번 이상 발생해야 합니다.

사용하다

안티 패턴을 문서화하는 것은 문제 공간을 분석하고 전문 [6]지식을 얻는 효과적인 방법입니다.

일부 안티 패턴 설명은 패턴의 부정적인 결과를 문서화하는 데 그치는 데 불과하지만 적절한 안티 패턴 문서는 안티 [7]패턴을 개선하기 위한 대체 수단 또는 수단을 제공합니다.

소프트웨어 엔지니어링 안티패턴

소프트웨어 엔지니어링에서 안티패턴에는 큰 진흙덩어리(부족한) 설계, God 클래스(단일 클래스가 여러 클래스에 걸쳐 제어가 분산되지 않고 프로그램 내의 모든 제어를 처리함) 및 Poltergeists([7]클래스에서 다른 메서드를 호출하기 위해 존재하는 에페럴컨트롤러 클래스)가 포함됩니다.

프로젝트 관리 안티패턴

Antiatterns 책에 포함된 프로젝트 관리의 안티패턴에는 Blowhard Jambore(업계 전문가 과잉), 분석 마비, Viewgraph Engineering(실제 소프트웨어에 너무 많은 시간을 할애하고 너무 많은 시간을 할애), Death by Planning(비슷한 계획), Fear of Success(프로젝트에 대한 두려움) 등이 있습니다.완료), Corncob(사람과의 문제), 지적 폭력(전문용어나 난해한 테크놀로지를 사용한 경고), 불합리한 관리(나쁜 관리 습관), Smoke and Mirrors(판매원의 데모 및 프로토타입 과다 사용), Through It Over the Wall(유행 소프트웨어 엔지니어링을 구매하지 않고 개발자에게 강요)in), Fire Drill (long periods of monotony punctuated by short crises), The Feud (conflicts between managers), and e-mail Is Dangerous (situations resulting from ill-advised e-mail messages).[4]

「 」를 참조해 주세요.

레퍼런스

무엇을 지원하는가

  1. ^ Budgen 2003, 페이지 225
  2. ^ 앰블러 1998, 페이지 4
  3. ^ a b c Neill, Laplante & DeFranco 2011, 페이지 4
  4. ^ a b Neill, Laplante & DeFranco 2011, 페이지 5
  5. ^ Neill, Laplante & DeFranco 2011, 페이지 6
  6. ^ 히메네즈 2006년
  7. ^ a b Demeyer 2008, 페이지 102

원천

  • Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162.
  • Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4. As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'.
  • Ambler, Scott W. (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. p. 4. ISBN 0-521-64568-9. ...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns.
  • Jimenez, Edward (2006-04-24). "AntiPatterns". AntiPatterns. Retrieved 24 April 2006.
  • Demeyer, Serge (2008). "ObjectOriented Reengineering". In Mens, Tom; Demeyer, Serge (eds.). Software Evolution. Springer Science + Business Media. ISBN 9783540764403.

추가 정보

  • Koenig, Andrew (March–April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming. 8 (1): 46–48.
    • 나중에 재인쇄:
  • Laplante, Phillip A.; Neill, Colin J. (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9.
  • Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (ed.). Anti-Patterns in Project Management. John Wiley & Sons. ISBN 0-471-36366-9.
  • Stamelos, Ioannis (January 2010). "Software project management anti-patterns". Journal of Systems and Software. 83 (1): 52–59. doi:10.1016/j.jss.2009.09.016.

외부 링크

Wikimedia Commons에는 Anti-Patterns 관련 미디어가 있습니다.