Привет, Вы узнаете о том , что такое анти-паттерн, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое анти-паттерн, антипаттерн , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

анти-паттерн (от англ. anti-pattern; он же ловушка, англ. pitfall) — это то, как поступать не надо, но как все равно все, всегда и повсюду поступают. Сколько ни предупреждают. Потому как дедлайны. Потому как бизнес. Потому как долбоебы.

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

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

• Жесткий код, от англ. hard code — про него еще говорят «прибито гвоздями». Код настолько привязан к конкретной аппаратной конфигурации и/или системному окружению, что оторвать его для переноса в другое место можно только гвоздодером.
• Мягкий код, от англ. soft code — почти то же, что мягкий стул, или, техническим языком, код, конфигурируемый настолько гибко (и запутано), что хочется, чтобы лучше уж это был hard code. Возникает вследствие выноса в файлы конфигурации программной логики, что в разумных количествах, к слову, бывает иногда оправданно.
• Магические числа, от англ. magic numbers — то, на чем нередко строится hard code. Всяческие константы в программе без пояснения их физического (или любого иного) смысла. Как правило, при изменении магического числа или его удалении код магически перестает работать вовсе. Типичные примеры — 17 и 54.
• Магические строки, от англ. magic strings — как магические числа, но только это строки.
• Магическая кнопка, от англ. magic button — весь код написан в обработчике нажатия кнопки. Этим страдают на всех языках с графическим редактором гуя — C#, делфи.
• Гонки, англ. race condition, race hazard — начинаются тогда, когда программист попадает в чудный мир параллельного программирования с его нитями, потоками и семафорами.
• Ненужная сложность, от англ. accidental complexity — делать сложно то, что можно сделать просто. Как правило, программисту хочется побыстрее применить все, что он изучил (и воон ту новую библиотеку для обмена данными по протоколу XXX), а еще заполучить по результатам проекта сразу много новых строчек в резюме. Если это желание побеждает доводы рассудка, то в проекте появляется accidental complexity. Также см. статьи Индусский код и KISS.
• Спагетти (рус. солянка) из кода, от англ. code spaghetti — это тот самый код, который вам однажды дают сопровождать и после пяти минут причесывания вставших дыбом волос просмотра которого вы молча закрываете редактор и открываете броузер на хуехантере.ру в поисках вакансии в более другой фирме, где не практикуют такого жестокого обращения с программистами. Характеризуется тем, что в одном куске кода описывается куча перемешанных до полного непонимания сущностей, которые по-хорошему необходимо разделять. Например, HTML теги в PHP коде вместо выноса всей верстки в шаблоны.
• Катамари — внедрение новых возможностей исключительно в виде внешних костылей и подпорок вместо периодического пересмотра базового функционала. В итоге со временем код превращается в тугой комок какого-то нечта, в чем даже сами разработчики отказываются ковыряться. В итоге получаем следующую порцию костылей и подпорок. Может применяться как в отдельно взятом фрагменте кода, так и глобально во всем проекте.
• Божественный Объект, от англ. God Object — небольшая часть кода, где сконцентрировано все. Буквально все. Возможно, там даже прячется немаленьких размеров галактика. Весь прочий код программы — исключительно декорация вокруг Божественного Объекта.
• Детонатор, от англ. detonator — очень распространен, но редко обнаруживаем. Наглядный пример: использование в вычислениях с датами поля из двух цифр. Бомба заложена, и детонатор рано или поздно сработает
• Не-виноватая-я, англ. absolver — паттерн встречается в коде, написанном бывшими сотрудниками компании. В таком коде заключено столько старых проблем, что теперешние сотрудники могут защитить свои наработки от обвинений, утверждая, что именно чужой код — причина всех возникающих ошибок. Также известен под именем Это-Не-Моя-Правка.
• Исторический вклад, от англ. stake — паттерн имеет место в программе, написанной сотрудником, который впоследствии получил продвижение по службе. Несмотря на изобилие ошибок в программе, вклад этого сотрудника слишком велик, чтобы позволить кому-либо начать переписывать код, поскольку он является апофеозом технических достижений этого товарища.
• Паблик Морозов (сугубо русская идиома, нет английского эквивалента) — класс, который по запросу выдает доступ ко всем, даже приватным, свойствам класса-родителя. Не столько плохо само по себе, сколько означает, что в коде что-то не так.
• Спасти рядового Райана, от англ. Private Ryan — паттерн, в котором доступ к полю получить в принципе можно, но для этого надо снаряжать экспедицию, сопряженную со множеством опасностей.

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

Специально для сисадминов есть два антипаттерн а, в которые они попадают в зависимости от своей специализации.

• Ад зависимостей, от англ. dependency hell — для юниксовых сисадминов. Прямо проистекает из того факта, что строители юниксовых дистрибутивов (в первую очередь линупсов) однажды возгордились и решили возвести Вавилонскую башню упорядочить весь линуксовый софт, так, чтобы одна программа в дистрибутиве не мешала другой. Последствия этой попытки пользователи порой ощущают в виде «циклических зависимостей» и прочих дорожек в dependency hell.
• Ад DLL, от англ. Об этом говорит сайт https://intellect.icu . DLL hell — персонально для сисадминов Windows. Проблема является частным случаем ада зависимостей, применительно к формату библиотек (DLL) в Windows, особенно в старых версиях этой системы.

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

Есть такое искусство — «пасти котов», или, скучно выражаясь, управление программистами. Рисование всяких там диаграммок Ганта и прочей псевдонаучной лабуды, которую потом все дружно игнорируют. Этим занимаются менеджеры. Не секрет, что в менеджеры уходят те, кто в ИТ пришел к своему финишу, постарел и отупел, чтобы писать код и ваять вечное, а может быть, и вовсе кроме ворда и аутлука ничем не пользовался и потому подался сразу в управдомы управлять людьми. Поэтому антипаттерны в этой области просто-таки цветут пышным цветом. Дополнительную дезорганизацию в организацию разработки порой привносят сами разработчики, помогая менеджерам во внедрении анти-паттернов.

• Управление грибами, от англ. mushroom management — метод управления подчиненными по принципу: вы все муравьи, а я муравейник! Английский лозунг грибного менеджера — «we keep them in the dark and feed them a steady diet of manure» (Richard Henderson). Менеджер всячески окучивает грибы убеждает подчиненных в том, что кроме их непосредственных заданий, им не надо ничего знать, а утруждать мозги думами о проекте в целом — исключительно манагерский удел. Для внедрения данного метода следует разбить проект на несобираемые кусочки паззла, чтобы никто не понимал, что из них можно собрать вообще и затем выдавать каждому эти кусочки в достаточных количествах, чтобы грибы перманентно были заняты работой и не отвлекались на раздумья «а на уя вообще мы делаем именно так?». Как правило, грибной менеджмент приводит к полностью провальным финалам, поскольку менеджер сам забывает (либо изначально не понимает), к чему и зачем идет проект. Что любопытно, грибной менеджмент практикуют не только менеджеры, но и отдельные программисты, очутившись на ролях старших в проекте. Как правило, это индикатор неквалифицированных программистов, боящихся раскрывать коллегам те немногие знания, которыми они обладают — чтобы не обнаружилось, насколько эти знания малы. Та же причина справедлива и для менеджеров.
• Чайка-менеджер, от англ. seagull management или corporate seagull — распространенный подкласс менеджеров, действующих в следующей последовательности: прилетел, поорал и улетел, оставив за собой кучки проектного дерьма, которые потом, матерясь, подчищают подчиненные. По поведению напоминают морских ворон чаек, парящих гордо между тучами и морем и прилетающих на берег с целью быстро пожрать и попутно опорожнить кишечники, за что они (менеджеры) и переняли данное наименование. Самый бестолковый для проектной деятельности тип, но начальство их любит, так как корпоративные чайки умеют громко хлопать крыльями заявлять о себе, выдавая копеечную деятельность за великие свершения. Живучи, их сложно поймать на ошибках, так как ошибок они не совершают (поскольку, как известно, для этого нужно хоть что-то делать).
• Разработка комитетом, от англ. design by commitee — аналог пословицы «у семи нянек дитя без глазу» применительно к ИТ. Раздувается в гигантские нежизнеспособные стандарты и спецификации с over 9000 уровней абстракции, которые потом все равно никто не реализует. Примеры — модель OSI[ЩИТО?] и CORBA.
• Аналитики-паралитики, от англ. analysis paralysis — проект застревает на стадии анализа задачи, в бесконечных спорах «как делать лучше». В результате получается вообще никак.
• Рыцарь на белом коне (РНБК), от англ. Knight in shining armor (KISA) — непогрешимая личность, с ЧСВ, равным как минимум квадрату собственной технической квалификации. Появляется на сцене в кризисный момент и начинает чинить все подряд, как правило — чинит успешно, только без сообщений о том, какие изменения он сделал, и почему. Так что при очередном обновлении системы ничего не подозревающим сисадмином старые ошибки возвращаются на свои места, что дает повод РНБК заявлять о тупости и некомпетентности окружающих, что еще более увеличивает его ауру непогрешимости.
• Аврал!, от англ. Tempest Method — применяется не ранее, чем за несколько дней до сдачи проекта. При этом пограммисты начинают в срочном порядке генерировать код без комментариев и содержащий в себе связки бомб с детонаторами.
• Охота на ведьм, от англ. witch hunt — попытки отыскать козла отпущения после успешного внедрения анти-паттернов выше, но поскольку проблем это не решает, результатом будет являться отстрел все новых и новых козлов отпущения. В финале игры должен оставаться только один — Duncan McLeod менеджер на белом коне, с подтверждениями некомпетентности предыдущей команды и уверениями руководства фирмы в том, что новая команда под его руководством достигнет небывалых проектных успехов.

Антихитрожопость

Как говорил рядовой программист Э. Дейкстра: «Компетентный программист полностью осознает строго ограниченные возможности своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью».

Заблуждения по поводу потенциала мозга руководителя или программиста являются перманентным источником антипаттернов.

• Раскрытие потенциала технологии на 110%. Быстрое развитие платформ, средств разработки и их зарастание возможностями туманит мозги рядовому кодеру, который предполагает, что если он не будет писать код с десятью операторами на строку, использовать все возможные варианты генераторов, шаблонов, тегов, тонкие нюансы работы интерпретатора и низкосистемные хаки, то коллеги сочтут его полным junior'ом. Но, как правило, все получается ровно таки наоборот и каждая хитрожопость в коде с лихвой аукается при дальнейшей поддержке продукта, не говоря про то, что бедные разработчики платформ, сред и библиотек кучу фич включают просто для галочки, уделяя им соответствующее внимание. При этом простых и понятных дедушкиных подходов, которые не обязательно означают квадратно-гнездовой подход, обычно с лихвой хватает для решения подавляющего большинства задач.

• Манипулирование сроками. Любому эффективному руководителю рано или поздно приходит в голову мысль, а не стоит ли назвать разработчикам срок в 3,14 раз меньше оценочного, чтобы пошевеливались, хотя, если инвестиции затуманили его мозг, то в 3,14 раза больше, чтобы в этот раз ну точно успеть к дедлайну. Мысль о том, что все будет относительно хорошо, только если план работ соотносится с оценкой объема работ, считается слишком банальной и не достойной настоящего гуру руководства. Как следствие — множество проектов заканчивается феерически.

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

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

Resign Patterns

Проломы проектно-дизориентированного проектирования

Любой, кто знаком с книгой о паттернах, написанной той самой Бандой Четырех, знает, что паттерны, указанные там, представляют собой изящные решения, выработанные годами. К сожалению, извлечь паттерны из имеющегося кода не представляется возможным, потому что авторы этого кода не знали, что они должны были использовать паттерны. Сей труд — собрание паттернов для народа. Паттерны, указанные здесь, представляют собой решения, выдержавшие испытание временем. Желаю вам приятного чтения, но пожалуйста, не вздумайте ими пользоваться!

1. Умерщвляющие паттерны

Ниже представлен список из пяти умерщвляющих паттерна.

1.1. Крайняя Нищета (Abject Poverty)

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

1.2. Ослепитель (Blinder)

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

1.3. Обманчивый Метод (Fallacy Method)

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

1.4. Пробатип (ProtoTry)

Паттерн Пробатип — попытка разработать работающую модель приложения на скорую руку. Естественное желание — переписать Пробатип, учитывая полученные из него уроки, однако сроки поджимают. Пробатип также известен как имеющийся код (legacy code).

1.5. Симплтон (Simpleton)

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

2. Бесструктурные паттерны

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

2.1. Усыновитель (Adopter)

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

2.2. Бригада (Brig)

Бригада — контейнерный класс для кривого ПО. Также известно под названием модуль.

2.3. Компромисс (Compromise)

Паттерн Компромисс используется для создания баланса между сроками разработки и качеством продукта. В результате получается посредственное приложение — и все равно с опозданием.

2.4. Детонатор (Detonator)

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

2.5. Сыр (Fromage)

Паттерн Сыр — полон дыр. Этот паттерн состоит из мелких убогих фокусов, которые в итоге сводят на нет переносимость приложения. Чем старше Сыр, тем лучше «пахнет».

2.6. Мухоловка (Flypaper)

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

2.7. Эпоксидка (ePoxy)

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

3. Паттерны плохого поведения

Ниже представлен список из одиннадцати паттернов плохого поведения.

3.1. Цепочка Возможностей (Chain of Possibilities)

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

3.2. Коммандос (Commando)

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

3.3. Распылитель (Intersperser)

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

3.4. Подстрекатель (Instigator)

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

3.5. Импульс (Momentum)

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

3.6. Лекарь (Medicator)

Лекарь — настоящия пожиратель времени, при этом остальные части системы приходиться буквально откачивать и давать успокоительное.

3.7. Не-Виноватая-Я (Absolver)

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

3.8. Вклад (Stake)

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

3.9. Хвалебная Речь (Eulogy)

Паттерн Хвалебная Речь применяется во всех проектах, которые уже используют остальные 22 паттерна. Также известен как Посмертная Речь.

3.10. Авральный Метод (Tempest Method)

Авральный Метод применяется в последние несколько дней перед сдачей проекта. Данный паттерн характеризуется недостатком комментариев и многократным использованием паттерна Детонатор.

3.11. Гость Из Преисподней (Visitor From Hell)

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

Вау!! 😲 Ты еще не читал? Это зря!

• SOLID
• GRASP
• Принципы и назначение ООП / ООД / ООА
• качество кода , ооп , оод , ооа ,
• антипаттерны , антипаттерн ,

• шаблон проектирования , gof паттерны ,

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