Что такое хорошая архитектура, что такое плохая архитектура

Архитектура

Что такое архитектурная космонавтика

Хорошее объяснение "архитектурных астронавтов" дал Джон Спольски в своей статье Don’t Let Architecture Astronauts Scare You

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

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

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

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

Что значит архитектура "поддерживает" проект

По поводу того как архитектура мешает делать неправильные вещи

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

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

Изоляция, грануляция, проведение границ, разделение ответственности - основные архитектурные инструменты на уровне системы и приложения.

Типы, принципы и паттерны - это инструменты архитектуры на уровне кода.

Еще пример

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

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

Как типы помогают программировать

Заметил, что после того как программист переходит на TypeScript, после чистого JavaScript, то через некоторое время, он все меньше смотрит в браузер и все больше доверяет парсеру TS. Цикл работы сокращается и разработка идет быстрее.

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

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

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

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

Не зря все больше фронтендеров любят TS, по сути это означает, что они все больше любят "типы".

Ограничения по уровням

Уровень кода

  • ревью кода;
  • соглашения уровня кода (SOLID, GRASP и т.д.)
  • шаблоны
  • тесты

Уровень приложения

  • программные интерфейсы
  • модули
  • соглашения уровня приложения (статический анализ)
  • тесты
  • документация (storybook, спецификации, комментарии и т.д.)
  • версионирование

Уровень системы

  • границы ("логическое" разделение данных, например, фронтенд и бэкенд, разделение не уровне API)
  • документы (ADR, спецификации, проектная документация и т.д.)
  • IT-ландшафт (IT-архитектура (IT-ландшафт) — совокупность информационных систем, сервисов, услуг и продуктов компании, использующихся на производстве, в коммуникации, аналитике, учете, получении дохода.)

Уровень предприятия

  • организационная структура (закон Конвея - организации проектируют системы, которые копируют структуру коммуникаций в этой организации)
  • должностные
  • технология разработки (scrum, canban и т.д.)

Как архитектурные ограничения помогают поддерживать проект

Коллективный разум vs документирование

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

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

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

Технологии - это тоже ограничения

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

К технологиям относится как инфраструктура (СУБД, ОС, среды передачи данных), так и средства разработки и сопровождения (фреймворки, ЯП, автоматизация и т.д.).

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

Что делает архитектор

Как можно сломать архитектуру проекта и как понять, что что-то идет не так

  • Ограничения не работают если они незадокументированны
  • Неквалифицированные кадры или "против лома нет приема"
  • Отсутствие контроля или "неуверенный бизнес"
  • Нет ответственного лица
  • Нет системы принятия решений

Как гранулировать проектные решения

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

Архитектурный коммитет

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

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

Регулирумые vs свободные бизнесы

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

Можно выделить две основные группы бизнесов: "регулируемые" и "свободные".

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

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

Крупные vs мелкие бизнесы

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

Распределенные vs локальные команды

Отдельно нужно отметить, что фактор "рассредоточения" команды сильно влияет на то каким образом следует гранулировать проектные решения - здесь так же используется принцип, чем больше рассредоточена команда, тем детальнее грануляция.

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

"правильно" - не значит "хорошо"

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

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

Теоретические "правильные" требования не обязательно приведут к улучшению ситуации в компании, поэтому нужно помнить, что бывают стандартные проблемы, которые нужно учитывать:

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