Interested Article - Антипаттерн
- 2020-03-27
- 1
Антипаттерн ( англ. 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 ) [ прояснить ]
См. также
Примечания
- Budgen, D. Software design. — Addison-Wesley, 2003. — ISBN 0-201-72219-4 .
- , Chapter 2.
- .
- . Cunningham & Cunningham, Inc. . Дата обращения: 15 февраля 2006. 3 апреля 2005 года.
- ↑ .
- ↑ .
- Miroslav Kis. Information security antipatterns in software requirements engineering. In Proceedings of the 9th Conference on Pattern Language of Programs (Plop), 2002.
- John Long. Software reuse antipatterns. In ACM SIGSOFT Software Engineering Notes, volume26, page 4, July 2001.
- 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
- J. Krai and M. Zemlicka. The most important service-oriented antipatterns. In proceedings of the International Conference on Software Engineering Advances (ICSEA), 2007.
- P.A. Laplante, R.R. Hoffman, and G. Klein. Antipatterns in the creation of intelligent systems. IEEE Intelligent Systems, 22:91-95, 2007.
- ↑ Rajiv Ramnath, Cheyney Loffing. . — John Wiley & Sons, 2014-04-14. — С. 105. — 470 с. — ISBN 9781118799277 . 23 июля 2016 года.
- ↑ William J. Brown. . — Wiley, 1998-04-03. — 156 с. — ISBN 0−471−19713−0. 22 декабря 2015 года.
- Gary McLean Hall. . — Microsoft Press, 2014. — С. 267-268. — ISBN 978-0735683204 .
- В оригинале: socio-political forces
- 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» — — пародии на книгу «Банды четырёх»
- 2020-03-27
- 1