Антипаттерн в программировании

Лекция

Привет, Вы узнаете о том , что такое антипаттерн , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое антипаттерн , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

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

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

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

История

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

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

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

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

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

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

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

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

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

информационная безопасность
повторное использование кода
человеко-компьютерное взаимодействие
сервис-ориентированная архитектура
интеллектуальная информационная система

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

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

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

Базовый класс-утилита (BaseBean^[12]): Наследование функциональности из класса-утилиты вместо делегирования к нему.
Anemic Domain Model— боязнь размещать логику в объектах предметной области.
Вызов предка^[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): Объединение нескольких интерфейсов, разделенных согласно принципу изоляции интерфейсов (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++), в том числе там, где их использование не оправдано. Об этом говорит сайт https://intellect.icu . Это уменьшает понимание и сопровождение кода и замедляет компиляцию.

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

Программирование методом копирования-вставки (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) — самоуправление приводит к пассивности
Синдром вареной лягушки (Boiling Frog Syndrome) — постепенные отрицательные изменения замечают, когда уже поздно.
Горящий мешок навоза (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)

Вау!! 😲 Ты еще не читал? Это зря!

Исследование, описанное в статье про антипаттерн , подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое антипаттерн и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем