Антипаттерн

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

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

Концепция также прекрасно подходит к машиностроению. Несмотря на то, что термин нечасто используется вне программной инженерии, концепция является универсальной.

Некоторые различаемые антипаттерны в программировании[править | править вики-текст]

См. Категория:Анти-паттерны для более подробного списка.

Антипаттерны в управлении разработкой ПО[править | править вики-текст]

  • Дым и зеркала (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): непредвидение возможности наступления событий в порядке, отличном от ожидаемого
  • Мышиная возня[источник не указан 575 дней]: Неоправданное создание множества мелких и абстракных классов для решения одной конкретной задачи более высокого уровня
  • Висящие концы: Интерфейс, большинство методов которого бессмысленны и реализуются "пустышками"
  • Золушкина туфелька: Попытка "натянуть" на объект уже имеющийся малоподходящий по смыслу интерфейс, вместо создания нового.
  • Членовредительство (Mutilation): Излишнее "затачивание" объекта под определенную очень узкую задачу таким образом, что он не способен будет работать с никакими иными, пусть и очень схожими задачами.

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

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

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

  • Паттерн проектирования: само по себе использование паттернов считается анти-паттерном — знаком того, что система не воплощает достаточный уровень абстракции (англ. Abstraction (computer science))[1].
  • Ненужная сложность (Accidental complexity): Внесение ненужной сложности в решение
  • Действие на расстоянии (Action at a distance): Неожиданное взаимодействие между широко разделёнными частями системы
  • Накопить и запустить (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных
  • Слепая вера (Blind faith): Недостаточная проверка (a) корректности исправления ошибки или (b) результата работы подпрограммы
  • Лодочный якорь (Boat anchor): Сохранение более не используемой части системы
  • Активное ожидание (Busy spin): Потребление ресурсов ЦПУ (процессорного времени) во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать асинхронное программирование (к примеру, систему сообщений или событий)
  • Кэширование ошибки (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): Внедрение слишком большого количества объектов синхронизации между потоками
  • Сохранение или смерть (Save or die): Сохранение изменений конфигурации на жесткий диск лишь при завершении приложения; приводит к тому, что в случае отказа в программе эти данные будут утеряны

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

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

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

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

Некоторые организационные антипаттерны[править | править вики-текст]

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

Некоторые социальные антипаттерны[править | править вики-текст]

Статус некоторых из них может быть спорным.

  • Цензура (Censorship): Подавление дискуссии и запрещение определённых тем в рамках обсуждения системы, в результате которого система ухудшается по качеству, функциональности или другим показателям
  • Концентрация власти (Political corruption, Concentrated power): Индивидуальное злоупотребление властью, даже с изначально хорошими помыслами
  • Демократия (Democracy): Большая группа индивидов не может принимать аргументированные решения, а руководствуется лишь поверхностной информацией.
  • Диктатура (Dictatorship): Не всегда один индивид имеет все навыки, необходимые для ведения проекта и грамотного управления.
  • Дискриминация (Discrimination): Концентрация на неуместных особенностях усиливает экономическую неэффективность и социальную напряжённость
  • Догмат (Dogmatic religion): Догмат подавляет индивидуальное мышление и тормозит прогресс
  • Нетерпимость (Intolerance): Настаивание на изменении нежелательных, но безопасных особенностей других людей влечёт усиление напряжённости и также, очень часто является задачей, которая отнимает время от проекта, и решение которой не имеет значительных плюсов
  • Монополия (Monopoly): Без соперничества большинство эффектов свободного рынка не работают, и частная компания не имеет стимула действовать максимально эффективно
  • Система голосования на основе большинства (Plurality voting system): Политика при голосовании на основе большинства вырождается в две полярно-противоположные партии, результатом чего является подавление других политических воззрений
  • Соревнование в популярности (Popularity contest): Популярность становится самодостаточной величиной и не сопоставима ни с каким другими параметрами или достоинствами
  • Сегрегация (Racial segregation): Разделение по равноправию весьма редко, если вообще существует; ведёт к напряжённости
  • Однопартийная система (Single-party system): Аналогично монополии, но внутри компании.
  • Тоталитаризм (Totalitarianism): Нередко подавление индивидуальности с переходом за определённые рамки, ведёт к напряжённости, которая отрицательно влияет на эффективность.
  • Преступление без жертв (Victimless crime): Подавление поведения создаёт субкультуру людей, постоянно живущих по другим законам, для которых эта правовая система является врагом
  • Охота на ведьм (Witch hunt): Попытки отыскать козла отпущения, но если проблема никогда не решается в действительности, результатом будет являться поиск всё новых и новых козлов отпущения
  • Нулевой Год (Year Zero): Социальное изменение является долгим процессом, ускорение его влечёт катастрофу

Шуточные антипаттерны[править | править вики-текст]

  • Паблик Морозов: Класс-потомок, созданный в соответствии с этим антипаттерном, выдает по запросу все данные класса-предка, независимо от степени их сокрытия. Название данного антипаттерна — это каламбур, основанный на созвучии ключевого слова public (паблик), часто означающего открытый доступ к методам и полям класса в объектно-ориентированных языках программирования, и имени пионера-героя Павлика Морозова, известного тем, что он выдал своего отца-кулака, занимавшегося вредительством будучи на руководящей должности в советской системе. Источником данного определения является блог пропагандистской направленности.

Литература[править | править вики-текст]

  • Perl Design Patterns — A free online book
  • William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. — John Wiley & Sons, 1998. — ISBN 0471197130.

Ссылки[править | править вики-текст]

  • Revenge of the Nerds. — «In the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.»