Информационные списки

Антипаттерн (Gumnhgmmyju)

Перейти к навигации Перейти к поиску

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

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

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

История[править | править код]

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

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

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

Классификация[править | править код]

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

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

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

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

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

Антипаттерны разработки[править | править код]

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

Антипаттерны в объектно-ориентированном программировании[править | править код]

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

Антипаттерны при написании кода[править | править код]

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

Методологические антипаттерны[править | править код]

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

Антипаттерны управления конфигурацией[править | править код]

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

Разные[править | править код]

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

Архитектурные антипаттерны[править | править код]

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

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

Организационные антипаттерны[править | править код]

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

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

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

  • Заочный менеджер (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): управленческая ситуация, в которой работник, который едва соответствует минимальным требованиям, перемещается от проекта к проекту или от команды к команде. Слабый работник называется «теплым телом», хотя настоящая проблема заключается в менеджере. Этот антипаттерн является противоположностью «Звёздного выскочки» в отношении навыков и потенциала.

Антипаттерны обстановки[править | править код]

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

См. также[править | править код]

Примечания[править | править код]

  1. Budgen, D. Software design. — Addison-Wesley, 2003. — ISBN 0-201-72219-4.
  2. Brown, 1998, Chapter 2.
  3. Smith C. U., 2000.
  4. http://c2.com/cgi/wiki?AntiPattern. Cunningham & Cunningham, Inc.. Дата обращения: 15 февраля 2006. Архивировано 3 апреля 2005 года.
  5. 1 2 3 Neill, Laplante, 2005.
  6. 1 2 3 4 5 6 Settas, 2011.
  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. 1 2 Rajiv Ramnath, Cheyney Loffing. Beginning IOS Programming For Dummies. — John Wiley & Sons, 2014-04-14. — С. 105. — 470 с. — ISBN 9781118799277. Архивировано 23 июля 2016 года.
  13. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 William J. Brown. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. — Wiley, 1998-04-03. — 156 с. — ISBN 0−471−19713−0. Архивировано 22 декабря 2015 года.
  14. Gary McLean Hall. Adaptive Code via C#: Agile coding with design patterns and SOLID principles. — Microsoft Press, 2014. — С. 267-268. — ISBN 978-0735683204.
  15. В оригинале: socio-political forces
  16. Phillip Laplante The Burning Bag of Dung—and Other Environmental Antipatterns Архивная копия от 19 сентября 2015 на Wayback Machine ACM Queue November 30, 2004 Volume 2, issue 7

Литература[править | править код]

Ссылки[править | править код]