Skip to content
VarvariucA edited this page Sep 30, 2019 · 1 revision

Семинар 4. Антипаттерны

Антипаттерн — это часто встречающиеся ошибки, неэффективный подход к решению задач.

Различают:

  1. Антипаттерны разработки - частые ошибки при кодировании (спагетти-код);
  2. Архитектурные антипаттерны - проблемы структуры системы (раздувание интерфейса);
  3. Организационные антипаттерны - проблемы управления проектом (управление грибами);
  4. Антипаттерны среды - проблемы социальной модели организации, и, как следствие, снижение продуктивности рабочего персонала (город ларьков).

В задании необходимо:

Привести пример каждого из 4 видов антипаттернов с пояснением, почему данный пример является антипаттерном.

В помощь:

Осторожно! Многие анти-паттерны в интернете формулируются ярко, но грубо. Плюс зачастую вообще наблюдается переход на неприемлемую для нас ненормативную лексику

ИДБ-15-12

  1. Антипаттерны разработки- Преждевременная оптимизация (Premature optimization)

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

  1. Архитектурные антипаттерны - Состояние гонки (Race hazard, Race condition)

Непредвидение возможности наступления событий в порядке, отличном от ожидаемого.

  1. Организационные антипаттерны - Единственный знающий человек

Когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде. С его уходом работа останавливается.

  1. Антипаттерны среды - Непоколебимое мужество

Отважные усилия хороших людей, выполняющих свою работу, несмотря на плохое планирование и ужасное принятие решений, .

  1. Антипаттерны разработки- Золотой молоток (Golden hammer)

Антипаттерн проектирования, заключающийся в использовании одного и того же решения везде. Золотой молоток также известен под названиями: закон инструмента (The law of the instrument), молоток Маслоу (Maslow's hammer), «молоточек» ( Gavel).

  1. Архитектурные антипаттерны - Большой комок грязи.

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

  1. Организационные антипаттерны - Аналитический паралич.

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

  1. Антипаттерны среды - Дедовщина (Geek Hazing).

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

  1. Антипаттерны разработки – Слепая вера (Blind faith).
  • Этот анти-паттерн — недостаточная проверка корректности входных данных, исправления ошибки или результатов работы кода. Очень часто программист думает, что его код всегда будет в идеальных условиях, никогда не выдаст ошибки и не получит неверных входных данных или, ещё чего, данных неверного типа.
  1. Архитектурные антипаттерны – Инверсия абстракции (Аbstraction inversion).
  • Инверсия абстракции — ошибка проектирования программного модуля, когда в сложном модуле для пользователя закрыты простые, но нужные функции. В результате пользователю приходится писать простую функциональность, надстраивая её над сложной, иногда с использованием недокументированных возможностей и побочных эффектов, в то время когда она уже написана.
  1. Организационные антипаттерны – Путь камикадзе (Death march).
  • Все участники разработки знают, что проект обречён, кроме главы, вплоть до последнего дня. Также применяется для стиля руководства, когда сотрудники вынуждаются к сверхурочной работе для достижения нереальных сроков.
  1. Антипаттерны среды – Манипулирование сроками.
  • Иногда руководителю рано или поздно приходит в голову мысль о том, что стоит назвать разработчикам срок в несколько раз меньше оценочного, чтобы поторопить, или обратно, в несколько раз больше, для того чтобы якобы точно успеть к дедлайну. Однако проект ждет успех, только если план работ соотносится с оценкой объема работ. Как следствие — множество проектов заканчивается безуспешно.
  1. Антипаттерны разработки – программирование копипастом. Если из копии одной функции после небольших изменений появляется вторая, третья и т.д., то это может привести к проблемам: чтобы перенести функцию в другой проект, придется искать все места, куда был скопирован код; если нужно будет внести изменения в первую функцию, придется изменять и все остальные; если в первой функции был баг, то он окажется и во всех остальных; code review усложняется, т.к. код увеличивается в размере за счет скопированных строчек, а не реальной работы.
  2. Архитектурные антипаттерны – мышиная возня. Создание множества мелких и абстрактных классов для решения одной конкретной задачи более высокого уровня.
  3. Организационные антипаттерны – разработка комитетом. Разработка проекта без централизованного управления, либо при некомпетентном руководстве.
  4. Антипаттерны среды – микроменеджмент. Руководители контролируют каждый шаг работников, не допускают самостоятельности, требуют отчетов после каждого действия. Это приводит к снижению мотивации сотрудников и к накоплению нереализованного потенциала.
  1. Антипаттерны разработки – Золотой молоток. Сильная уверенность в том, что любимое решение универсально применимо. Название происходит от поговорки «когда в руках молоток, все проблемы кажутся гвоздями»
  2. Архитектурные антипаттерны – Большой комок грязи.программа с нераспознаваемой структурой
  3. Организационные антипаттерны –Функции для галочки. Превращение программы в конгломерат плохо реализованных и не связанных между собой функций
  4. Антипаттерны среды – Чрезмерное усложнение. Расходы ресурсов, что делает проект более устойчивым и сложным, чем это необходимо
  1. Антипаттерны разработки- Френд-зона (Friend-zone)

Неуместное использование дружественных классов и дружественных функций в языке C++.

  1. Архитектурные антипаттерны - Бензиновая фабрика.

Необязательная сложность дизайна.

  1. Организационные антипаттерны - Раздутый улучшизм.

Добавление новых улучшений в ущерб суммарному качеству системы.

  1. Антипаттерны среды - Синдром вареной лягушки.

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

  1. Антипаттерны разработки – Паблик Морозов (сугубо русская идиома, нет английского эквивалента) — класс, который по запросу выдаёт доступ ко всем, даже приватным, свойствам класса-родителя. Не столько плохо само по себе, сколько означает, что в коде что-то не так.
  2. Архитектурные антипаттерны – неопределённая точка зрения, от англ. ambiguous viewpoint — представление модели без спецификации её точки рассмотрения.
  3. Организационные антипаттерны – аналитики-паралитики, от англ. analysis paralysis — проект застревает на стадии анализа задачи, в бесконечных спорах «как делать лучше». В результате получается вообще никак.
  4. Антипаттерны среды – раскрытие кадрового потенциала на 110%. В голову среднестатистического эффективного проджект-менеджера никак не укладывается, что программиста, написавшего в день десять строк, вполне можно назвать нормально поработавшим, а сто годных, отлаженных и протестированных строк — поработавшим отменно. Это приводит его к мысли, что в качестве программиста можно посадить секретаршу, так как у нее скорость набора выше, но так как секретарша отказывается, менеджерская логика подсказывает, что пора нагнетать панику, бегать, орать и всячески стимулировать процесс, дабы поиметь отдачу на 110%. В результате проект дохнет под собственным технологическом долгом (неудачные решения, неправильные оценки и тупо баги), не успев толком начаться. Правда, сам менеджер, как правило, двигает кони в первых рядах, а команда разработчиков, поправив резюме, на следующий же день переползает в какие-то другие конторы в надежде на лучшее.
  1. Антипаттерны разработки – Волшебные числа. «Магическими числами» называют плохую практику программирования, когда в исходном тексте встречается числовое значение и не очевидно, что оно означает
  2. Архитектурные антипаттерны – Сохранение или смерть. Сохранение изменений в конфигурации на жесткий диск лишь при завершении приложения, приводящее к тому, что в случае отказа в программе эти данные будут утеряны.
  3. Организационные антипаттерны – Раздутый улучшизм. Добавление новых улучшений в ущерб суммарному качеству системы
  4. Антипаттерны среды – Город ларьков. Каждый отдел вырабатывает свой собственный механизм обмена информацией
  1. Антипаттерны разработки - Мягкое кодирование (Soft code) — параноидальная боязнь жёсткого кодирования. Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной. Этот анти-паттерн является вторым концом палки о жёстком кодировании и поэтому тоже является опасным. Во-первых, при разработке много ресурсов уходит на реализацию возможности настроек абсолютно всего. Во-вторых, развёртывание такой системы повлечет так же дополнительные затраты. Перед началом решения определённой задачи следует определить, что должно быть настариваемым, а что является постоянным для различных систем или может быть настроено автоматически.
  2. Архитектурные антипаттерны - Божественный объект. Этот анти-паттерн, который довольно часто встречается у ООП разработчиков. Такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него. Причинами являются — некомпетентность разработчика, взятие одним разработчиком большой части работы (особенно, когда размер работы «превышает» уровень опыта этого разработчика). Бороться с таким подходом надо — разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками.
  3. Организационные антипаттерны - Единственный знающий человек (Single head of knowledge, SHOK) - когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде, с его уходом работа останавливается;
  4. Антипаттерны среды - Непоколебимое мужество. Несмотря на ужасное планирование и ужасное принятие решений, отважные усилия хороших людей, обычно «на передовой», выполняют свою работу.
  1. Антипаттерны разработки – Два тоннеля: вынесение новой функциональности в отдельное приложение вместо расширения уже имеющегося. Чаще всего применяется, когда по каким-либо причинам (в основном, при нехватке времени либо нежелании менеджмента) внесение изменений в уже имеющийся код требует больших затрат, чем создание нового. При этом у клиента в конечном итоге работают два приложения, запускаясь одновременно либо попеременно друг из друга.
  2. Архитектурные антипаттерны – Магическая кнопка – антипаттерн, появляющийся при недостатке абстракции, когда множество различных действий сваливается в кучу в неподходящем месте, например, в обработчике нажатия на кнопку, вместо того чтобы быть распределёнными по подходящим классам и функциям. Обычно проблема возникает в средах визуальной разработки, когда программист сначала рисует пользовательский интерфейс, а затем пишет бизнес-логику в автоматически созданных методах
  3. Организационные антипаттерны – Драконовские меры: неоправданно жесткий стиль управления.
  4. Антипаттерны среды – Потемкинские деревни: обман с явной целью приукрасить положение для создания видимости благополучия, процветания.
  1. Антипаттерны разработки - Золотой молоток (Golden hammer) — уверенность в полной универсальности любого решения. На практике, это — применение одного решения (чаще всего какого-либо одного паттерна проектирования) для всех возможных и невозможных задач. Проблема в том, что многие программисты «используют» данный анти-паттерн не подозревая о собственной некомпетентности — они считают, что знают паттерн проектирования и успешно его используют — всё хорошо. Причиной среди новичков является лень к изучению чего-то нового — новичок пытается решить все задачи единственным методом, который он освоил. Но к сожалению, это встречается и среди профессионалов — программист очень любит использовать какой-либо паттерн и начинает делать это везде. С этим надо бороться — для каждой задачи имеется не одно, а несколько, красивых и оптимальных решений — именно к поиску таких решений и сводится эффективная разработка. И только такая разработка позволит создать эффективную систему.
  2. Архитектурные антипаттерны - Спагетти-код — слабо структурированная и плохо спроектированная система, запутанная и очень сложная для понимания. Такой код так же очень часто содержит в себе множество примеров анти-паттерна программирования копи-пастом. Подобный код в будущем не сможет разобрать даже его автор. В ООП спагетти-код может быть представлен в виде небольшого количества объектов с огромными, по размеру кода, методами. Причинами являются — разработка по принципу «Да ну, оно же работает! Целых пять тысяч строк!», малоэффективные code review, недостаток опыта в ООП разработке, удалённая работа отдельных программистов. Ипользовать спагетти-код повторно невозможно и нежелательно. Если в вашем проекте начинает возникать спагетти-код, а вам как раз надо расширить функционал, который он реализует — не ленитесь, рефакторьте спагетти полностью или напишите эту часть заново! Проиграв немного времени сейчас — вы получите огромный плюс в будущем. Или наоборот — проиграете, если оставите спагетти-код в проекте.
  3. Организационные антипаттерны - Аналитический паралич. Желание предсказать что-либо, нежелание действовать, когда это было бы просто и эффективно, недостаток ясности мысли… Всё это свойства, заставляющие бесконечно повторять историю. Уинстон Черчилль, Дебаты в парламенте
  4. Антипаттерны среды - Лягу́шка в кипятке́ — научный анекдот, а также реально проводившийся в XIX веке эксперимент, описывающий медленное сваривание в кипятке живой лягушки. Сутью эксперимента является предположение о том, что если лягушку поместят в кипящую воду, она выпрыгнет, но если она будет находиться в холодной воде, которая медленно нагревается, то она не будет воспринимать опасность и будет медленно погибать. История часто используется как метафорическое отображение неспособности людей реагировать на значительные изменения, которые происходят постепенно.

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

  1. Антипаттерн разработки - Лодочный якорь (Boat anchor) Этот анти-паттерн означает сохранение неиспользуемых частей системы, которые остались после оптимизации или рефакторинга. Часто, после рефакторинга когда, который является результатом анти-паттерна, некоторые части кода остаются в системе, хотя они уже больше не используются. Так же некоторые части кода могут быть оставлены «на будущее», авось придётся ещё их использовать. Такой код только усложняет системы, не неся абсолютно никакой практической ценности. Эффективным методом борьбы с лодочными якорями является рефакторинг кода для их устранения, а так же процесс планирования разработки, с целью предотвращения возникновения якорей.
  2. Организационный антипаттерн - Привязка к поставщику (Vendor lock-in) Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход. Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».
  3. Антипаттерн среды - Синдром варёной лягушки (Boiling Frog Syndrome) Лягушка в кипятке — научный анекдот, а также реально проводившийся в XIX веке эксперимент, описывающий медленное сваривание в кипятке живой лягушки. Сутью эксперимента является предположение о том, что если лягушку поместят в кипящую воду, она выпрыгнет, но если она будет находиться в холодной воде, которая медленно нагревается, то она не будет воспринимать опасность и будет медленно погибать. История часто используется как метафорическое отображение неспособности людей реагировать на значительные изменения, которые происходят постепенно.
  4. Антипаттерны среды - Модные слова: особый род новых слов и речевых конструкций, часто используемых в коммерции и профессиональной деятельности для оказания впечатления осведомлённости говорящего и для придания чему-либо образа важности. Из-за неумеренного употребления смысл слова размывается, и «модные слова» можно встретить даже в контексте, не имеющем отношения к исходному значению.
  1. Антипаттерны разработки - –Таинственный код (Cryptic code) – использование аббревиатур вместо понятных имён. В следствии чего можно запутаться в своем же коде;
  2. Архитектурные антипаттерны - Бензиновая фабрика (Gas factory) - необязательная сложность дизайна. Зачем усложнять и без того тяжелый труд?;
  3. Организационные антипаттерны - Тёплое тело (Warm Bodies) - человек, чей вклад в проект под сомнением. Проявляется в отсутствии конкретных действий для достижения целей проекта ;
  4. Антипаттерны среды - Дедовщина (Geek Hazing) - сложившаяся в организации неформальная система иерархических отношений между сотрудниками имеющими большой стаж работы в организации и "новичками", связанная с дискриминацией последних. Проявляется в перекладывании большого объема тяжелой работы или ответственности на новичков .
  1. Антипаттерны разработки - Мягкое кодирование (Soft code):Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование
  2. Архитектурные антипаттерны - Раздувание интерфейса (Interface bloat): разработка интерфейса очень мощным и очень сложным для реализации
  3. Организационные антипаттерны - Ползущий улучшизм (Creeping featurism): добавление новых улучшений в ущерб суммарному качеству системы
  4. Антипаттерны среды -- Потёмкинские деревни. Обман, попытки скрыть за благопристойным фасадом какие-либо неблаговидные явления.
  1. Антипаттерны разработки - Самоуничтожение (Self-destruction): Фатальная ошибка либо нестандартное поведение программы, приводящая к отказу в обслуживании, возникшая вследствие другой менее серьёзной ошибки. Например, при возникновении ошибки, приложение начинает очень быстро и много писать в лог, вследствие чего заканчивается место на жёстком диске быстрее, чем это обнаружит мониторинг.
  2. Архитектурные антипаттерны - Сохранение или смерть (Save or die): Сохранение изменений в конфигурации на жесткий диск лишь при завершении приложения; приводит к тому, что в случае отказа в программе эти данные будут утеряны.
  3. Организационные антипаттерны - Я тебе это говорил (I told you so): Игнорирование мнения эксперта.
  4. Антипаттерны среды - Болезнь основателя (Founderitis): Является популярным термином для трудностей, с которыми сталкиваются организации, где один или несколько основателей поддерживают непропорциональную власть и влияние после эффективного первоначального создания проекта, что приводит к широкому кругу проблем для организации.

ИДБ-15-13

Антипаттерн разработки - Лодочный якорь (Boat anchor)

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

Архитектурный паттерн - Состояние гонки (Race hazard, Race condition)

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

Организационный антипаттерн - Привязка к поставщику (Vendor lock-in)

Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход. Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».

Антипаттерн среды - Синдром варёной лягушки (Boiling Frog Syndrome)

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

  1. Антипаттерны разработки – Золотой молоток (англ. Golden hammer).

Золотой молоток — уверенность в полной универсальности любого решения. На практике, это — применение одного решения (чаще всего какого-либо одного паттерна проектирования) для всех возможных и невозможных задач. Проблема в том, что многие программисты «используют» данный анти-паттерн не подозревая о собственной некомпетентности — они считают, что знают паттерн проектирования и успешно его используют — всё хорошо. Причиной среди новичков является лень к изучению чего-то нового — новичок пытается решить все задачи единственным методом, который он освоил.

  1. Архитектурные антипаттерны – Состояние гонки (англ. Race condition).

Состояние гонки — ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода. Состояние гонки. Race condition. Другое название: гонки данных (data race). Ошибка программирования многозадачной системы, при которой работа системы зависит от того, в каком порядке выполняются части кода. Состояние гонки возникает тогда, когда несколько потоков многопоточного приложения пытаются одновременно получить доступ к данным, причем хотя бы один поток выполняет запись. Состояния гонки могут давать непредсказуемые результаты, и зачастую их сложно выявить. Иногда последствия состояния гонки проявляются только через большой промежуток времени и в совсем другой части приложения.

  1. Организационные антипаттерны – Рыцарь на белом коне (англ. Knight in shining armor).

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

  1. Антипаттерны среды – Раскрытие потенциала технологии на 110%.

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

  1. Антипаттерны разработки- Френд-зона (Friend-zone)

Неуместное использование дружественных классов и дружественных функций в языке C++.

  1. Архитектурные антипаттерны - Бензиновая фабрика.

Необязательная сложность дизайна.

  1. Организационные антипаттерны - Раздутый улучшизм.

Добавление новых улучшений в ущерб суммарному качеству системы.

  1. Антипаттерны среды - Синдром вареной лягушки.

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

  1. Антипаттерны разработки - Мягкое кодирование (Soft code) — параноидальная боязнь жёсткого кодирования. Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной. Этот анти-паттерн является вторым концом палки о жёстком кодировании и поэтому тоже является опасным. Во-первых, при разработке много ресурсов уходит на реализацию возможности настроек абсолютно всего. Во-вторых, развёртывание такой системы повлечет так же дополнительные затраты. Перед началом решения определённой задачи следует определить, что должно быть настариваемым, а что является постоянным для различных систем или может быть настроено автоматически.
  2. Архитектурные антипаттерны - Божественный объект. Этот анти-паттерн, который довольно часто встречается у ООП разработчиков. Такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него. Причинами являются — некомпетентность разработчика, взятие одним разработчиком большой части работы (особенно, когда размер работы «превышает» уровень опыта этого разработчика). Бороться с таким подходом надо — разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками.
  3. Организационные антипаттерны - Единственный знающий человек (Single head of knowledge, SHOK) - когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде, с его уходом работа останавливается;
  4. Антипаттерны среды - Непоколебимое мужество. Несмотря на ужасное планирование и ужасное принятие решений, отважные усилия хороших людей, обычно «на передовой», выполняют свою работу.

• Антипаттерн разработки - Мягкое кодирование (Soft code)

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

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

• Организационный антипаттерн - Управление грибами (Mushroom management): недостаточное информирование работников о выполняемой работе. Например, сотрудников держат в занятом состоянии, не дают возможности участвовать в принятии решений — и даже информируют об этом решении лишь тогда, когда оно принято.

• Антипаттерн среды – Город ларьков. Каждое подразделение, отдел или департамент обменивается информацией собственным способом, таким образом накапливая непонимание между подразделениями.

Машкова Татьяна (семинары расположены по ссылке)

  1. Антипаттерны разработки – Золотой молоток (англ. Golden hammer).

Золотой молоток — уверенность в полной универсальности любого решения. На практике, это — применение одного решения (чаще всего какого-либо одного паттерна проектирования) для всех возможных и невозможных задач. Проблема в том, что многие программисты «используют» данный анти-паттерн не подозревая о собственной некомпетентности — они считают, что знают паттерн проектирования и успешно его используют — всё хорошо. Причиной среди новичков является лень к изучению чего-то нового — новичок пытается решить все задачи единственным методом, который он освоил.

  1. Архитектурные антипаттерны – Состояние гонки (англ. Race condition).

Состояние гонки — ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода. Состояние гонки. Race condition. Другое название: гонки данных (data race). Ошибка программирования многозадачной системы, при которой работа системы зависит от того, в каком порядке выполняются части кода. Состояние гонки возникает тогда, когда несколько потоков многопоточного приложения пытаются одновременно получить доступ к данным, причем хотя бы один поток выполняет запись. Состояния гонки могут давать непредсказуемые результаты, и зачастую их сложно выявить. Иногда последствия состояния гонки проявляются только через большой промежуток времени и в совсем другой части приложения.

  1. Организационные антипаттерны – Рыцарь на белом коне (англ. Knight in shining armor).

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

  1. Антипаттерны среды – Раскрытие потенциала технологии на 110%.

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

  1. Антипаттерны разработки – Золотой молоток (англ. Golden hammer).

Золотой молоток — уверенность в полной универсальности любого решения. На практике, это — применение одного решения (чаще всего какого-либо одного паттерна проектирования) для всех возможных и невозможных задач. Проблема в том, что многие программисты «используют» данный анти-паттерн не подозревая о собственной некомпетентности — они считают, что знают паттерн проектирования и успешно его используют — всё хорошо. Причиной среди новичков является лень к изучению чего-то нового — новичок пытается решить все задачи единственным методом, который он освоил.

  1. Архитектурные антипаттерны – Состояние гонки (англ. Race condition).

Состояние гонки — ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода. Состояние гонки. Race condition. Другое название: гонки данных (data race). Ошибка программирования многозадачной системы, при которой работа системы зависит от того, в каком порядке выполняются части кода. Состояние гонки возникает тогда, когда несколько потоков многопоточного приложения пытаются одновременно получить доступ к данным, причем хотя бы один поток выполняет запись. Состояния гонки могут давать непредсказуемые результаты, и зачастую их сложно выявить. Иногда последствия состояния гонки проявляются только через большой промежуток времени и в совсем другой части приложения.

  1. Организационные антипаттерны – Рыцарь на белом коне (англ. Knight in shining armor).

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

  1. Антипаттерны среды – Раскрытие потенциала технологии на 110%.

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

Антипаттерн разработки - Лодочный якорь (Boat anchor)

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

Архитектурный паттерн - Состояние гонки (Race hazard, Race condition)

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

Организационный антипаттерн - Привязка к поставщику (Vendor lock-in)

Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход. Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».

Антипаттерн среды - Синдром варёной лягушки (Boiling Frog Syndrome)

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

Антипаттерн разработки - Лодочный якорь (Boat anchor)

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

Архитектурный паттерн - Состояние гонки (Race hazard, Race condition)

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

Организационный антипаттерн - Привязка к поставщику (Vendor lock-in)

Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход. Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».

Антипаттерн среды - Синдром варёной лягушки (Boiling Frog Syndrome)

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

ИДБ-15-14

  1. Антипаттерны разработки - Френд-зона (Friend-zone)
    Неуместное использование дружественных классов и дружественных функций в языке C++.

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

  3. Организационные антипаттерны - Привязка к поставщику (Vendor lock-in)
    Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход. Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».

  4. Антипаттерны среды - Синдром варёной лягушки (Boiling Frog Syndrome)
    Лягушка в кипятке — научный анекдот, а также реально проводившийся в XIX веке эксперимент, описывающий медленное сваривание в кипятке живой лягушки. Сутью эксперимента является предположение о том, что если лягушку поместят в кипящую воду, она выпрыгнет, но если она будет находиться в холодной воде, которая медленно нагревается, то она не будет воспринимать опасность и будет медленно погибать. История часто используется как метафорическое отображение неспособности людей реагировать на значительные изменения, которые происходят постепенно.

  1. Антипаттерн разработки - Жесткий код (Hard code) Избыточно сильная привязка программного кода к конкретной программной, аппаратной или системной конфигурации.
  2. Архитектурный антипаттерн - Тупик (Dead End) Модификация повторно используемого программного компонента, поддержка которого уже была прекращена ранее, что влечет за собой необходимость возобновлять его сопровождение.
  3. Организационный антипаттерн - Охота на ведьм (Witch Hunt) Попытка найти проблему неуспеха проекта только в некомпетентности конкретных руководителей либо исполнителей, и решить её исключительно сменой команды разработчиков, либо менеджеров.
  4. Антипаттерн среды - Босые дети (Shoeless children) Суть данного антипаттерна состоит в игнорировании внутренних потребностей компании и распределении всех доступных ресурсов на реализацию текущих внешних проектов.
  1. Антипаттерны разработки - Мягкое кодирование (Soft code):Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование
  2. Архитектурные антипаттерны - Бензиновая фабрика (Gas factory) - необязательная сложность дизайна. Зачем усложнять и без того тяжелый труд?;
  3. Организационные антипаттерны - Ползущий улучшизм (Creeping featurism): добавление новых улучшений в ущерб суммарному качеству системы
  4. Антипаттерны среды – Потемкинские деревни: обман с явной целью приукрасить положение для создания видимости благополучия, процветания.
  1. Антипаттерны разработки - божественный объект, который располагает большое количество функционала в одном классе. Программисту лучше разделять функции по классам, и потом вызывать их, это гораздо лучше.
  2. Архитектурные антипаттерны - Отсутствие реализации ввода правильных данных. В Системе всегда должен быть правильный ввод данных, допустим введёшь отрицательное выражение, где не предусматривается и выйдет ошибка.
  3. Организационные антипаттерны - Сомнение что вклад 1 человека присутствует в проекте. В команде каждый должен вносить свой вклад в результат.
  4. Антипаттерны среды - Хаос в компании, идёт не разбериха, что соответственно снижает kpi компании.
  1. Антипаттерны разработки - Коммит-убийца - это внесение отдельных изменений в систему контроля версий без проверки влияния их на другие части программы. Как правило, после подобных коммитов работа коллектива парализуется на время исправления проблем в местах, которые ранее работали безошибочно. Наиболее часто встречается в игровой индустрии, о которой писал в предыдущих семинарах, когда после фикса багов всплывают сотни других.
  2. Архитектурные антипаттерны - Функции для галочки. Превращение программы в конгломерат плохо реализованных и не связанных между собой функций (как правило, для того, чтобы заявить в рекламе, что функция есть). Как пример опять же можно привести игровую индустрию, когда в играх вводят фарм ради фарма. Получение одной экипировки просто ради того, чтобы потом получить экипировку чуть лучше, без какой либо цели.
  3. Организационные антипаттерны - Драконовские меры. Неоправданно жесткий стиль управления. Примером могут быть требования к разработчикам находиться на рабочем месте в офисе четко по графику, с наказаниями за малейшие опоздания, при том что выполнение работы вообще не требует присутствия человека в офисе.
  4. Антипаттерны среды - Потёмкинские деревни. Несоответствие реальности. Примерами могут служить поездки наших уважаемых президента и премьер-министра по стране.
  1. Антипаттерны разработки. Лазанья-код (Lasagnia code, или «лук» (onion)) - Использование неоправданно большого количества уровней абстракции;
  2. Архитектурные антипаттерны. Сохранение или смерть (Save or die) - Сохранение изменений в конфигурации на жесткий диск лишь при завершении приложения. Приводит к тому, что в случае отказа в программе эти данные будут утеряны;
  3. Организационные антипаттерны. Единственный знающий человек (Single head of knowledge, SHOK) - когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде, с его уходом работа останавливается;
  4. Антипаттерны среды - Синдром варёной лягушки (Boiling Frog Syndrome)

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

  1. Антипаттерны разработки. Полтергейст (Poltergeist) - объекты, передающие данные другим объектам;
  2. Архитектурные антипаттерны. Мышиная возня - создание множества мелких и абстрактных классов для решения одной конкретной задачи более высокого уровня;
  3. Организационные антипаттерны. Тёплое тело (Warm Bodies) - человек, чей вклад в проект под сомнением;
  4. Антипаттерны среды - Город ларьков. Каждый отдел вырабатывает свой собственный механизм обмена информацией.
  1. Антипаттерны разработки. Приватизация (Privatisation): Сокрытие функциональности в приватной секции (private), что затрудняет его расширение в классах-потомках;
  2. Архитектурные антипаттерны. Бензиновая фабрика (Gas factory): Необязательная сложность дизайна;
  3. Организационные антипаттерны. Я тебе это говорил (I told you so): игнорирование мнения эксперта;
  4. Антипаттерны среды - Экономия. Так как заказчик часто желает получить золотой замок за цену железного ведра, то встает вопрос об экономии. И заказчик решает вместо того, чтобы сократить функционал и требования, лучше сократить проектирование, прототипирование, внутренние.
  • Антипаттерн разработки - Лодочный якорь (Boat anchor)

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

  • Архитектурный паттерн - Состояние гонки (Race hazard, Race condition)

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

  • Организационный антипаттерн - Привязка к поставщику (Vendor lock-in)

Привязка к поставщику (англ. vendor lock-in, proprietary lock-in, customer lock-in, «барьер для смены поставщика») — бизнес-модель, в которой устанавливается зависимость потребителя от продуктов и услуг одного поставщика, намеренно создаются осложнения для смены поставщика из‑за высоких затрат на переход. Поставщики заинтересованы намеренно создавать замыкание для завоевания большой доли рынка, что иногда приводит к появлению монополии и «стандартов де-факто».

  • Антипаттерн среды - Синдром варёной лягушки (Boiling Frog Syndrome)

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

  1. Антипаттерны разработки. Мягкое кодирование (Soft code) — параноидальная боязнь жёсткого кодирования. Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной. Этот анти-паттерн является вторым концом палки о жёстком кодировании и поэтому тоже является опасным. Во-первых, при разработке много ресурсов уходит на реализацию возможности настроек абсолютно всего. Во-вторых, развёртывание такой системы повлечет так же дополнительные затраты. Перед началом решения определённой задачи следует определить, что должно быть настариваемым, а что является постоянным для различных систем или может быть настроено автоматически;
  2. Архитектурные антипаттерны. Большой комок грязи. Программная система с нераспознаваемой архитектурой. Хотя это нежелательно с точки зрения программной инженерии, такие системы распространены на практике из-за давления бизнеса, текучке кадров среди разработчиков и энтропии кода. Они представляют собой тип анти-шаблона дизайна.;
  3. Организационные антипаттерны. Тёплое тело (Warm Bodies) - человек, чей вклад в проект под сомнением. Проявляется в отсутствии конкретных действий для достижения целей проекта;
  4. Антипаттерны среды - - Дедовщина (Geek Hazing). Сложившаяся в организации неформальная система иерархических отношений между сотрудниками имеющими большой стаж работы в организации и "новичками", связанная с дискриминацией последних. Проявляется в перекладывании большого объема тяжелой работы или ответственности на новичков .
  1. Антипаттерны разработки - Изобретение одноколёсного велосипеда. Этот анти-паттерн очень тесно связан с простым изобретением велосипеда — это создание своего плохого решения, при существовании лучшего. Этот анти-паттерн вдвойне забирает время — так как, во-первых, время тратится на изобретение и реализацию собственного решения, во-вторых, время тратится при рефакторинге таких решений и замене их оптимальными. Программист должен быть осведомлен о существовании различных решений для определённых кругов задач, ориентироваться в их преимуществах и недостатках.
  2. Архитектурные антипаттерны - Божественный объект. Этот анти-паттерн, который довольно часто встречается у ООП разработчиков. Такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него. Причинами являются — некомпетентность разработчика, взятие одним разработчиком большой части работы (особенно, когда размер работы «превышает» уровень опыта этого разработчика). Бороться с таким подходом надо — разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками.
  3. Организационные антипаттерны - Разработка комитетом. Уничижительная характеристика стиля проектирования и полученного результата, когда группа участников объединяется для создания чего-либо (обычно технического устройства или стандарта) при плохом или некомпетентном руководстве. Отличительными чертами «разработанного комитетом» проекта являются излишняя сложность, неполнота, логические противоречия, банальность и отсутствие целостной структуры.
  4. Антипаттерны среды - Непоколебимое мужество. Несмотря на ужасное планирование и ужасное принятие решений, отважные усилия хороших людей, обычно «на передовой», выполняют свою работу.
  1. Антипаттерны разработки – Магическая кнопка. Антипаттерн, появляющийся при недостатке абстракции, когда множество различных действий сваливается в кучу в неподходящем месте, например в обработчике нажатия на кнопку, вместо того чтобы быть распределёнными по подходящим классам и функциям. Этим страдают на всех языках с графическим редактором – C#, делфи.
  2. Архитектурные антипаттерны – Членовредительство. Излишнее «затачивание» объекта под определенную очень узкую задачу так, что объект не способен будет работать с другими схожими задачами. В следствии чего может появиться очень много объектов с однотипными задачами.
  3. Организационные антипаттерны - Аврал! Применяется не ранее, чем за несколько дней до сдачи проекта. При этом программисты начинают в срочном порядке генерировать код без комментариев и содержащий в себе связки бомб с детонаторами.
  4. Антипаттерны среды - Экономия. Так как заказчик часто желает получить золотой замок за цену железного ведра, то встает вопрос об экономии. И заказчик решает вместо того, чтобы сократить функционал и требования, лучше сократить проектирование, прототипирование, внутренние
  1. Антипаттерн разработки - Активное ожидание (Busy spin, busy waiting)

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

  1. Архитектурный антипаттерн - Эффект внутренней платформы (Inner-platform effect).

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

  1. Организационный антипаттерн - Дойная корова (Cash cow).

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

  1. Антипаттерн среды - Увлечение модными словами (Buzzword Mania).

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

  1. Антипаттерны разработки - Мягкое кодирование (Soft code) — параноидальная боязнь жёсткого кодирования. Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной. Этот анти-паттерн является вторым концом палки о жёстком кодировании и поэтому тоже является опасным. Во-первых, при разработке много ресурсов уходит на реализацию возможности настроек абсолютно всего. Во-вторых, развёртывание такой системы повлечет так же дополнительные затраты. Перед началом решения определённой задачи следует определить, что должно быть настариваемым, а что является постоянным для различных систем или может быть настроено автоматически.
  2. Архитектурные антипаттерны - Божественный объект. Этот анти-паттерн, который довольно часто встречается у ООП разработчиков. Такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него. Причинами являются — некомпетентность разработчика, взятие одним разработчиком большой части работы (особенно, когда размер работы «превышает» уровень опыта этого разработчика). Бороться с таким подходом надо — разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками.
  3. Организационные антипаттерны - Единственный знающий человек (Single head of knowledge, SHOK) - когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде, с его уходом работа останавливается;
  4. Антипаттерны среды - Непоколебимое мужество. Несмотря на ужасное планирование и ужасное принятие решений, отважные усилия хороших людей, обычно «на передовой», выполняют свою работу.
  1. Антипаттерны разработки – программирование копипастом. Если из копии одной функции после небольших изменений появляется вторая, третья и т.д., то это может привести к проблемам: чтобы перенести функцию в другой проект, придется искать все места, куда был скопирован код; если нужно будет внести изменения в первую функцию, придется изменять и все остальные; если в первой функции был баг, то он окажется и во всех остальных; code review усложняется, т.к. код увеличивается в размере за счет скопированных строчек, а не реальной работы.
  2. Архитектурные антипаттерны – мышиная возня. Создание множества мелких и абстрактных классов для решения одной конкретной задачи более высокого уровня.
  3. Организационные антипаттерны – разработка комитетом. Разработка проекта без централизованного управления, либо при некомпетентном руководстве.
  4. Антипаттерны среды – микроменеджмент. Руководители контролируют каждый шаг работников, не допускают самостоятельности, требуют отчетов после каждого действия. Это приводит к снижению мотивации сотрудников и к накоплению нереализованного потенциала.
  1. Антипаттерны разработки- Божественный объект (God object)

Концентрация слишком большого количества функций в одной части системы (классе).

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

  1. Архитектурные антипаттерны - Состояние гонки (Race condition).

Ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода.

Пример: есть код, в котором пять потоков параллельно инкрементируют переменную x.
for (int i = 0; i < 10000000; i++) x = x + 1;

Изменение переменной x происходит в три этапа:

  • чтение текущего значения
  • добавление 1 к этому значению
  • запись нового значения в x

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

  1. Организационные антипаттерны - Привязка к поставщику (Vendor lock-in).

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

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

  1. Антипаттерны среды - Дедовщина (Geek Hazing).

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

  1. Антипаттерны разработки - –Таинственный код (Cryptic code) – использование аббревиатур вместо понятных имён. В следствии чего можно запутаться в своем же коде;
  2. Архитектурные антипаттерны - Бензиновая фабрика (Gas factory) - необязательная сложность дизайна. Зачем усложнять и без того тяжелый труд?;
  3. Организационные антипаттерны - Тёплое тело (Warm Bodies) - человек, чей вклад в проект под сомнением. Проявляется в отсутствии конкретных действий для достижения целей проекта ;
  4. Антипаттерны среды - Дедовщина (Geek Hazing) - сложившаяся в организации неформальная система иерархических отношений между сотрудниками имеющими большой стаж работы в организации и "новичками", связанная с дискриминацией последних. Проявляется в перекладывании большого объема тяжелой работы или ответственности на новичков .
  1. Антипаттерны разработки - Спагетти-код: плохо спроектированная, слабо структурированная, запутанная и трудная для понимания программа, особенно содержащая много операторов GOTO (особенно переходов назад), исключений и других конструкций, ухудшающих структурированность.
  2. Архитектурные антипаттерны - Сохранение или смерть: сохранение изменений в конфигурации на жесткий диск лишь при завершении приложения; приводит к тому, что в случае отказа в программе эти данные будут утеряны.
  3. Организационные антипаттерны - Я тебе это говорил: игнорирование мнения эксперта.
  4. Антипаттерны среды - Модные слова: особый род новых слов и речевых конструкций, часто используемых в коммерции и профессиональной деятельности для оказания впечатления осведомлённости говорящего и для придания чему-либо образа важности. Из-за неумеренного употребления смысл слова размывается, и «модные слова» можно встретить даже в контексте, не имеющем отношения к исходному значению.
  1. Антипаттерны разработки - Золотой молоток (Golden hammer)

Антипаттерн проектирования, заключающийся в использовании одного и того же решения везде. Золотой молоток также известен под названиями: закон инструмента (The law of the instrument), молоток Маслоу (Maslow's hammer), «молоточек» ( Gavel).

  1. Архитектурные антипаттерны - Божественный объект.

Этот анти-паттерн, который довольно часто встречается у ООП разработчиков. Такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него. Причинами являются — некомпетентность разработчика, взятие одним разработчиком большой части работы (особенно, когда размер работы «превышает» уровень опыта этого разработчика). Бороться с таким подходом надо — разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками.

  1. Организационные антипаттерны - Рыцарь на белом коне (англ. Knight in shining armor).

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

  1. Антипаттерны среды - Синдром вареной лягушки.

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

Clone this wiki locally