Поющие трусы

Просто смешно =)

Различия между лицензиями на бесплатное ПО

К лицензиям подобного типа относятся GNU General Public License (GNU GPL), Berkeley software license (BSD), лицензия Apache, а теперь еще Netscape Public License и Mozilla Public License.

GPL - пожалуй, наиболее распространенная из лицензий, до появления Netscape Public License была еще и наиболее юридически проработанной. Она описывает все этапы использования текстов, начиная от распространения и заканчивая защитой от нарушения условий патентов. Самый важный пункт лицензии - наследование GPL любым программным обеспечением, в котором использован оригинал (недаром GPL означает Copyleft). Проще говоря, соглашение Copyleft требует, чтобы любое программное обеспечение, которое использует любую часть оригинального файла с грифом GPL, само должно полностью соответствовать GPL. Кроме того, каждый волен получить весь
исходный текст этого программного обеспечения либо бесплатно, либо оплатив стоимость доставки.

В отличие от GPL, лицензия Apache License имеет самые скромные ограничения. Единственное требование - любой исполняемый, исходный или производный продукт должен быть одобрен членами Apache Group, а производный текст автоматически будет "наследовать" лицензию Apache License. Эта лицензия также запрещает применять название Apache в рекламных целях или для маркировки других продуктов без письменного разрешения компании.

Лицензия Berkeley (BSD) существует дольше других указанных в этом списке. Как и лицензия Apache, она требует одобрения производных продуктов в Калифорнийском университете Беркли и должна быть включена в любой производный текст или исполняемый модуль. Из-за большого числа владельцев исходных текстов, включенных в состав Unix, эта лицензия недостаточно юридически выверена, в силу чего не может быть отнесена к классу Copyleft.

Лицензия Netscape Public License (NPL) весьма напоминает GPL. Все исходные тексты, распространяемые под грифом NPL, могут свободно использоваться в других программных проектах. В этом случае разработчикам нужно учитывать, что им придется распространять исходные тексты всех модулей, созданных Netscape, а также любого нового кода, который изменяет или использует код Netscape. Если программа предназначена для "внутреннего" применения, исходные тексты должны быть предоставлены специалистам той компании, где с ней работают.

Но наиболее интересный раздел NPL - это условие, которое позволяет Netscape использовать любые дополнения к открытому для широкой публики тексту в других своих продуктах (семействе серверов, к примеру) без компенсации или разрешения автора изменений и вне зависимости от того, подпадает ли этот код под действие лицензий с другими условиями, нежели NPL. На самом деле это условие позволяет Netscape использовать в своих коммерческих продуктах достижения всех специалистов, работающих с бесплатным программным обеспечением, в обмен на средства, вложенные компанией в разработку своего браузера Navigator. Прежде чем включить это условие в свою лицензию, Netscape провела консультации с пользователями, организовав на своем Web-узле дискуссию. Кроме того, Netscape внесла в свою лицензию поправки, предусматривающие применение другого варианта лицензии на бесплатное ПО,
Mozilla Public License.

Лицензия MPL практически аналогична NPL, за тем исключением, что Netscape не получает никаких особых прав на частное использование кода, написанного по условиям MPL. Netscape пытается очень четко сформулировать условия применения каждой лицензии. Во-первых, все исходные тексты Navigator попадают под действие лицензии NPL, предусматривающей, что любые изменения, сделанные в исходном тексте, могут быть включены в состав серверных продуктов Netscape и при этом компания не обязана указывать источник этих изменений. Однако на все новые файлы с исходным текстом, добавленные в проект Navigator и не содержащие оригинальный код Netscape, могут
распространяться условия лицензии MPL. Таким образом, для использования этих изменений Netscape обязуется, в соответствии с условиями MPL, бесплатно распространять также и те продукты, в которые эти изменения включены, что невозможно из-за существующих лицензионных соглашений с другими компаниями.

Customers rock!

Зачем нужен enum из двух объектов, если есть булевский тип?

На своем проекте заметил странное явление, в коде встречалось несколько перечислений примерно такого вида:

enum MyEnum
{
Value1,
NotValue1
}

Я думаю идея понятна. Есть два взаимоисключающих значения. Для этих значений заводится перечисление. Возникает закономерный вопрос: "Зачем?". Кроме лишнего кода этот шедевр больше ничего не привносит в проект. Каждый раз, когда нужно проверить какое-то условие, приходится код примерно такого вида:

if (myValue == MyEnum.Value1)

И так постоянно. Налицо дублирование кода, хоть и в мелких маштабах. От того, что это дублирование мелкое, легче не становится.

Мое мнение, что данное перечисление лучше (и логичнее) было бы заменить на булевое значение. Например сделать что-то наподибие такого:

bool IsValue1

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

Кто будет пойман с поличным (при написании очередного такого перечисления) или случайно (проблем посмотреть, кто этот файл создал в системе контроля версий нет) будет выставлен на публичное осмеяние =))

Привязка к производителю

В экономике, привязка к производителю, также известная как имущественная привязка, делает клиента зависимым от поставщика на продуктов и услуг, не давая возможности использовать другой поставщика без существенных издержек переключения. Расходы на привязку, которые создают барьеры для выхода на рынок может привести к недоверию против монополии.

Грибное управление

Грибной управление является аллюзией к компании, где с сотрудниками обращаются, как грибам: держут в темне, удобряют, а когда выросли достаточно большим консервируют. В смысл заключается в том, что руководство принимает решение без консультации с персоналом, которые будут подвежены этим решеням - и, возможно, даже не информируя сотрудников еще долго после того, как решение принято.

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

Моральный риск

Моральный риск вытекает из того, что одна из сторон, огражденая от рисков, может вести себя иначе, по сравнению с тем, как бы она себя вела, если бы в полной мере была подвержена этому риску. В страховании, моральный урон, который происходит без сознательных или вредоносные действий, называется моральным ущербом.

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

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

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

Прячьте приведение типов внутрь метода!

В коде была найдена довольно неприятная проблема. Вот пример проблемного кода

GetSelectedObject() as Order

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

Order GetSelectedOrder()
{
return (Order)GetSelectedObject();
}

Метод получение выделенного ордера использовать повсеместно. Если тип объекта поменяется сразу возникает исключение и исправлять придется в одном месте.

Примечания:

Оператор AS является довольно опасным. Т.к. может прятать настоящие ошибки и порождать совсем другие. Чаще всего NullReferenceException в других местах приложения, где их быть не должно. Я уже вижу возражения, что он быстрее чем оператор приведения типа (Cast). Так вот, хочу вас расстроить, последние версии .NET Framework хорошо улучшили скорость работы оператора приведения типов. Особого выигрыша от использования операбота AS вы не почувствуете.

Дальнейшим развитием идееи может служить добавление строго типизированного метода добавление элементров в коллекцию:

AddOrder(Order order)
{
AddObject(order)
}

При таком подходе будет трудно добавить объект неправильного типа в коллекцию.

Бог-громовержец

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

Название происходит от известного финского ругательства perkele (бог-громовержец), и это ссылка на неоднократные повторения этого слова со стороны топ-менеджеров.

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

В этом смысле "управление громовержцем" подразумевает неизбирательное применение армейских методов в гражданской жизни - экспорт практик, которые следовало бы использовать для одной конкретной сфере, в другую, где они могут иметь неоднозначные результаты. Финские вооруженные силы имеют прусские традиции дисциплины: когда ожидается подчинение без каких либо вопросов.

К сожалению, традиции прусский дедовщины, - которые были устранены в последнее время в армии - продолжают сущестовать. Старая "армейская философия" основана на вселении страха и неуверенности в подчиненных. Она также может рассматриваться как организационная издевательств на рабочем месте. В экспертных организация, в которых присутсвует запугивание могут прекратиться положительных результаты, потому как сотрудники будут слишком запуганы чтобы высказывать альтернативные идеи. Это также отстранению исключению индивидуумов от командной работы, так как страх перед коллегами приводит к общению только с теми, кому можно доверять.

По сравнению с другими странами или групп населения, как Финляндия и Швеция являются крайне индивидуалистической культурами, так что это не следует рассматривать как заявление о том, что Финляндия имеет культуру "послушания"

Эскалация обязательств

Эскалация обязательств впервые была описана Барри М. Стов в своем документе, 1976, "По колено в большой мути: Исследование эскалации обязательств в соответствии выбранным планом действий". В последнее время термин невозвратные расходы ошибочно был использован для описания этого явления, когда люди оправдывают увеличение инвестици в решение, основываясь на величину прежних совокупных инвестиции, несмотря на новые доказательства того, что это решение было, вероятно, неправильно. Такие инвестиции могут включать в себя деньги, время, или - в случае военной стратегии - человеческие жизни.

Этот термин используется также для описания плохих решений в бизнесе, государственных, информационных системах в целом, программном обеспечении управления проектами, в частности, политике, а также азартных игра. Этот термин используется для описания участия Соединенных Штатов в военных конфликтах, в том числе Вьетнаме в 1960-х - 1970-х годах и в Ираке в 2000, когда США тратили деньги и жизни для оправдания продолжение участия.

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

Коллективное проектирование

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

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

Этот термин также в автомобильном жаргоне для плохо сконструированных или непопулярных автомобилей.

Дойная корова

В бизнесе дойной коровой называют продукт или бизнес-единицу, которые приносят необычайно высокие прибыли: настолько высокие, что порождают большую часть прибыли компании. Эта прибыль намного превышает расходы, необходимые для поддержания бизнеса, связанный с дойной коровой, а избыточные средства используются для других целей.

Предприятие выступает в качестве дойной коровы, когда его прибыль в расчете на одну акцию (EPS) равна ее дивидендам на одну акцию (DPS), или, другими словами, если фирма выплачивает 100% своего свободного денежного потока (FCF) ее акционерами в виде дивидендов по состоянию на конец каждого отчетного периода. Это также предполагает, что фирма не инвестирует в совершенствование продукта, и по существу рассматривает себя вне роста рынка.

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

При этом, каждое предприятие стремится обогатиться за счёт дойной коровы. Матрица BCG growth-share matrix разработанная Boston Consulting Group, всё ещё используется аналитиками в больших компаниях, и термин дойная корова используется, чтобы описать бизнес-подразделения занимающие значительные доли медленно растущего рынка.

Термин дойная корова также выражает сарказм в области продаж, который используют деловые люди для описания заказчика или организации, которая не имеет контроля над своими расходами. Довольно часто используется для описания правительственные ведомств, таких как: оборона; гуманитарная помощь; социальное обеспечение, где расходы выделяются вне зависимости произведенных услуг или товаров. Иными словами, налогоплательщика обманывают, поскольку правительство не выполняют свою работу должным образом. Это является проблемой не только в США. Страны Европейского союза имеет те же недостатки.

Паралич от анализа

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

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

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

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

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

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

• Программирование посредством копирования/вставки (Copy and paste programming). Копирование (и модифицирование) существующего когда вместо создания обощенных алгоритмов
• Золотой молот (Golden hammer). Предположение о том, что любимое решение является универсальным и применимым в любой ситуации
• Фактор неправдоподобности (Improbability factor). Предлоложение о том, что вероятность возникновения известной ошибки мала.
• Преждевременная оптимизация (Premature optimization). Написание программного кода изначального оптимизированного, жертвуя хорошей архитектурой, сопровождаемостью и иногда реальной производительностью.
• Программирование перестановками (Programming by permutation) (или «случайное программирование»). Попытка написать код изменяя его до тех пор пока он заработает.
• Изобретание колеса (Reinventing the wheel). Неспособность применить существующее адектватное решение
• Серебяная пуля (Silver Bullet). Предположение о том, что любимое техническое решение может быть использовано для более крупного процесса или проблемы
• Разработка направляемая тестировщиком (Tester Driven Development). Программные продукты, в которых новые требование указываются в отчетах об ошибках
  

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

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

Объектно-ориентированные анти-паттерны

• Тощая объектная модель (Anemic domain model). Использование доменной модели, которой нет бизнес логики, что не является объектно-ориетированным программированием, т.к. объект должен содержать и аттрибуты и поведеление
• Главное зерно (Base bean). Наследование функциональности от утилитного класса вместо делигирования этой функциональности этому классу (утилитному).
• Вызов базового метода (Call super). Необходимость вызова переопределенного метода родительского класса дочерними классами.
• Круговая-элипсная проблема (Circle-ellipse problem). Создание ссылочных подтипов на основе подтипов значений.
• Круговая зависимость (Circular dependency). Введение ненужных непосредственных и опосредованных взаимных зависимостей между объектами или программными модулями
• Константные интерфейсы (Constant Interface). Использование интерфейсов для опреления констант
• Божетсвенный объект (God object). Сосредоточение слишком многих функций в одной части системы (класса)
• Выгребная яма (Cesspool object). Повторное использование объектов, которые не подразумевают повторное использование
• Оргия объектов (Object orgy). Недостаточное сокрытие внутреннего устройста объекта и предоставление неограниченного доступа к его внутреннему состоянию.
• Полтергейств (Poltergeists). Объекты, единственным назначением которых является передача информации другому объекту.
• Последовательное сцепление (Sequential Coupling). Класс требует, чтобы его методы были вызваны в определенном порядке
• Yo-yo проблема (Yo-yo problem). Структура, которую сложно понять, в силу чрезмерной фрагментации.
  

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

• Инвертирование абстракции (Abstraction inversion). Непредоставление требуемых пользователю функций, что приводит к реализации их путем использования более высокоуровневых функций
• Неоднозначная точка зрения (Ambiguous viewpoint). Предоставление объектной модели без указания точки зрения на нее.
• Большой ком грязи (Big ball of mud). Система без четко выраженной структуры
• Газовый завод (Gas factory). Необоснованно сложная структура
• Выращивание золота (Gold Planting). Продолжение работы над задачей или проектом после отметки, после которой дополнительные затраты вносят дополнительную стоимость и при этом не создают дополнительной ценности
  
• Эффект внутренней платформы (Inner platform effect). Система является настолько гибкой и настраеваемой, чтоб выглядит жалким подобием платформы разработки.
• Игорирование входныз данных (Input kludge). Невозможность указать и реализовать обработку возможно некоректных входных данных.
• Раздутый интерфейс (Interface bloat). Создание настолько мощного интерфейса, что его сложно реализовать.
• Волшебная кнока (Magic push button). Реализация бизнес логики непосредственно в коде пользовательского интерфейса, отсутствие абстракции.
• Опасность гонки (Race hazard). Отсутствие возможности увидеть последствие запросов и событий.
• Дымоходная система (Stove pipe system). Трудно обслуживаемая система взаимосвязанных компоненитов.
  

Анти-паттерны анализа

• Апатия наблюдателя (Bystander apathy). Когда требование или дизайнерское решение неверно, но люди которые замечают это ничего не делают, посколько это затрагивает большое число людей.
  

Анти-паттерны управления

• Смертельный марш (Death March). Каждый знает, что проект является катастрофой за исключением генерального директора. Тем не менее, истина остается скрытой и жизнеспособность проекта искусственно поддерживается до часа Ч (“большого взрыва”). Существует альтернативное определение. На работников оказывается давление с целью работы до позднего вечера и в течение выходных над проектом с нереальными сроками
• Групповое мышление (Group think). В ходе группового обсуждения члены группы избегают высказывать точки зрения вне общепринятой комофртной зоны консенсуса.
• Дым и зеркала (Smoke and Mirrors). Демонстрация того, как будут выглядеть нереализованные функции
• Раздувание программного обеспечения (Software bloat). Разрешение последующим версиям системы требовать все больше и больше ресурсов
  

Организационные анти-паттерны

• Паралич от анализа (Analysis paralysis). Выделение непропорцио больших затрат на стадию анализа проекта
• Дойная корова (Cash Cow). Выгодный старый продукт, по которому часто оценивают компетентность при разработке новых продуктов.
• Коллективное проектирование (Design Committee). Дизайн, являющийся результатом работы большого числа людей, но обладающиий единой концепцией.
• Экскалация обязательств (Escalation of commitment). Отсутствие возможности отменить решение, если доказана его ошибочность.
• Управление богом-громовержцем (Management by perkele). Авторитарный стиль управления без какой-либо терпимости к инакомыслию.
• Моральный риск (Moral hazard). Изоляция человека, ответственного за решения, от последствий его решения.
• Грибное управление (Mushroom management). Поддержание сотрудников неинформированными или дезыинформированными.
• Дымоход (Stove pipe). Структура, которая поддерживает в основном нисходящий поток данных, но препятствует межорганизационному общению.
• Привязка к производителю (Vendor lock-in). Создание системы чрезмерно зависящей от компонентов поставляемых третьей стороной

Введение в анти-паттерны

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

Термин был придуман в 1995 году Андю Кенигом (Andrew Koenig) вдохновленным книгой Банды Четырех (Gang of Four) Паттерны разработки. Авторы книги разработали концепцию шаблонов проектирования в области разработки программного обеспечения. Этот термин (антипаттерны) получил широкое распространение тремя годами позже вместе с книгой Анти-Паттерны (AntiPatterns), которая вывела использование термина за рамки разработки программного обеспечения. По менению авторов книги, должны присутствовать, по крайней мере, два ключевых элемента для формального отличия анти-паттерна от плохой превычки, плохой практики или плохой идеи:

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

Часто уничижительно называмые oxymoronic neologisms, многие среди антипаттернов являются больше чем просто ошибками, разглагольствованиями, нерешаемыми проблемами или плохими практиками. Если это возможно, лучше стараться их избегать. Антипаттерны иногда называются ловушками (pitfalls) или темными шаблонами (dark patterns). Это неформальное использование термина описывает часто изобретаемые повторно плохие решение проблем.