АРХИважный этап

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

До самого проектирования, продолжает Александр, стоит поговорить о требованиях: заказчик приносит функциональные, а сложность архитектуры задаёт вторая половина — нефункциональные. На системном дизайн-интервью это видно сразу: функции кандидат закрывает, а нагрузка, доступность, отказоустойчивость при пропаже питания или сети и maintainability остаются за кадром; потом приходят безопасники, и требования начинают конкурировать между собой — производительно или безопасно. Бизнесу нефункциональные требования продаются плохо, ведь он заказывал функции, поэтому их стали называть атрибутами качества системы, а затем архитектурными характеристиками. Собирать их нужно конкретно: сколько людей придёт, где хранятся данные, можно ли их терять — для статистики рекламных кликов процент потерь приемлем, для финансовых транзакций нет, — а потом расставить приоритеты: must have, nice to have и то, что в этой системе никого не волнует. Ведущая отмечает, что это похоже на технику shift left testing.

Ведущая рассказывает, что в её проекте архитектор есть, но подключается далеко не ко всем задачам, и спрашивает, должность это или роль. Позиция Александра, по его словам, не самая популярная в архитектурном сообществе: это роль, и не одна. Software-архитектура — проектирование самой системы; solution-архитектура — сквозной проект, где нужно соединить набор систем и договориться с несколькими командами; есть и третья, мифическая роль архитектора, который в «зелёном банке» или «синем банке» нередко получает второе имя PowerPoint-архитектора. В Тинькофф, где Александр курирует часть архитектурных вопросов, грейды архитекторов и системные дизайн-интервью, ставка сделана на автономную команду с сильными инженерами внутри. Выделенный человек нужен на проекте через половину организации: аудит ландшафта, анализ мирового опыта, набор опций со своей стоимостью и сроками. Решение под сегодняшние ожидания он сравнивает с ботинками впритык, купленными малышу: через три месяца нужны новые.

Чтобы команда двигала архитектуру целенаправленно, нужны понятные правила игры — ADR и RFC. Request for comments — заявка на обсуждение: человек описывает идею в документе, остальные комментируют, идею реализуют, дорабатывают или выбрасывают, а серия документов превращается в карту решений. Пример Александра: в документе условно фиксируют, что 14 сентября 2022 года выбрали пилить монолит на такие-то части и почему; через полгода задачи поменялись — команда проходит по тому же процессу заново. Без такой карты и для команды, и для бизнеса всё выглядит как флюгер, поворачивающийся туда, куда подул ветер. Лог решений помогает и против sunk cost: свой движок форм работает и много умеет, но порог входа для новых разработчиков высокий, а открытое решение за эти годы развилось — стоит спросить, выбрали бы вы своё, если бы решали сегодня, и не делали ли инструмент ради инструмента. Память пластична, люди правят собственную историю задним числом, а документ — нет. Ведущая резюмирует: важно не кто инициирует изменение, а что команда может его отревьюить.

Ведущая спрашивает, чем качание маятником — распилили приложение, слили обратно, снова распилили — отличается от развития. Александр напоминает, что в IT решения повторяются: Таненбаум показывает это на виртуализации, которая жила на мейнфреймах, вернулась на x86 на рубеже девяностых и двухтысячных, а из-за накладных расходов уступила контейнерам; возвращаются они потому, что перемещается бутылочное горлышко. Управлять этим он предлагает фитнес-функциями из концепции эволюционной архитектуры, о которой рассказывал на конференции компании в прошлом году: выделенные архитектурные характеристики можно померить. Динамические — через SLO, логи и метрики, статические — через ограничения на структуру: как связаны компоненты и какая цепочка вызовов обслуживает запрос. Иначе выходит распределённый монолит, где на компьютере разработчика всё поднято в одной среде, а в реальном развёртывании запрос занимает секунды. Смысл — в сходимости: без внешних изменений система должна прийти в состояние, к которому нечего добавить.

Разница с бэкендом, где со сложностью боролись делением на части, в том, что в мобильном приложении исполняемый файл один: архитектура здесь про то, как жить в одном большом приложении — организовать компоненты и ходить через абстракции, а не импортировать конкретную реализацию чужого класса. Иначе команда второстепенной функции раздувает бинарь притянутой зависимостью или увеличивает старт с секунды до пяти, синхронно ожидая ресурс; Александр сравнивает это с общежитием на Физтехе, где забытая сковорода наполняет запахом весь этаж. Когда бизнес просит автономно развивать банковские, платёжные и нефинансовые продукты, слоёную архитектуру режут вертикально, а за скоростью перехода следят платформенные команды; выигрыш — мини-сборка, на которой прогоняют сценарии своих экранов с замоканной чужой оплатой. На вопрос про инженеров по качеству Александр отвечает, что нефункциональные требования проверяют через proof of concept — упрощённой системой смотрят, переварит ли она нужный объём данных и переживёт ли пиковую нагрузку или отвал дата-центра, — а от инженера ждут сложных, «душных» вопросов: как тестировать решение с eventual consistency, что будет при потере данных или конкурентной работе пользователей. Из книг он советует «Совершенный код» Макконнелла: ошибку дешевле найти в архитектуре, чем в эксплуатации.