Антишаблон в разработке программного обеспечения , управлении проектами и бизнес - процессах — это распространенный ответ на повторяющуюся проблему, который обычно неэффективен и рискует оказаться крайне контрпродуктивным. [1] [2] Этот термин, придуманный в 1995 году программистом Эндрю Кенигом , был вдохновлен книгой « Шаблоны проектирования » (в которой освещается ряд шаблонов проектирования при разработке программного обеспечения , которые ее авторы считали очень надежными и эффективными) и впервые опубликован. в своей статье в Journal of Object-Oriented Programming . [3] Еще один документ, представленный Майклом Экройдом в 1996 году на конференции Object World West, также документировал антипаттерны. [3]
Однако именно книга AntiPatterns 1998 года не только популяризировала эту идею, но и расширила ее сферу за пределы области проектирования программного обеспечения, включив в нее архитектуру программного обеспечения и управление проектами. [3] Другие авторы расширили его еще больше, включив в него экологические, организационные и культурные антипаттерны. [4]
По мнению авторов Design Patterns , в антипаттерне есть два ключевых элемента, которые отличают его от плохой привычки, плохой практики или плохой идеи:
Руководством к тому, что обычно используется, является «правило трех», аналогичное правилу для шаблонов: чтобы быть анти-шаблоном, его возникновение должно быть засвидетельствовано как минимум три раза. [5]
Документирование антипаттернов может быть эффективным способом анализа проблемного пространства и сбора экспертных знаний. [6]
В то время как некоторые описания анти-шаблонов просто документируют неблагоприятные последствия шаблона, хорошая документация анти-шаблона также предоставляет альтернативу или средство улучшения анти-шаблона. [7]
В разработке программного обеспечения антишаблоны включают в себя «большой ком грязи » (отсутствие) дизайна, « Класс Бога» (когда один класс управляет всем управлением в программе , а не управление распределяется между несколькими классами), магические числа (когда уникальное значение с необъяснимым значением или множественными вхождениями, которые можно заменить именованной константой) и полтергейсты (эфемерные классы контроллеров, которые существуют только для вызова других методов классов). [7]
Это указывает на программную систему , которой не хватает воспринимаемой архитектуры. Хотя это и нежелательно с точки зрения разработки программного обеспечения, такие системы широко распространены на практике из-за давления со стороны бизнеса, текучести разработчиков и энтропии кода .
Этот термин был популяризирован в одноименной статье Брайана Фута и Джозефа Йодера 1997 года, в которой этот термин определяется:
«Большой комок грязи» — это беспорядочно структурированные, разросшиеся, неряшливые джунгли с изоляционной лентой и проволокой, со спагетти-кодом . Эти системы демонстрируют безошибочные признаки нерегулируемого роста и неоднократного целесообразного ремонта. Информация беспорядочно распределяется между удаленными элементами системы, часто до такой степени, что почти вся важная информация становится глобальной или дублируется.
Общая структура системы, возможно, никогда не была четко определена.
Если бы это было так, возможно, оно разрушилось до неузнаваемости. Программисты, обладающие хоть каплей архитектурного чутья, избегают этих трясин. Только те, кого не волнует архитектура и, возможно, доволен инерцией повседневной работы по заделыванию дыр в этих разрушающихся дамбах, довольны работой над такими системами.
- Брайан Фут и Джозеф Йодер, «Большой комок грязи». Четвертая конференция по шаблонам языков программ (PLoP '97/EuroPLoP '97), Монтичелло, Иллинойс, сентябрь 1997 г.
Фут и Йодер считают Брайана Марика автором термина «большой ком грязи» для обозначения такого рода архитектуры. [8]
Антишаблоны управления проектами, включенные в книгу «Антипаттерны» , включают Blowhard Jamboree (избыток отраслевых экспертов), паралич анализа , Viewgraph Engineering (слишком много времени тратится на создание презентаций и недостаточно на реальное программное обеспечение), Death by Planning (аналогично, слишком много времени тратится на создание презентаций и недостаточно на реальное программное обеспечение). планирование), Страх успеха (иррациональные страхи перед завершением проекта), Кукурузный початок (трудности с людьми), Интеллектуальное насилие (запугивание посредством использования жаргона или загадочных технологий), Иррациональное управление (плохие привычки управления), Дым и зеркала (чрезмерное использование демонстраций и прототипов от продавцов), Throw It Over the Wall (навязывание модных методов разработки программного обеспечения разработчикам без всякой поддержки), Fire Drill (длительные периоды монотонности, перемежающиеся короткими кризисами), The Feud (конфликты между менеджерами) и e -Почта опасна (ситуации, возникающие в результате необдуманных сообщений электронной почты). [4]
Как описано Лонгом (2001), антишаблоны проектирования — это «очевидные, но неправильные решения повторяющихся проблем».
...общие подходы к решению повторяющихся проблем, которые оказываются неэффективными. Эти подходы называются антипаттернами.
Антипаттерн подобен шаблону, за исключением того, что вместо решения он дает нечто, внешне похожее на решение, но таковым не являющееся.
