Interested Article - Антипаттерн

Антипаттерн ( англ. anti-pattern ) — это распространённый подход к решению класса часто встречающихся проблем, являющийся неэффективным, рискованным или непродуктивным . В отличие от шаблона проектирования , рассмотрение антипаттерна включает в себя как неправильное решение проблемы с его признаками и последствиями, так и выход из ситуации .

Термин происходит из информатики , из книги «Банды четырёх» « Шаблоны проектирования », которая заложила примеры практики хорошего программирования. Авторы назвали эти хорошие методы «паттернами», и противоположными им являются «антипаттерны».

Антипаттерны концептуально похожи на паттерны в том, что они документируют повторяющиеся решения общих проблем. Они известны как антипаттерны, потому что их использование (или злоупотребления) даёт негативные последствия .

История

С развитием ИТ-индустрии масштабы программных проектов и затраты ресурсов на них стремительно росли, что порождало большое количество проблем, что вставали перед программистами. Большинство этих проблем были типичными и встречались практически в каждом крупном проекте. В начале 90-х годов приобрели значительную популярность каталоги шаблонов проектирования , «паттернов» ( англ. design patterns ) — элегантных и проверенных на практике способов решения типичных задач. Паттерны и на сегодняшний день являются мощными и чрезвычайно популярны, однако многие разработчики, используя популярные паттерны в ситуациях, для которых они не презназначены, порождали этим больше проблем, чем решали. Кроме того, у ИТ-инженеров, как и у работников любой другой сферы деятельности, можно выделить типичные совершаемые ошибки, обусловленные недостаточной базой знаний или отсутствием опыта, спешкой и оказываемым давлением из-за сроков сдачи проекта, финансовыми ограничениями и прочим.

Впервые термин «антипаттерн» в смысле обобщенного описания типичного неудачного решения был применен в 1996 году Майклом Эйкройдом ( англ. Michael Akroyd ) на конференции «Object World West Conference», посвященной аспектам объектно-ориентированного программирования . В своей презентации «Антипаттерны: предотвращение неправильного использования объектов» Эйкройд обращал внимание на вредные, но частые программные конструкции, в частности, те, что противоречат принципам ООП. К тому же, для каждой такой конструкции он предлагал эффективную замену.

Термин в смысле «плохая идея» встречался и до Эйкройда, но не публиковался и особой популярностью не пользовался. И все же приписывать авторство одному человеку не стоит. Как считает Уильям Браун, автор книги «Антипаттерны: рефакторинг приложений, архитектур и проектов», антипаттерн — это этап эволюции понятия паттерна проектирования, расширения их модели.

Классификация

выделяет антипаттерны с трёх точек зрения: разработчика , архитектора и менеджера :

  • Антипаттерны разработки ( development antipatterns )
  • Архитектурные антипаттерны ( architectural antipatterns )
  • Организационные антипаттерны ( managerial antipatterns )

Нейл и Лаплантэ приводят четвёртый тип :

  • Антипаттерны среды ( environmental antipatterns )

Кроме того, антипаттерны были описаны для отдельных информационных технологий , таких как :

Антипаттерны разработки

Технические проблемы и решения, с которыми имеют дело программисты :

Антипаттерны в объектно-ориентированном программировании

  • (BaseBean ): Наследование функциональности из класса-утилиты вместо делегирования к нему.
  • — боязнь размещать логику в объектах предметной области.
  • (Call super): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка.
  • (Empty subclass failure): Создание класса (в Perl ), который не проходит «проверку пустоты подкласса» («Empty Subclass Test») из-за различного поведения по сравнению с классом, который наследуется от него без изменений.
  • Божественный объект (God object): Концентрация слишком большого количества функций в одной части системы (классе).
  • Объектная клоака (Object cesspool): Переиспользование объектов, находящихся в непригодном для переиспользования состоянии.
  • (Poltergeist ): Объекты, чьё единственное предназначение — передавать информацию другим объектам.
  • (Yo-yo problem): Чрезмерная размытость сильно связанного кода (например, выполняемого по порядку) по иерархии классов.
  • (Singletonitis): Неуместное использование паттерна одиночка .
  • (Friend zone): Неуместное использование дружественных классов и дружественных функций в языке C++.
  • (Interface soup ): Объединение нескольких интерфейсов , разделенных согласно принципу изоляции интерфейсов (Interface segregation), в один.
  • : Интерфейс, большинство методов которого бессмысленны и реализуются «пустышками».
  • Заглушка (Stub): Попытка «натянуть» на объект уже имеющийся малоподходящий по смыслу интерфейс, вместо создания нового.

Антипаттерны при написании кода

  • (Accidental complexity): Внесение ненужной сложности в решение.
  • (Action at a distance): Неожиданное взаимодействие между широко разделёнными частями системы.
  • (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных.
  • (Blind faith): Недостаточная проверка корректности исправления ошибки или результата работы подпрограммы.
  • (Boat anchor) : Сохранение более не используемой части системы.
  • (Busy spin, busy waiting): Потребление ресурсов ЦПУ (процессорного времени) во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать асинхронное программирование (к примеру, систему сообщений или событий).
  • (Caching failure): Забывать сбросить флаг ошибки после её обработки.
  • (The Diaper Pattern Stinks): Сброс флага ошибки без её обработки или передачи вышестоящему обработчику.
  • (Checking type instead of membership, Checking type instead of interface): Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс.
  • (Code momentum): Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы.
  • (Coding by exception): Добавление нового кода для поддержки каждого специального распознанного случая.
  • (Cryptic code): Использование аббревиатур вместо мнемоничных имён.
  • Жёсткое кодирование (Hard code): Внедрение предположений об окружении системы в слишком большом количестве точек её реализации.
  • (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование.
  • (Lava flow) : Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия.
  • Волшебные числа (Magic numbers): Использование числовых констант без объяснения их смысла.
  • (Procedural code): Когда другая парадигма является более подходящей.
  • Спагетти-код (Spaghetti code, иногда «макароны») : Код с чрезмерно запутанным порядком выполнения.
  • (Lasagnia code, или «лук» (onion)): Чрезмерное связывание между собой уровней абстракции, приводящее к невозможности изменения одного уровня без изменения остальных.
  • (Ravioli code, или «пельмени»): Объекты настолько «склеены» между собой, что практически не допускают рефакторинга.
  • (Soap bubble): Объект, инициализированый мусором, максимально долго притворяется, что содержит какие-то данные.
  • (Mutex hell): Внедрение слишком большого количества объектов синхронизации между потоками.
  • (Мета-)шаблонный рак (Template cancer): Повсеместное использование шаблонов (в основном C++), в том числе там, где их использование не оправдано. Это уменьшает понимание и сопровождение кода и замедляет компиляцию.

Методологические антипаттерны

  • Программирование методом копирования-вставки (Copy and paste programming) : Копирование (и лёгкая модификация) существующего кода вместо создания общих решений.
  • (De-Factoring): Процесс уничтожения функциональности и замены её документацией.
  • Золотой молоток (Golden hammer ): Сильная уверенность в том, что любимое решение универсально применимо. Название происходит от поговорки «когда в руках молоток, все проблемы кажутся гвоздями».
  • (Improbability factor): Предположение о невозможности того, что сработает известная ошибка.
  • Преждевременная оптимизация (Premature optimization): Оптимизация на этапе проектирования сегмента кода, приводящая к его усложнению или искажению.
  • Программирование методом подбора (Programming by permutation): Подход к разработке программного обеспечения небольшими изменениями.
  • /велосипеда (Reinventing the wheel ): Создание с нуля вместо использования хорошего готового решения.
  • (Reinventing the square wheel): Создание плохого решения, при условии, что уже существует известное решение лучше.
  • (Self-destruction): Фатальная ошибка либо нестандартное поведение программы, приводящая к отказу в обслуживании, возникшая вследствие другой менее серьёзной ошибки. Например, при возникновении ошибки, приложение начинает очень быстро и много писать в лог, вследствие чего заканчивается место на жёстком диске быстрее, чем это обнаружит мониторинг.
  • : Вынесение новой функциональности в отдельное приложение вместо расширения уже имеющегося. Чаще всего применяется, когда по каким-либо причинам (в основном, при нехватке времени либо нежелании менеджмента) внесение изменений в уже имеющийся код требует больших затрат, чем создание нового. При этом у клиента в конечном итоге работают два приложения, запускаясь одновременно либо попеременно друг из друга.
  • (Commit assasin): Внесение отдельных изменений в систему контроля версий без проверки влияния их на другие части программы. Как правило, после подобных коммитов работа коллектива парализуется на время исправления проблем в местах, которые ранее работали безошибочно.

Антипаттерны управления конфигурацией

  • Ад зависимостей (Dependency hell, на платформе Microsoft Windows также называется « DLL hell », «DLL-ад»): Разрастание графа взаимных зависимостей программных продуктов и библиотек, приводящее к сложности установки новых и удаления старых продуктов. В сложных случаях различные установленные программные продукты требуют наличия разных версий одной и той же библиотеки. В наиболее сложных случаях один продукт может косвенно потребовать сразу две версии одной и той же библиотеки.

Разные

  • (Smoke and mirrors ): Демонстрация того, как будут выглядеть ненаписанные функции (название происходит от двух излюбленных способов, которыми фокусники скрывают свои секреты).
  • Раздувание ПО (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов.
  • Функции для галочки : Превращение программы в конгломерат плохо реализованных и не связанных между собой функций (как правило, для того, чтобы заявить в рекламе , что функция есть).

Архитектурные антипаттерны

Типичные проблемы, связанные со структурой системы :

  • Инверсия абстракции (Abstraction inversion): Сокрытие части функциональности от внешнего использования, в надежде на то, что никто не будет её использовать.
  • (Ambiguous viewpoint ): Представление модели без спецификации её точки рассмотрения.
  • Большой комок грязи (Big ball of mud): Система с нераспознаваемой структурой.
  • Блоб (Blob ): см. Божественный объект (God object).
  • (Gas factory): Необязательная сложность дизайна.
  • (Input kludge ): Забывчивость в спецификации и выполнении поддержки возможного неверного ввода.
  • (Interface bloat): Разработка интерфейса очень мощным и очень сложным для реализации.
  • Волшебная кнопка (Magic pushbutton): Выполнение результатов действий пользователя в виде неподходящего (недостаточно абстрактного) интерфейса. Например, в системах типа Delphi это написание прикладной логики в обработчиках нажатий на кнопку.
  • (Re-Coupling): Процесс внедрения ненужной зависимости .
  • (Stovepipe System ): Редко поддерживаемая сборка плохо связанных компонентов.
  • Состояние гонки (Race hazard, Race condition): непредвидение возможности наступления событий в порядке, отличном от ожидаемого.
  • (Mutilation): Излишнее «затачивание» объекта под определенную очень узкую задачу таким образом, что он не способен будет работать с никакими иными, пусть и очень схожими задачами.
  • (Save or die): Сохранение изменений в конфигурации на жесткий диск лишь при завершении приложения; приводит к тому, что в случае отказа в программе эти данные будут утеряны

Организационные антипаттерны

Проблемы, с которыми встречаются менеджеры (или группы менеджеров) :

  • Аналитический паралич (Analysis paralysis) : неоправданно большие затраты на анализ и проектирование. Часто приводит к закрытию проекта до начала его реализации.
  • (Cash cow): при наличии продукта, приносящего выгоду без существенных вложений, не вкладываются средства в развитие и разработку новых продуктов.
  • (Continuous obsolescence) : выделение непропорционально больших усилий на портирование системы в новые окружения.
  • (Cost migration): перенос расходов на проект к слабому отделу или бизнес-партнёру.
  • Раздутый улучшизм (Creeping featurism): добавление новых улучшений в ущерб суммарному качеству системы.
  • (Creeping elegance): непропорциональное улучшение красивости кода в ущерб функциональности и суммарному качеству системы.
  • Разработка комитетом (Design by committee) : разработка проекта без централизованного управления или без компетентного руководства.
  • (Escalation of commitment): продолжение реализации решения после того, как доказана его ошибочность.
  • (I told you so): игнорирование мнения эксперта.
  • (Management by numbers): излишнее внимание к численным показателям, имеющим очень косвенное отношение к управляемой системе, сложным для получения, либо подверженным эффекту Гудхарта .
  • Драконовские меры (Management by perkele): неоправданно жесткий стиль управления.
  • (Mushroom management) : недостаточное информирование работников о выполняемой работе.
  • (Scope creep): потеря контроля над разрастанием проекта.
  • Привязка к поставщику (Vendor lock-in) : жёсткая привязка к поставщику.
  • (Warm Bodies) : человек, чей вклад в проект под сомнением.
  • (Single head of knowledge, SHOK): когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде, а с его уходом работа останавливается.
  • (Knight in shining armor, KISA): когда на сцене появляется человек, который пытается починить всё, не сообщая никому, что он сделал и почему.

Нейл и Лапланте приводят следующие антипаттерны :

  • (Absentee Manager): менеджер ведет себя уклончиво или невидим в течение длительного времени - он прячется где-то в офисе или вдали от офиса.
  • (All You Have Is A Hammer): однонаправленное управление, где одни и те же приемы используются на всех подчиненных и во всех ситуациях. Иногда также называется «One-Trick Pony».
  • (Cage Match Negotiator): любой менеджер, который упрям не по разуму и использует подход к управлению «Победа любой ценой» или «Я прав, а вы нет». У них часто есть кофейная кружка с «Правилами управления»: «Правило №1: Босс всегда прав. Правило №2: Если босс не прав, см. Правило №1».
  • Доппельгангер (Doppelganger): менеджер или коллега, с которым то легко работать, то трудно.
  • (Fruitless Hoops): вы готовите для менеджеров всё новые и новые данные, нужные им для принятия решения, но менеджеры так и не принимают никакого решения, продолжая запрашивать у вас данные. Вы не знаете, зачем им нужны эти данные.
  • (Golden Child): «Золотой ребенок» появляется в ситуациях, когда менеджер предоставляет особую ответственность, возможность, признание или вознаграждение члену своей команды на основе личных взаимоотношений с ним и вопреки его действительным действиям. Всех раздражает «Золотое дитя», но настоящая проблема заключается в менеджере.
  • (Headless Chicken): менеджер без фокуса и плана, который никогда ничего не заканчивает.
  • (Leader Not Manager): подчеркивает важность эффективного руководства.
  • (Managerial Cloning): менеджеры среднего звена, начинающие со временем вести себя, как их начальники.
  • (Manager Not Leader): такой менеджер хорошо справляется с административными и управленческими обязанностями, но не обладает лидерскими способностями.
  • (Metric Abuse): неправильное использование метрик из-за некомпетентности или умышленного манипулирования данными.
  • (Mr. Nice Guy): менеджер, который сосредотачивается на том, чтобы быть другом каждого, в конечном итоге разочаровывает всех и не справляется со своими обязанностями.
  • (Mushroom Management): ситуация, в которой руководство не может эффективно общаться с персоналом. По сути, информация намеренно скрывается, чтобы все были «толстыми, глупыми и счастливыми». Название связано с аналогией: шампиньоны выращивают в темноте и в навозе.
  • (Plate Spinning): менеджер скрывает свою неэффективность, заставляя работников заниматься трудоёмкой и бесполезной работой.
  • (Proletariat Hero): менеджер ведёт себя с подчинёнными, как с идеальными работниками, но это лишь его опора, используемая для маскировки плохого управления. Это форма «мотивации» персонала, которая дает повод руководству повысить ожидаемые результаты или получить больше с меньшими затратами.
  • (Rising Upstart): суперзвезды, которые не могут терять время на обучение и поиск своего места. Иногда это может быть из-за невежества (они не знают, чего не знают), а иногда из-за нетерпения (они знают то, чего не знают другие). Такой выскочка представляет настоящий вызов для всех, кроме самых опытных менеджеров.
  • (Road to Nowhere): Отсутствие плана вызывает замешательство и кризис руководства.
  • (Spineless Executive): любой менеджер, который не имеет смелости вступить в необходимую конфронтацию или справиться со сложной ситуацией. Вместо этого он полностью избегает конфронтации или ситуации или просит вас сообщить ему плохие новости.
  • (Three-Headed Knight): нерешительный менеджер.
  • (Ultimate Weapon): менеджер объявляет, что все могут положиться на выдающихся сотрудников настолько, что эти сотрудники станут проводником всего.
  • (Warm Bodies): управленческая ситуация, в которой работник, который едва соответствует минимальным требованиям, перемещается от проекта к проекту или от команды к команде. Слабый работник называется «теплым телом», хотя настоящая проблема заключается в менеджере. Этот антипаттерн является противоположностью «Звёздного выскочки» в отношении навыков и потенциала.

Антипаттерны обстановки

Проблемы, вызванные доминирующей в организации структурой и социальной моделью, являющейся результатом действующей в организации общественной политики :

  • ( Ant Colony ) — под внешней красотой скрывается насаждение целей [ прояснить ] .
  • ( Atlas Shrug ) — после временного успеха начинается спад [ прояснить ] .
  • ( Autonomous Collective ) — самоуправление приводит к пассивности [ прояснить ] .
  • Синдром варёной лягушки ( ) — постепенные отрицательные изменения замечают, когда уже поздно.
  • ( Burning Bag of Dung ) — менеджер оставляет соседей (смежников, подопечных, преемника) в щекотливой ситуации.
  • Увлечение модными словами ( Buzzword Mania ) — руководство жонглирует словами, которые мало кто из подопечных понимает.
  • ( Deflated Balloon ) — лучшие годы компании позади, но она не может этого осознать и снизить расходы.
  • ( Divergent Goals ) [ прояснить ]
  • ( Dogmatic About Dysfunction )
  • ( Dunkirk Spirit ) [ прояснить ]
  • ( Emperor’s New Clothes ) — по одноимённой сказке
  • ( Fairness Doctrine ) [ прояснить ]
  • ( Fools Rush In ) [ прояснить ]
  • ( Founderitis ) [ прояснить ]
  • ( Geek Hazing ) — начинающих загружают большим количеством тривиальных задач, которые не помогают им учиться.
  • ( Institutional Mistrust ) [ прояснить ]
  • ( Kiosk City ) — каждый отдел вырабатывает свой собственный механизм обмена информацией.
  • ( Mediocracy )
  • ( One-Eyed King ) [ прояснить ]
  • ( Orange Stand Economics ) — плохая оценка расходов.
  • ( Pitcairn Island ) [ прояснить ]
  • Потёмкинские деревни
  • ( Process Clash ) [ прояснить ]
  • ( Rubik’s Cube ) [ прояснить ]
  • ( Shoeless Children ) [ прояснить ]
  • ( Worshipping the Golden Calf ) [ прояснить ]

См. также

Примечания

  1. Budgen, D. Software design. — Addison-Wesley, 2003. — ISBN 0-201-72219-4 .
  2. , Chapter 2.
  3. .
  4. . Cunningham & Cunningham, Inc. . Дата обращения: 15 февраля 2006. 3 апреля 2005 года.
  5. .
  6. .
  7. Miroslav Kis. Information security antipatterns in software requirements engineering. In Proceedings of the 9th Conference on Pattern Language of Programs (Plop), 2002.
  8. John Long. Software reuse antipatterns. In ACM SIGSOFT Software Engineering Notes, volume26, page 4, July 2001.
  9. Paula Kotze, Karen Renaud, and Judy van Biljona. Don’t do this — pitfalls in using anti-patterns in teaching human-computer interaction principles. Computers and Education, 50(3):979-1008, April 2008
  10. J. Krai and M. Zemlicka. The most important service-oriented antipatterns. In proceedings of the International Conference on Software Engineering Advances (ICSEA), 2007.
  11. P.A. Laplante, R.R. Hoffman, and G. Klein. Antipatterns in the creation of intelligent systems. IEEE Intelligent Systems, 22:91-95, 2007.
  12. Rajiv Ramnath, Cheyney Loffing. . — John Wiley & Sons, 2014-04-14. — С. 105. — 470 с. — ISBN 9781118799277 . 23 июля 2016 года.
  13. William J. Brown. . — Wiley, 1998-04-03. — 156 с. — ISBN 0−471−19713−0. 22 декабря 2015 года.
  14. Gary McLean Hall. . — Microsoft Press, 2014. — С. 267-268. — ISBN 978-0735683204 .
  15. В оригинале: socio-political forces
  16. Phillip Laplante от 19 сентября 2015 на Wayback Machine ACM Queue November 30, 2004 Volume 2, issue 7

Литература

  • — A free online book and wiki
  • William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray. . — John Wiley & Sons, 1998. — ISBN 0471197130 .
  • William J. Brown, Hays W. "Skip" McCormick, Scott W. Thomas. . — Wiley, 1999. — ISBN 978-0-471-32929-9 .
  • William J. Brown, Hays W. "Skip" McCormick, Scott W. Thomas. AntiPatterns in Project Management. — Wiley, 2000. — ISBN 978-0-471-36366-8 .
  • Neal Ford, Matthew McCullough, Nathaniel Schutta. . — Addison-Wesley, 2012-08-15. — 395 с. — ISBN 9780132963374 .
  • Chad Pytel, Tammer Saleh. . — Addison-Wesley Professional, 2010-11-09. — 347 с. — ISBN 9780132660068 .
  • Neill, Colin J. (англ.) // INCOSE International Symposium. — 2012. — Vol. 22 , no. 1 . — P. 1233—1245 . — ISSN .
  • Colin J. Neill, Philip A. Laplante. Antipatterns: Identification, Refactoring, and Management. — CRC Press, 2005. — ISBN 978-1-4200-3124-9 .
  • Dimitrios Settas. Software project antipattern knowledge management (doctoral thesis). — Thessaloniki, Greece: Aristotle University, 2011.
  • Аллен Э. Типичные ошибки проектирования. — Издательский дом «Питер», 2003. — 224 с. — ISBN 5-887827-304 -6.
  • Smith C. U., Williams L. G. (англ.) // 2nd International Workshop on Software and Performance. — 2000.

Ссылки

  • Перевод статьи «Resign Patterns» — — пародии на книгу «Банды четырёх»


Источник —

Same as Антипаттерн