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

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

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

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

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

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

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

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

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

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

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

Тут как в теории разбитых окон: наличие антипаттернов в проекте легитимизирует и поощряет их использование. Там, где есть одно применение, можно допустить и второе. Там, где второе, найдется место и третьему. А три штуки — это уже не 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.

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