А

Антипаттерн

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

Концепция антипаттерну является универсальной и пригодна не только для программной инженерии, но и для практически любой сферы человеческой деятельности; впрочем, срок не получил распространения за пределами IT-индустрии.

Понятие антипаттерну появилось тогда, когда программисты поняли, что описывать и документировать необходимо не только хорошие идеи, но и плохие. Правильно сформулированный антипаттерн состоит не только из описания типичной ошибки, но и объясняет, почему такое решение выглядит привлекательным (например, экономит время разработки, действительно работает в некотором ограниченном контексте), к каким негативным последствиям оно приводит, и каким паттерном желательно его заменить.

Важнейшая цель документации антипаттернив — облегчить возможность распознавания вредоносного решения и успешного исправления ошибок еще на ранних этапах работы. Антипаттерн не просто предостерегает «Не делай этого!», А указывает инженеру на то, что он, возможно, не осознает, что решение такого типа принесет гораздо больше вреда, чем пользы.

Существует 3 ключевых правила, когда решение считается антипаттерном:

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

История

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

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

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

Примеры

Антипаттерны проектирования программного обеспечения

  • Инверсия абстракции (Abstraction inversion) — сокрытие части функциональности от внешнего использования, в надежде на то, что никто не будет ее использовать.
  • Неоднозначная точка зрения (Ambiguous viewpoint) — представление модели без спецификации ее точки рассмотрения.
  • Database-as-IPC Использование базы данных, как очереди сообщений для рутинных внутренних коммуникаций, когда можно применить более простой механизм, например сокеты.
  • Золотое покрытие (Gold plating) Продолжение работы над задачей или проектом, когда стоимость работы превышает выгоду от ее эффективности.
  • Внутришньоплатформний эффект (Inner-platform effect): Система может так настраиваться, что становится бедной копией среды разработки.
  • Ляп на входе Невозможность определить и реализовать обработку ошибки из-за неправильных входные данные.
  • Перегруженный интерфейс: Проектирование столь сложного интерфейса, его крайне трудно реализовать.
  • Магическая кнопка (Magic pushbutton): Кодирование логики реализации класса непосредственно в коде элементов интерфейса, без использования абстракции.
  • Состояние гонки (Race hazard): Результат программы зависит от последовательности неконтролируемых событий.
  • Дымоход (Stovepipe system): Легкий сопровождение сборки плохо связанных элементов.

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

  • Излишняя сложность (Accidental complexity): Представление необязательной сложности в программе.
  • Действия на расстоянии (Action at a distance): Неожиданное взаимодействие между изолированными частями программы.
  • Слепая вера (Blind faith): не проверка, исправление ошибки, или результата подпрограммы
  • Пятое колесо (Boat anchor): Хранение частей кода, которые не используются.
  • Занят ожиданием (Busy waiting) Использование CPU при очкування какого-то действия, обычно для продолжительных циклов проверки, вместо использования сообщений событий.
  • Кэш отказов (Caching failure): Забывание сбросить флажок ошибки после ее исправления.
  • Культ грузового программирования (Cargo cult programming) Использование паттернов и методов без понимания цели.
  • Кодирования исключений (Coding by exception): Добавление нового кода для обработки каждой исключительной ситуации.
  • Сокрытие ошибок (Error hiding): Перехват сообщений, свидетельствующих об ошибке, до того, как они поступят к пользователю, вместо реального исправления ошибок.
  • Жесткий код (Hard code): Вложения предположений о среде системы в ее реализации.
  • Мягкий код (Soft code): Хранение бизнес-логики в конфигурационных файлах, а не в коде.
  • Последовательность циклов-ветвлений (Loop-switch sequence): Кодирование последовательности шагов используя ветвления внутри циклов.
  • Магические числа (Magic numbers): Включение непрокоментованих и незадокументированных констант в алгоритм.
  • Повторение кода (Repeating yourself): Написание кода, который повторяется снова и снова, вместо организации подпрограмм.
  • Код Спагетти (Spaghetti code): Программы, структуры которых едва понятны из-за неправильного применения структур кода.
  • Код Лазаньи (Lasagna code) Программа, структура которой содержит много уровней.

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

  • BaseBean: Наследование функциональности из служебного класса, а не делегирование ему решения проблем.
  • Супер вызов (Call super) Обязательные подклассы для вызова переопределенного метода суперкласса.
  • Проблема круг-эллипс (Circle-ellipse problem): Использование подтипа переменной-типа или базового подтипа-значения.
  • Кольцевые зависимости (Circular dependency): Представление ненужных прямых или косвенных взаимных зависимостей между объектами и модулями программы.
  • Интерфейс констант (Constant interface): Использование интерфейсов для определения констант.
  • Божественный объект (God object): Концентрирование функционала в одной части проекта (класса, методе).
  • Объект выгребной ямы (Object cesspool): Повторное использование объекта, состояние которого не допускает повторное использование.
  • Объект оргии (Object orgy): Нет сил должным образом инкапсулировать объекты дает неограниченный доступ к его внутренним функциям.
  • Полтергейсты (Poltergeists) Объекты, целью которых является передача информации на другие объекты.
  • Последовательное соединение (Sequential coupling) Класс требует, чтобы его методы вызывались в определенном порядке.
  • Проблема Йо-йо (Yo-yo problem): Структуру (например, наследование), трудно понять из-за чрезмерной фрагментации.

Антипаттерны методологий программирования

  • Программирование вставкой (Copy and paste programming): Копирование (и изменение) существующего кода, вместо того, чтобы создавать новое решение.
  • Золотой молоток (Golden hammer): Предположение, что любимое решение является универсальным.
  • Коэффициент невероятности (Improbability factor): Предположение, что вероятность возникновения ошибки достаточно низкой.
  • Это придумал не я (Not Invented Here (NIH) syndrome): Обвинение бывших сотрудников организации в написании неработающего кода.
  • Это придумал я (Invented Here): Тенденция к неприятие новых или менее тривиальных решений внутри организации, зачастую из-за недоверия к персоналу.
  • Преждевременная оптимизация (Premature optimization): Заблаговременное программирования для повышения эффективности, жертвуя хорошим дизайном, гибкостью, а иногда даже реальной эффективностью.
  • Программирование перестановкой (или "случайное программирования), или« программирования по стечению обстоятельств ») (Programming by permutation (or« programming by accident », or« programming by coincidence »)): Попытка найти решение путем последовательной смены кода и проверяя« или оно работает ».
  • Изобретения велосипеда (Reinventing the square Wheel) При не в состоянии принять существующее решение, пытаешься оптимизировать свое, которое работает гораздо хуже.
  • Серебряная пуля (Silver bullet): Предположение, что любимым техническим решением можно решить большую проблему.
  • Tester Driven Development: программные проекты, в которых новые требования указанные в сообщениях об ошибках.

Антипаттерны системного администрирования

  • Адская зависимость (Dependency hell): Зависимость от версий необходимых библиотек и программ. Распространенный в Unix-средах.
  • DLL ад (DLL hell): Неадекватное управление динамическими библиотеками (DLLs). Распространен в Microsoft Windows.

Показать больше

Похожие статьи

Добавить комментарий

Проверьте также
Закрыть
Кнопка «Наверх»
Закрыть
Закрыть