Что такое антипаттерны? Часть 1

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

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

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

Разработчик, не знающий о шаблонах проектирования.

Термин происходит из информатики, из книги «Банды четырёх» «Шаблоны проектирования», которая заложила примеры практики хорошего программирования. Авторы назвали эти хорошие методы «паттернами», и противоположными им являются «антипаттерны».

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

Антипаттерны классифицируются также, как и паттерны, но разберем мы самые базовые и главные, которые приводит Уильям Браун:

1. Антипаттерны разработки:
   1.1 Антипаттерны в ООП;
   1.2 Антипаттерны в кодировании;
   1.3 Методологические антипаттерны.
2. Архитектурные антипаттерны;
3. Организационные антипаттерны

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

Антипаттерны разработки. ООП:

• Базовый класс-утилита: наследование функциональности из класса-утилиты вместо делегирования к нему;
• Вызов предка: класс-потомок обязательно вызывает методы класса-предка;
• Ошибка пустого подкласса;
• Божественный объект: одна сущность выполняет тотальную часть функционала продукта в целом;
• Полтергейст: реализация сущностей, которые ничего не делают, кроме хранения данных для других сущностей.
• Синглтонизм: неправильное использование/злоупотребление паттерна одиночка (Singleton);
• Интерфейсный суп: объединение нескольких интерфейсов, разделенных принципу изоляции, в один;
• Заглушка;

Такой код писать кстати не надо, используйте switch, пожалуйста

Антипаттерны разработки. Кодирование:

• Ненужная сложность;
• Действие на расстоянии: взаимодействие между сильно разделенными частями системы;
• Слепая вера: недостаточная проверка корректности исправления ошибки или результата подпрограмм;
• Лодочный якорь: сохранение более неиспользуемой части системы;
• Кэширование ошибки;
• Проверка типа вместо интерфейса;
• Инерция кода: ограничение сущности из-за подразумевания ее поведения в других частях системы;
• Таинственный код: использование аббревиатур или ненужных сокращений;
• Поток лавы: сохранение нежелательного, устаревшего, плохо кода (легаси-код) по причине дороговизны и непредсказуемости последствий;
• Магические числа: использование числовых констант без их комментирования и/или смысла;
• Спагетти-код: код с запутанным порядком выполнения программы;
• Лазанья-код: чрезмерное связывание между собой уровней абстракции, приводящее к невозможности изменения одной части программы без изменения другой;
• Равиоли-код: объектны настолько склеены между собой, что их рефакторинг практически или полностью недопустим.

Антипаттерны разработки. Методология:

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

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

Архитектурные антипаттерны

• Инверсия абстракции: сокрытие части функциональности от внешнего использования, в надежде на то, что никто не будет её использовать;
• Большой комок грязи: система с нераспознаваемой структурой;
• Блоб ( == Божественный объект);
• Бензиновая фабрика: излишнее усложнение дизайна программы;
• Раздувание интерфейса;
• Перестыковка: излишняя реализация ненужных зависимостей между различными частями системы;
• Состояние гонки: непредвиденная ситуация, когда обработка событий или частей кода срабатывают не в ожидаемом порядке;
• Сохранение или смерть: сохранение конфигураций на жесткий диск (или иной носитель) только при выходе из приложения/окончания работы приводит к тому, что при ошибке данные будут утеряны.

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

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

• Аналитический паралич: неоправданно большие затраты на анализ и проектирование. Часто приводит к закрытию проекта до начала его реализации;
• Дойная корова: при наличии продукта, приносящего выгоду без существенных вложений, не вкладываются средства в развитие и разработку новых продуктов;
• Раздутый улучшизм;
• Раздутый элегантизм;
• Разработка комитетом: разработка проекта без централизованного управления или без компетентного руководства;
• Неуемная преданность: продолжение реализации решения после того, как доказана его ошибочность;
• Я тебе это говорил: игнорирование мнения эксперта;
• Драконовские меры: неоправданно жесткий стиль управления;
• Управление грибами: недостаточное информирование работников о выполняемой работе;
• Расползание рамок;
• Теплое тело: человек, чей вклад в проект под сомнением;
• Единственный знающий человек;
• Рыцарь на белом коне: когда на сцене появляется человек, который пытается починить всё, не сообщая никому, что он сделал и почему;
• Дикий менеджер;
• Бесплодные прыжки: вы готовите для менеджеров всё новые и новые данные, нужные им для принятия решения, но менеджеры так и не принимают никакого решения, продолжая запрашивать у вас данные. Вы не знаете, зачем им нужны эти данные;
• Дорога в никуда: отсутствие плана вызывает замешательство и кризис руководства;

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

Итоги

Прочитав и, желательно, взяв на заметку, вышеупомянутые антипаттерны или же иначе - плохие методы/подходы к реализации приложения, можно сделать вывод: ТАК ДЕЛАТЬ НЕЛЬЗЯ! Допуская эти приемы, вы или ваши коллеги потенциально ставите крест на развитии продукта, а также его поддержки в будущем. Понятное дело, что абсолютно все игнорировать - тяжело, но нужно к этому стремиться. Всегда должен быть баланс между качеством и скоростью. Искренне верю, что вы учтете все ошибки, возможно обнаружили их в текущем проекте, и никогда не будете их допускать, сведете к минимуму или полностью исключите. Желаю удачи вашим продуктам в продвижении.

Мой телеграм:https://t.me/nikita_kirakosyan_it . Там бывает эксклюзив.