Атрибуты качества
Ключом к пониманию современных представлений об архитектуре служат атрибуты качества.
Сначала простой и избитый пример. Допустим, архитектор слышит фразу: «мы хотим разработать систему с нуля и в первый год ожидаем 1 000 000 активных пользователей». Тогда архитектор пишет заметку «для системы важен атрибут качества масштабируемость». Если архитектор не застрял в каменном веке, он сразу же спросит: «а эти пользователи каждый день будут активны?». Если ответ будет: «нет, у нас сезонный бизнес, летом 100 активных пользователей, 1 000 000 только под Новый год», архитектор добавляет к масштабируемости атрибут эластичность.
Более жизненный пример – это когда заказчик говорит, что хочет догнать и перегнать конкурентов. Услышав это, архитектор пишет заметку «у системы должно быть конкурентное преимущество» и идёт думать над вариантом диаграммы ниже (у гибкости в реальной жизни больше составляющих).
Ну и последний, не менее жизненный пример – это когда систему нужно сдать через две недели. Допустим, спорить о сроках бессмысленно. Всем ясно, что либо система выходит через две недели, либо мы теряем проект. Архитектор в таком случае пишет заметку «выкидываем из системы тестируемость, масштабируемость, простоту поддержки + ещё десяток атрибутов качества» и фокусируется на оставшихся атрибутах качества. Никаких обид и седых волос, особенно если заказчик такой architectural decision record подписал.
Про существование атрибутов качества известно давно, как минимум, лет 30. Раньше их было немного, сейчас открыли десятки. Например, эластичность (возможность системы автоматически «раздуваться» под нахлынувшей как цунами нагрузкой, при этом не теряя в доступности и времени отклика) стала возможна только после cloud и devops-революций.
Архитектура – это про выяснение и проверку нужных нам атрибутов качества. Дизайн и реализация должны соответствовать нужным атрибутам качества. Типичная ошибка – это рисовать диаграммы компонентов (то есть дизайн) не выяснив и не описав нужные атрибуты качества.
Любой айтишник может стать архитектором. Сначала выбираешь один атрибут качества (тот, к которому сердце лежит) и изучаешь по нему лучшие труды, пока не поймёшь, в чём суть. Лучшие труды можно найти, например, вот так. Потом выбираешь второй атрибут качества и тоже изучаешь его. Ну и так дальше, пока не сможешь внятно рассуждать о любой системе с точки зрения примерно десяти атрибутов качества. Если интересно копнуть тему атрибутов качества в целом, она классно раскрыта в Software Architecture in Practice (2021).
Fitness functions
Cовременные архитекторы пытаются автоматизировать проверку атрибутов качества. Самый широко известный пример – это проверка testability. Архитектор пишет немножко кода, который реализует правило «тесты должны покрывать 90% кода проекта». Если покрытие кода тестами падает ниже 90%, разработчик просто не сможет интегрировать свои изменения до тех пор, пока не напишет тесты. То есть испортить качество реализации или дизайна для разработчика уже сложнее, что радует архитектора. Подобные автоматические правила проверки атрибутов качества называются fitness functions. Впервые о них заговорили в книге «Building Evolutionary Architectures (2017)» (не рекомендую, книжка прорывная, но написана плохо).
Встречаются продвинутые примеры fitness functions. Бывает, в приложении один из модулей вырастает до таких гигантских размеров, что его становится невозможно поддерживать. Для архитектора поддерживаемость важна, поэтому архитектор распиливает этот модуль на модули поменьше и пишет fitness function, чтобы такое больше не повторялось. Fitness function может быть чем-нибудь вроде «ни один из модулей не должен содержать больше 10% логики приложения».
В слоистой архитектуре бывает, что ради достижения краткосрочной цели разработчик пробивает дыру со слоя представления до базы данных. Это может создать кучу проблем в будущем. Но архитектор может такое предусмотреть и написать fitness function «классы слоя представления не должны напрямую обращаться к классам слоя доступа к данным. Вместо этого они должны обращаться только к классам слоя бизнес-логики».
Тема fitness functions хорошо раскрыта в Software Architecture: The Hard Parts (2021), но в неё может быть сложно запрыгнуть с кондачка. Лучше начать с Fundamentals of Software Architecture: An Engineering Approach (2021).
Будущее
Для многих атрибутов качества до сих пор нет измерительных инструментов, они оцениваются «на глаз», либо проверяются вручную. При этом на многих проектах такие огромные потоки изменений, что архитекторы просто не успевают отследить влияние этих изменений на атрибуты качества. К счастью, для некоторых атрибутов качества мы уже имеем классные инструменты вроде ArchUnit, Chaos Monkey, Dependabot, а также линтеров для любых языков программирования.
Надеюсь, в недалёком будущем золотым стандартом индустрии будет автоматическая проверка абсолютно всех интересных атрибутов качества производимого ПО. Вот тогда заживём!