WikiDer > Анти-шаблон

Anti-pattern

An антипаттерн это обычная реакция на повторяющуюся проблему, которая обычно оказывается неэффективной и может оказаться крайне контрпродуктивной.[1][2] Термин, введенный в 1995 г. Эндрю Кениг,[3] был вдохновлен книгой, Шаблоны проектирования, в котором выделяется ряд шаблоны проектирования в разработка программного обеспечения что его авторы считают весьма надежным и эффективным.

Термин был популяризирован тремя годами позже в книге Антипаттерны, который распространил его использование за пределы области разработки программного обеспечения, чтобы неформально относиться к любому обычно заново изобретенному, но плохому решению проблемы. Примеры включают паралич анализа, карго культ программирование, марш смерти, групповое мышление и привязка к поставщику.

Определение

По мнению авторов Шаблоны проектирования, должны присутствовать как минимум два ключевых элемента, чтобы формально отличить действительный антипаттерн от простой плохой привычки, плохой практики или плохой идеи:

  1. Часто используемый процесс, структура или модель действий, которые, несмотря на то, что изначально кажутся подходящими и эффективными ответами на проблему, имеют больше плохих последствий, чем хороших.
  2. Существует другое решение, которое задокументировано, воспроизводимо и доказало свою эффективность.

Примеры

Социальные и деловые операции

Организационная

  • Аналитический паралич: Проект застопорился на этапе анализа, неспособный обеспечить поддержку ни одного из потенциальных планов подхода.
  • Навес для велосипедов: Придание непропорционально большого значения тривиальным вопросам
  • Передний край: Использование передовых технологий, которые до сих пор не протестированы или нестабильны, что приводит к перерасходу средств, недостаточной производительности или задержке доставки.
  • Сторонняя апатия: Явление, при котором люди с меньшей вероятностью предложат или не предложат помощь нуждающемуся в присутствии других.
  • Дойная корова: Прибыльный устаревший продукт, который часто приводит к самоуспокоенности по поводу новых продуктов.
  • Дизайн комитетом: Результат наличия множества участников в дизайне, но отсутствие единого видения.
  • Эскалация обязательств: Неспособность отменить решение, когда оно оказывается неправильным
  • Групповое мышление: Коллективное состояние, при котором члены группы начинают (часто неосознанно) думать одинаково и отвергать разные точки зрения.
  • Управление по целям: Управление по цифрам, сосредоточьтесь исключительно на количественных критериях управления, когда они несущественны или слишком дороги для приобретения
  • Микроменеджмент: Неэффективность из-за чрезмерного наблюдения, надзора или другого практического участия со стороны руководства
  • Моральный ущерб: Изоляция лица, принимающего решения, от последствий его решения
  • Управление грибами: Держать сотрудников «в темноте и кормить навозом» (также «оставлять тушиться и, наконец, консервировать»)
  • Принцип Питера: Постоянно продвигать в остальном хорошо работающих сотрудников до уровня их некомпетентности, где они остаются на неопределенный срок.[4]
  • Управление чайками: Управление, при котором менеджеры взаимодействуют с сотрудниками только тогда, когда возникает проблема, когда они «прилетают, создают много шума, обрушиваются на всех, не решают проблему, а затем улетают»
  • Печная труба или силосы: Организационная структура изолированных или полуизолированных команд, в которой слишком много коммуникаций происходит вверх и вниз по иерархии, а не напрямую с другими командами в организации.
  • Приведение типов: Закрепление успешных сотрудников на слишком безопасных, узко определенных, предсказуемых ролях, основанных на их прошлых успехах, а не на их потенциале.
  • Привязка к поставщику: Делает систему чрезмерно зависимой от компонента, поставляемого извне.

Управление проектом

  • Телега перед лошадью: Сосредоточение слишком большого количества ресурсов на одной стадии проекта вне его последовательности.
  • Марш смерти: Проект, сотрудники которого, ожидая его провала, вынуждены продолжать, часто с большим переутомлением, руководство, которое отрицает[5]
  • Правило девяноста девяноста: Склонность недооценивать время, необходимое для завершения проекта, когда он «почти готов».
  • Сверхинженерия: Трата ресурсов делает проект более надежным и сложным, чем необходимо.
  • Ползучесть прицела: Неконтролируемые изменения или непрерывный рост объема проекта, или добавление новых функций в проект после того, как исходные требования были составлены и приняты (также известное как распространение требований и ползучесть функций)
  • Дым и зеркала: Демонстрация нереализованных функций, как если бы они уже были реализованы
  • Закон Брукса: Добавление дополнительных ресурсов в проект для увеличения скорости, когда проект уже замедлен из-за накладных расходов на координацию.
  • Позолота: Продолжение работы над задачей или проектом после того момента, когда дополнительные усилия не добавят ценности.

Программная инженерия

Разработка программного обеспечения

Объектно-ориентированного программирования

  • Модель анемической области: Использование модель предметной области без всяких бизнес-логика. Объекты модели предметной области не могут гарантировать их правильность в любой момент, потому что их логика проверки и изменения размещена где-то снаружи (скорее всего, в нескольких местах). Мартин Фаулер считает это антипаттерном, но некоторые не согласны с тем, что это всегда антипаттерн.[6]
  • Звоните супер: Требование подклассов для вызова переопределенного метода суперкласса
  • Задача круг – эллипс: Подтип типы переменных на основе подтипов значений
  • Круговая зависимость: Введение ненужных прямых или косвенных взаимозависимостей между объектами или программными модулями.
  • Постоянный интерфейс: Использование интерфейсов для определения констант
  • Бог возражает: Сосредоточение слишком большого количества функций в одной части дизайна (классе)
  • Помойка объекта: Повторное использование объектов, состояние которых не соответствует (возможно, неявному) контракту для повторного использования.
  • Объектная оргия: Неспособность должным образом инкапсулировать объекты, разрешающие неограниченный доступ к их внутренним компонентам.
  • Полтергейсты: Объекты, единственная цель которых - передать информацию другому объекту.
  • Последовательная связь: Класс, который требует, чтобы его методы вызывались в определенном порядке.
  • Шаблон Singleton: Этот шаблон проектирования создает взаимосвязь и считается плохим решением.
  • Йо-йо проблема: Структура (например, наследования), которую трудно понять из-за чрезмерной фрагментации

Программирование

  • Случайная сложность: Задачи программирования, которые можно решить с помощью более совершенных инструментов (в отличие от существенной сложности, присущей решаемой проблеме)
  • Действия на расстоянии: Неожиданное взаимодействие между удаленными друг от друга частями системы.
  • Якорь для лодки: Сохранение части системы, которая больше не используется
  • Занято ожиданием: Потребление ЦПУ ожидая, что что-то произойдет, обычно путем повторной проверки вместо обмена сообщениями
  • Ошибка кеширования: Забыть очистить кеш, содержащий отрицательный результат (ошибку), после того, как условие ошибки было исправлено.
  • Культ карго: Использование шаблонов и методов, не понимая, почему
  • Кодирование по исключению: Добавление нового кода для обработки каждого особого случая по мере его распознавания.
  • Шаблон дизайна: Использование шаблонов само по себе было названо анти-шаблоном, признаком того, что система не использует достаточно абстракция[7]
  • Ошибка скрытия: Перехват сообщения об ошибке до того, как его можно будет показать пользователю, и либо ничего не показывать, либо показывать бессмысленное сообщение. Этот антипаттерн также называется Выкройка подгузника. Также может относиться к стиранию Трассировки стека во время обработки исключений, что может затруднить отладку.
  • Жесткий код: Встраивание предположений о среде системы в ее реализацию.
  • Код лазаньи: Программы, структура которых состоит из слишком большого количества уровней наследования.
  • Поток лавы: Сохранение нежелательного (избыточного или некачественного) кода, потому что его удаление слишком дорого или имеет непредсказуемые последствия.[8][9]
  • Последовательность переключения петли: Кодирование набора последовательных шагов с помощью переключателя внутри оператора цикла.
  • Магические числа: Включение необъяснимых чисел в алгоритмы
  • Волшебные струны: Реализация предположительно маловероятных сценариев ввода, таких как сравнения с очень конкретными строками, для маскировки функциональности.
  • Повторяя себя: Написание кода, который снова содержит повторяющиеся шаблоны и подстроки; избегать с раз и только раз (принцип абстракции)
  • Стрельба по посланнику: Выброс исключений из области действия надстройки или подписчика в ответ на допустимый ввод, особенно когда это приводит к сбою внешней области.
  • Операция с дробовиком: Разработчик добавляет функции в кодовую базу приложения, которые охватывают множество разработчиков или реализаций за одно изменение.
  • Мягкий код: Хранение бизнес-логики в файлах конфигурации, а не в исходном коде[10]
  • Код спагетти: Программы, структура которых трудно понять, особенно из-за неправильного использования структур кода.

Методологические

Управление конфигурацией

Смотрите также

Рекомендации

  1. ^ Будген, Д. (2003). Разработка программного обеспечения. Харлоу, англ .: Addison-Wesley. п. 225. ISBN 0-201-72219-4. «Как описано в Long (2001), антипаттерны проектирования - это« очевидные, но неправильные решения повторяющихся проблем »».
  2. ^ Скотт В. Эмблер (1998). Шаблоны процессов: построение крупномасштабных систем с использованием объектных технологий. Кембридж, Великобритания: Издательство Кембриджского университета. п. 4. ISBN 0-521-64568-9. «... общие подходы к решению повторяющихся проблем, которые оказываются неэффективными. Эти подходы называются антипаттернами».
  3. ^ Кениг, Эндрю (март – апрель 1995 г.). «Паттерны и антипаттерны». Журнал объектно-ориентированного программирования. 8 (1): 46–48.; позже был перепечатан в: Восхождение, Линда (1998). Справочник по шаблонам: методы, стратегии и приложения. Кембридж, Великобритания: Издательство Кембриджского университета. п. 387. ISBN 0-521-64818-1. «Антипаттерн похож на образец, за исключением того, что вместо решения он дает нечто, внешне похожее на решение, но не таковое».
  4. ^ Питер, Лоуренс Дж. (1969), Принцип Питера: почему дела всегда идут не так; Книги о буканьере 1969 г., ISBN 9781568491615
  5. ^ Йордон, Эдвард (1997), Марш смерти; ISBN 978-0137483105
  6. ^ «Модель анемического домена - это не антипаттерн, это твердый дизайн». SAPM: Блог курса. 4 февраля 2014 г.. Получено 3 января 2015.
  7. ^ «Месть ботаников». В мире объектно-ориентированных приложений вы часто слышите о «шаблонах». Интересно, не являются ли эти шаблоны иногда свидетельством того, что работает человеческий компилятор case (c). Когда я вижу закономерности в своих программах, я считаю это признаком проблемы. Форма программы должна отражать только ту проблему, которую необходимо решить. Любая другая регулярность в коде является признаком, по крайней мере для меня, того, что я использую недостаточно мощные абстракции - часто я вручную создаю расширения некоторых макросов, которые мне нужно написать.
  8. ^ "Поток лавы". antipatterns.com. 2 апреля 2017.
  9. ^ «Недокументированные антипаттерны« потока лавы »усложняют процесс». Icmgworld.com. 14 января 2002 г. Архивировано с оригинал 11 марта 2011 г.. Получено 3 мая 2010.
  10. ^ Пападимулис, Алекс (10 апреля 2007 г.). «Мягкое кодирование». thedailywtf.com. Получено 27 июн 2011.
  11. ^ «Каждый дурак - свой инструмент». linkedin.com. 23 января 2017.
  12. ^ «Фабрика функций». ProductPlan.

дальнейшее чтение

  1. Laplante, Phillip A .; Нил, Колин Дж. (2005). Антипаттерны: идентификация, рефакторинг и управление. Публикации Ауэрбаха. ISBN 0-8493-2994-9.
  2. Браун, Уильям Дж .; Malveau, Raphael C .; McCormick, Hays W .; Томас, Скотт В. (2000). Хадсон, Тереза ​​Хадсон (ред.). Антипаттерны в управлении проектами. Джон Уайли и сыновья. ISBN 0-471-36366-9.

внешняя ссылка