Что такое антипаттерн

Что такое Антипаттерн в программировании

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

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

Существует четыре типа антипаттернов:

( Development antipatterns ).
( Architectural antipatterns ).
( Managerial antipatterns ).
( Environmental antipatterns ).

Смотрите также

техника разработки TDD ,
которая применяется для гибкого управления проектами
набор концепций Парадигма программирования,
который определяет подход к программированию
техника planning-poker ,
которая предназначена для оценки объема и сложности задач

Антипаттерн

Анти-паттерны (anti-patterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются, как категория, в случае когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем.

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

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

Некоторые различаемые анти-паттерны в программировании

См. Категория:Анти-паттерны для более подробного списка.

Анти-паттерны в управлении разработкой ПО

Дым и зеркала (Smoke and mirrors): Демонстрация того, как будут выглядеть ненаписанные функции (название происходит от двух излюбленных способов, которыми фокусники скрывают свои секреты)
Раздувание ПО (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов
Функции для галочки: Превращение программы в конгломерат плохо реализованных и не связанных между собой функций (как правило, для того, чтобы заявить в рекламе, что функция есть)

Анти-паттерны в разработке ПО

Инверсия абстракции (Abstraction inversion): Сокрытие части функциональности от внешнего использования, в надежде на то, что никто не будет его использовать
Неопределённая точка зрения (Ambiguous viewpoint): Представление модели без спецификации её точки рассмотрения
Большой комок грязи (Big ball of mud): Система с нераспознаваемой структурой
Блоб (Blob): см. Божественный объект (God object)
Бензиновая фабрика (Gas factory): Необязательная сложность дизайна
Затычка на ввод данных (Input kludge): Забывчивость в спецификации и выполнении поддержки возможного неверного ввода
Раздувание интерфейса (Interface bloat): Изготовление интерфейса очень мощным и очень трудным для осуществления
Волшебная кнопка (Magic pushbutton): Выполнение результатов действий пользователя в виде неподходящего (недостаточно абстрактного) интерфейса. Например, в системах типа Delphi это написание прикладной логики в обработчиках нажатий на кнопку
Перестыковка (компьютер) (Re-Coupling): Процесс внедрения ненужной зависимости
Дымоход (Stovepipe system): Редко поддерживаемая сборка плохо связанных компонентов
Гонки (Race hazard, Race condition): непредвидение возможности наступления событий в порядке, отличном от ожидаемого
Мышиная возня: Неоправданное создание множества мелких и абстракных классов для решения одной конкретной задачи более высокого уровня
Висящие концы: Интерфейс, большинство методов которого бессмысленны и реализуются «пустышками»
Золушкина туфелька: Попытка «натянуть» на объект уже имеющийся малоподходящий по смыслу интерфейс, вместо создания нового.
Членовредительство (Mutilation): Излишнее «затачивание» объекта под определенную очень узкую задачу таким образом, что он не способен будет работать с никакими иными, пусть и очень схожими задачами.

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

Базовый класс-утилита (BaseBean): Наследование функциональности из класса-утилиты вместо делегирования к нему
Вызов предка (CallSuper): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка
Ошибка пустого подкласса (Empty subclass failure): Создание класса (в Perl), который не проходит «проверку пустоты подкласса» («Empty Subclass Test») из-за различного поведения по сравнению с классом, который наследуется от него без изменений
Божественный объект (God object): Концентрация слишком большого количества функций в одной части системы (классе)
Объектная клоака (Object cesspool): Переиспользование объектов, находящихся в непригодном для переиспользования состоянии
Полтергейст (Poltergeist): Объекты, чьё единственное предназначение — передавать информацию другим объектам
Проблема йо-йо (Yo-yo problem): Чрезмерная размытость сильно связанного кода (например, выполняемого по порядку) по иерархии классов
Одиночество (Singletonitis): Неуместное использование паттерна одиночка
Приватизация (Privatisation): Сокрытие функциональности в приватной секции (private), что затрудняет его расширение в классах-потомках
Френд-зона (Friend zone): Неуместное использование дружественных классов и дружественных функций в языке с++

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

Ненужная сложность (Accidental complexity): Внесение ненужной сложности в решение
Действие на расстоянии (Action at a distance): Неожиданное взаимодействие между широко разделёнными частями системы
Накопить и запустить (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных
Слепая вера (Blind faith): Недостаточная проверка (a) корректности исправления ошибки или (b) результата работы подпрограммы
Лодочный якорь (Boat anchor): Сохранение более не используемой части системы
Активное ожидание (Busy spin): Потребление ресурсов ЦПУ (процессорного времени) во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать асинхронное программирование (к примеру, систему сообщений или событий)
Кэширование ошибки (Caching failure): Забывать сбросить флаг ошибки после её обработки
Воняющий подгузник (The Diaper Pattern Stinks): Сброс флага ошибки без её обработки или передачи вышестоящему обработчику
Проверка типа вместо интерфейса (Checking type instead of membership, Checking type instead of interface): Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс
Инерция кода (Code momentum): Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы
Кодирование путём исключения (Coding by exception): Добавление нового кода для поддержки каждого специального распознанного случая
Таинственный код (Cryptic code): Использование аббревиатур вместо мнемоничных имён
Жёсткое кодирование (Hard code): Внедрение предположений об окружении системы в слишком большом количестве точек её реализации
Мягкое кодирование (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование
Поток лавы (Lava flow): Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия
Волшебные числа (Magic numbers): Включение в алгоритмы чисел без объяснений их смысла
Процедурный код (Procedural code): Когда другая парадигма является более подходящей
Спагетти-код (Spaghetti code, иногда «макароны»): Код с чрезмерно запутанным порядком выполнения
Мыльный пузырь (Soap bubbel): Класс, инициализированый мусором, максимально долго притворяется, что содержит какие-то данные
Мютексный ад (Mutex hell): Внедрение слишком большого количества объектов синхронизации между потоками

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

Программирование методом копирования-вставки (Copy and paste programming): Копирование (и лёгкая модификация) существующего кода вместо создания общих решений
Дефакторинг (De-Factoring): Процесс уничтожения функциональности и замены её документацией
Золотой молоток (Golden hammer): Сильная уверенность в том, что любимое решение универсально применимо. Название происходит от поговорки «когда в руках молоток, все проблемы кажутся гвоздями»
Фактор невероятности (Improbability factor): Предположение о невозможности того, что сработает известная ошибка
Преждевременная оптимизация (Premature optimization): Оптимизация на основе недостаточной информации
Изобретение колеса (Reinventing the wheel): Создание с нуля, вместо использования готового решения
Изобретение квадратного колеса (Reinventing the square wheel): Создание плохого решения, когда существует хорошее известное решение
Самоуничтожение (Self-destruction): Фатальная ошибка либо нестандартное поведение программы, приводящая к отказу в обслуживании, возникшая вследствие другой менее серьёзной ошибки. Например, при возникновении ошибки, приложение начинает очень быстро и много писать в лог, вследствие чего заканчивается место на жёстком диске быстрее, чем это обнаружит мониторинг.
Два тоннеля: Вынесение новой функциональности в отдельное приложение вместо расширения уже имеющегося. Чаще всего применяется, когда по каким-либо причинам (в основном, при нехватке времени либо нежелании менеджмента) внесение изменений в уже имеющийся код требует больших затрат, чем создание нового. При этом у клиента в конечном итоге работают два приложения, запускаясь одновременно либо попеременно друг из друга.

Анти-паттерны управления конфигурацией

Ад зависимостей (Dependency hell, на платформе Microsoft Windows также называется «DLL-ад», «DLL hell»): Разрастание графа взаимных зависимостей программных продуктов и библиотек, приводящее к сложности установки новых и удаления старых продуктов. В сложных случаях различные установленные программные продукты требуют наличия разных версий одной и той же библиотеки. В наиболее сложных случаях один продукт может косвенно потребовать сразу две версии одной и тот же библиотеки.

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

Аналитический паралич (Analysis paralysis): неоправданно большие затраты на анализ и проектирование. Часто приводит к закрытию проекта до начала его реализации;
Дойная корова (Cash cow): когда при наличии продукта, приносящего выгоду без существенных вложений не вкладываются средства в развитие и разработку новых продуктов;
Продолжительное устаревание (Continuous obsolescence): выделение непропорционально больших усилий на портирование системы в новые окружения;
Сваливание расходов (Cost migration): перенос расходов на проект к уязвимому отделу или бизнес-партнёру;
Ползущий улучшизм (Creeping featurism): добавление новых улучшений в ущерб суммарному качеству системы;
Разработка комитетом (Design by committee): разработка проекта без централизованного управления, либо при некомпетентном руководстве;
Эскалация обязательств (Escalation of commitment): продолжение реализации решения после того, как доказана его ошибочность;
Я тебе это говорил (I told you so): игнорирование мнения эксперта
Управление основанное на числах (Management by numbers): излишнее внимание к численным показателям, либо имеющим очень косвенное отношение к управляемой системе, либо сложным для получения;
Драконовские меры (Management by perkele): неоправданно жесткий стиль управления;
Управление грибами (Mushroom management): недостаточное информирование работников о выполняемой работе;
Расползание рамок (Scope creep): потеря контроля над разрастанием проекта;
Замыкание на продавце (Vendor lock-in): жесткая привязка к поставщику;
Тёплое тело (Warm body): человек, чей вклад в проект под сомнением;
Единственный знающий человек (Single head of knowledge, SHOK): когда жизненно важными для проекта сведениями или навыками обладает только один человек в команде; с его уходом работа останавливается;
Рыцарь на белом коне (Knight in shining armor, KISA): когда на сцене появляется человек, который пытается починить всё, не сообщая никому, что он сделал и почему.

Некоторые социальные анти-паттерны

Статус некоторых из них может быть спорным.

Цензура (Censorship): Подавление дискуссии и запрещение определённых тем в рамках обсуждения системы, в результате которого система ухудшается по качеству, функциональности или другим показателям
Концентрация власти (Political corruption, Concentrated power): Индивидуальное злоупотребление властью, даже с изначально хорошими помыслами
Демократия (Democracy): Большая группа индивидов не может принимать аргументированные решения, а руководствуется лишь поверхностной информацией.
Диктатура (Dictatorship): Не всегда один индивид имеет все навыки, необходимые для ведения проекта и грамотного управления.
Дискриминация (Discrimination): Концентрация на неуместных особенностях усиливает экономическую неэффективность и социальную напряжённость
Догмат (Dogmatic religion): Догмат подавляет индивидуальное мышление и тормозит прогресс
Нетерпимость (Intolerance): Настаивание на изменении нежелательных, но безопасных особенностей других людей влечёт усиление напряжённости и также, очень часто является задачей, которая отнимает время от проекта, и решение которой не имеет значительных плюсов
Монополия (Monopoly): Без соперничества большинство эффектов свободного рынка не работают, и частная компания не имеет стимула действовать максимально эффективно
Система голосования на основе большинства (Plurality voting system): Политика при голосовании на основе большинства вырождается в две полярно-противоположные партии, результатом чего является подавление других политических воззрений
Соревнование в популярности (Popularity contest): Популярность становится самодостаточной величиной и не сопоставима ни с каким другими параметрами или достоинствами
Сегрегация (Racial segregation): Разделение по равноправию весьма редко, если вообще существует; ведёт к напряжённости
Однопартийная система (Single-party system): Аналогично монополии, но внутри компании.
Тоталитаризм (Totalitarianism): Нередко подавление индивидуальности с переходом за определённые рамки, ведёт к напряжённости, которая отрицательно влияет на эффективность.
Преступление без жертв (Victimless crime): Подавление поведения создаёт субкультуру людей, постоянно живущих по другим законам, для которых эта правовая система является врагом
Охота на ведьм (Witch hunt): Попытки отыскать козла отпущения, но если проблема никогда не решается в действительности, результатом будет являться поиск всё новых и новых козлов отпущения
Нулевой Год (Year Zero): Социальное изменение является долгим процессом, ускорение его влечёт катастрофу

Шуточные анти-паттерны

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

Литература

Perl Design Patterns — A free online book
William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. — John Wiley & Sons, 1998. — ISBN 0471197130

Ссылки

Tutorial on anti-patterns
Anti-patterns catalog
Worse Than Failure
SourceMarking
Перевод статьи «Resign Patterns» — Проломы проектно-дизориентированного проектирования
Perl Design Patterns book
The Diaper Pattern Stinks

Анти-паттерны
Архитектура программного обеспечения
Компьютерный юмор

Wikimedia Foundation . 2010 .

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

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

Что такое антипаттерны

Обсудим сперва само понятие «антипаттерн». Википедия убеждает нас, что антипаттерн — это неэффективный, рискованный или непродуктивный подход к решению часто встречающихся проблем. Хорошее определение в целом, но чувствуется в нем некая стигматизация. Создается впечатление, что присутствие антипаттерна является следствием чьего-то злого умысла или «недалекости» специалиста, который это допустил. Но давайте условимся: все решения, которые когда-либо были приняты кем-то в вашей системе или проекте, исходили исключительно из положительных намерений. То есть никто не собирался специально вредить. Более того, все решения были приняты в определенном контексте, который сейчас мог просто-напросто измениться. Допустим, были неблагоприятные времена с недостатком компетенций, времени или бюджета.

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

Зачем знать антипаттерны

Чтобы это уяснить, приведем некоторые афоризмы, хорошо описывающие тему. Начнем с английской пословицы: «Лучше дьявол, которого знаешь, чем тот, которого не знаешь». Зная антипаттерны, вы понимаете, чего от них ждать. Можете заранее просчитать риски их использования в отличие от неизвестных вам антипаттернов.

Идем дальше. Как говорил старик Фрейд: «Признание проблемы — это половина успеха в ее разрешении». Диагностировав где-либо антипаттерн, вы уже немало сделали для его устранения.

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

Что делать с антипаттернами

Первое — стараться их избегать (привет, кэп). Кроме того, необходимо грамотно оценивать риски от наличия или использования антипаттерна. Будем с вами честны: оценка задач для разработчиков — и так достаточно сложная дисциплина. Если учитывать еще и все риски, это на порядок увеличивает сложность. Далее следует найти причину использования антипаттерна, для чего вспомнить несколько законов архитектуры: а) любое решение является компромиссом; б) вопрос «почему?» важнее вопроса «как?». Последнее — антипаттерны нужно приручить и контролировать.

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

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

Инверсия абстракции

Обычно это выглядит как попытка реализации низкоуровневых конструкций поверх высокоуровневых. Для примера рассмотрим вот такую вот цепочку вызовов.

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

Скорее всего, вам сразу показалось странным и неэффективным решением вычитывать весь список объектов для подсчета количества на стороне бизнес-логики. Вам не показалось: это действительно место, где происходит инверсия абстракции. И это пример антипаттерна. Здесь низкоуровневая конструкция количества записей строится поверх высокоуровневой конструкции.

Более приемлемой схемой тут будет сделать метод, который эффективно считает количество записей, на слое доступа к базе данных. Бизнес-логика будет вызывать его и возвращать это значение на UI. Это достаточно простой пример, и здесь главное — уловить суть антипаттерна.

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

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

Следующий антипаттерн называется

Большой ком грязи

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

Возможных причин появления такого антипаттерна хватает.

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

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

Причина №3. Изменение требований, особенно когда они приходят уже после реализации. Еще острее это чувствуется в системе с негибкой архитектурой.

Причина №4. Текучка кадров. Вместе с человеком обычно уходит часть знаний и контекста, которые вносили хоть какую-то структуру и порядок в вашу систему.

Причина №5. Рост системы и технического долга. Навык управления техническим долгом является очень ценным. И это дорого. Поэтому он есть далеко не в каждой команде.

Причина №6. Унаследованная сложность: если предметная область является большим комом грязи, то ваша архитектура примет такие же очертания. Насколько понятна и прозрачна предметная область, настолько же будет чистая и стройная архитектура.

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

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

Предположим, что микросервисов нет. Что нам поможет? В данном случае действительность хорошо отражает одна японская мудрость: «Делай чище, чем было до тебя». Так как дело предстоит иметь с чем-то не очень чистым, совет номер один — засучить рукава, естественно. Потом нужно постараться выявить хоть какую-нибудь структуру. Ведь если ком грязи работает, значит не все потеряно, и выявление структуры точно не будет бесполезным.

Далее стоит определить части, которые можно рассортировать. Допустим, у вас разные есть компоненты, они между собой связаны. Отсортируйте их хотя бы по зависимости друг от друга. Потом можете распределить их по значимости (если уже понимаете, какой компонент более важен, какой — менее). Можно по чистоте: какие части написаны совсем в дремучее время на старых подходах, а какие созданы недавно, и можно найти хоть кого-то с внятным объяснением.

После этого составьте план и — вперед, рефакторить! Конечно, если согласуют ресурсы. Но это уже совсем другая история.

Vendor lock-in

Следующий антипаттерн, который мы рассмотрим, — это vendor lock-in. Обычно он выглядит, как архитектура, основанная на определенных продуктах. Под продуктом тут имеется в виду определенная база данных, сервис или технология. Vendor-ом называется поставщик таких продуктов. Особенно больно от этого антипаттерна становится, когда вы платите vendor-у немалые деньги.

Здесь есть ремарка для vendor-ов: если вы таковым являетесь, то у вас есть свой антипаттерн — «обратный vendor lock-in», когда уже поставщик начинает зависеть от определенного заказчика. Но в данной статье мы это опустим и вернемся к обычному vendor lock-in.

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

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

Важное — определяйтесь с vendor-ом своевременно! Как говорит Роберт Мартин (он же дядя Боб) в своей книге про чистую архитектуру: хорошая архитектура позволяет откладывать принятие ключевых решений. Гибкая архитектура позволяет откладывать выбор vendor-а, инструмента, технологии. А главное — дает возможность их легко заменить в будущем. С этим связан тесно следующий антипаттерн, который называется

Cover your Assets

Данный паттерн выглядит, как предоставление набора вариантов вместо конкретного решения или вовсе избегания принятия решения под любым предлогом. Частенько приходится выбирать между несколькими хорошими вариантами или если нам совсем не повезло, то между несколькими плохими. Здесь можно впасть в состояние, которое называется «аналитический паралич». Это когда мы очень сильно боимся совершить ошибку или отказаться от лучшего решения в угоду какого-то быстрого. Кажется, что легче вообще не делать выбор. Увы, не легче. Что с этим делать?

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

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

Раз уж мы с вами затронули антипаттерны, связанные с принятием решений, давайте рассмотрим еще один.

CV Driven Development

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

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

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

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

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

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

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

Если хотите больше погрузиться в архитектуру

20 февраля стартует второй поток курса «Архитектура приложений». Мы создавали его для разработчиков и всех, кто хочет думать как архитектор. Посмотреть программу можно здесь: slurm.club/3jdGzWA

Анти-паттерн

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

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

1 Анти-паттерны программирования
2 Анти-паттерны системного администрирования
3 Организационные анти-паттерны
4 Антихитрожопость
5 Гиперссылки

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

Жёсткий код, от англ. hard code — про него ещё говорят «прибито гвоздями». Код настолько привязан к конкретной аппаратной конфигурации и/или системному окружению, что оторвать его для переноса в другое место можно только гвоздодёром.

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

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

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

Ад зависимостей, от англ. dependency hell — для юниксовых сисадминов. Прямо проистекает из того факта, что строители юниксовых дистрибутивов (в первую очередь линупсов) однажды возгордились и решили возвести Вавилонскую башню упорядочить весь линуксовый софт, так, чтобы одна программа в дистрибутиве не мешала другой. Последствия этой попытки пользователи порой ощущают в виде «циклических зависимостей» и прочих дорожек в dependency hell.
Ад DLL, от англ. 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 — распространённый подкласс менеджеров, действующих в следующей последовательности: прилетел, поорал и улетел, оставив за собой кучки проектного дерьма, которые потом, матерясь, подчищают подчинённые. По поведению напоминают морских ворон чаек, парящих гордо между тучами и морем и прилетающих на берег с целью быстро пожрать и попутно опорожнить кишечники, за что они (менеджеры) и переняли данное наименование. Самый бестолковый для проектной деятельности тип, но начальство их любит, так как корпоративные чайки умеют громко хлопать крыльями заявлять о себе, выдавая копеечную деятельность за великие свершения. Живучи, их сложно поймать на ошибках, так как ошибок они не совершают (поскольку, как известно, для этого нужно хоть что-то делать).

Отсутствующий менеджер, от англ. Absentee manager — более запущенный случай менеджера-чайки. Этот кадр даже не прилетает поорать и погадить, его просто всегда нет на месте, и почти всегда по уважительной причине. В итоге подчинённые остаются вариться в собственном соку без всякой поддержки.

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

Антихитрожопость [ править ]

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

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

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

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

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

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

Гиперссылки [ править ]

Большой неиллюстрированный каталог анти-паттернов (англ.)
Проломы проектно-дизориентированного проектирования

Глубокий смысл скрыт в этих неестественных языках
Языки программирования	Промышленные: 1С • BAT • C# • C • C++ • Java • JavaScript (AJAX) • Pascal • Perl • PHP • Python • Ruby • ABAP • Ассемблер • Васик • Фортран Эзотерические: BrainFuck • HQ9+ • + • Erlang • Forth • Haskell • LISP (My other car) • Prolog • Tcl • Τ Ε Χ • Oracle • MySQL • Golang • В++
Профессии	Быдлокодер • Программист • Тестировщик • Хакер • Хеллоуворлдщик • IT-звёзды
Методы и стили	Reverse Engineering • Анти-паттерн • Выстрелить себе в ногу • Грязный хак • Код (индусский) • Костыль • Метод научного тыка • Помолясь • Свистелки и перделки • Очередь • Спортивное программирование • Обфускация • Бета-тест • Альфа-тест • Шаблоны • RegReplace
Средства разработки	Sublime Text • Подсветка синтаксиса кода • Unstable Diffusion • API • PythonTutor • CodeWars • DataCamp
Люди	Илья Кантор • Юрий Ключевский • Эдуард Лаас
Прочее	++i + ++i • Deadline • %s • 640 килобайт • CMS • Dummy mode • ЕГГОГ • Foobar • God is real, unless explicitly declared as integer • GOTO • Ifconfig • KISS • RegExp • SICP • sql.ru • Xyzzy • Дискета • Инжалид дежице • КОИ-8 • Лог • Ман • Рекурсия • СУБД • Тест Тьюринга • Умение разбираться в чужом коде • Фаза Луны • Фатальный недостаток • Проблема 2000 • Таймстамп • Кэш • Запись в файл без кэша (Perl) • Танцы с бубном