Меня часто спрашивают, чем архитектор отличается от опытного программиста. Оба знают технологии, оба пишут код, оба разбираются в базах данных. Ответ, который я для себя нашёл, звучит так: программист решает, как сделать, а архитектор решает, что потом будет трудно изменить. Архитектура это не красивая схема с квадратиками и стрелками, и не выбор модного фреймворка. Это серия решений, которые закладывают фундамент, и цена ошибки в каждом из них растёт с каждым месяцем жизни системы.
Архитектура это то, что трудно изменить потом
В строительстве эта мысль очевидна. Цвет стен можно поменять за выходные. Перенести окно уже сложнее. А сдвинуть фундамент или добавить этаж к дому, который на это не рассчитан, практически невозможно без того, чтобы снести всё и построить заново. Никто не обсуждает с прорабом цвет обоев на этапе заливки фундамента, но вот глубину и прочность фундамента обсуждают очень серьёзно.
С программами точно так же, только фундамент не виден глазами, и поэтому его часто заливают на скорую руку. Модель данных, способ хранения истории, разделение системы на модули, принцип работы с правами доступа, подход к интеграциям: всё это фундамент. Интерфейс, тексты, расположение кнопок, отчёты: это обои. Обои меняются легко. Фундамент нет. И задача архитектора в том, чтобы отличить одно от другого и не тратить месяцы на обои, когда не залит фундамент.
Каждое архитектурное решение на старте либо позволит бизнесу масштабироваться, либо станет его стеклянным потолком. Узнаёте Вы об этом обычно тогда, когда упираетесь головой.
Решения, которые нельзя откладывать
Я разделяю решения на две группы. Первые можно отложить: их легко изменить потом, и принимать их рано значит гадать. Вторые откладывать нельзя: их изменение в будущем обойдётся очень дорого. Мастерство архитектора во многом состоит в том, чтобы правильно рассортировать решения по этим двум корзинам. Вот что почти всегда попадает во вторую.
- Модель данных. Какие сущности есть в бизнесе и как они связаны. Если сегодня заказ может принадлежать только одному клиенту, а через год окажется, что бывают совместные заказы, переделка затронет половину системы.
- Границы модулей. Что от чего зависит и где проходят швы. Хорошо разделённую систему можно развивать по частям, плохо разделённую можно только переписать целиком.
- Безопасность и персональные данные. Защиту, заложенную в ядро, почти ничего не стоит поддерживать. Защиту, прикрученную сверху к готовой системе, приходится латать вечно.
- Подход к масштабированию. Не обязательно строить систему под миллион пользователей с первого дня, но нужно понимать, что придётся менять, когда их станет в десять раз больше, и не делать этот путь невозможным.
Критерии, по которым я принимаю решения
Для каждого ключевого решения я задаю себе несколько вопросов. Первый: сколько будет стоить владение этой системой через два-три года? Не разработка, а именно владение: поддержка, обновления, поиск людей, которые в этом разбираются. Экзотическая технология может сэкономить месяц на старте и стоить годы мучений потом, когда единственный специалист по ней уволится.
Второй: выдержит ли решение рост в десять раз? Не в сто и не в тысячу, это обычно фантазии, а именно в десять. Если при росте в десять раз всё рушится, решение нужно пересмотреть сейчас. Если выдерживает, этого достаточно на ближайшие годы.
Третий: насколько это обратимо? Если решение легко отменить, принимайте его быстро и не мучайтесь. Если нет, остановитесь, соберите данные, посоветуйтесь, нарисуйте варианты. Время, потраченное на необратимое решение, окупается всегда.
Баланс между скоростью и совершенством
Есть две классические ошибки, между которыми архитектор всё время балансирует. Первая: построить всё быстро и без оглядки, потому что рынок ждёт. Через полгода такая система начинает тормозить каждую новую функцию, и скорость, ради которой всё затевалось, исчезает. Вторая: проектировать идеальную архитектуру на годы вперёд, предусматривая всё на свете, и так и не выпустить продукт. Я видел оба сценария много раз, и оба одинаково дорогие.
Правильный путь где-то посередине: тщательно продумать необратимое и быстро сделать всё остальное. Это как собирать рюкзак в поход: на палатке и обуви экономить нельзя, а вот всё остальное можно докупить по дороге.
Что делать, если Вы заказчик
Требуйте от подрядчика не только сроков и цены, но и объяснения ключевых архитектурных решений. Почему такая модель данных. Как система будет расти. Что будет трудно изменить потом и почему выбран именно такой вариант. Если подрядчик не может ответить на эти вопросы простыми словами, скорее всего, он их себе не задавал.
В Systems мы начинаем любой проект с архитектурного этапа, на котором фиксируем ключевые решения и их причины, чтобы через год было понятно, почему система устроена именно так. А Fractal позволяет описывать фундамент системы отдельно от отделки: модель данных, экраны и сценарии задаются описанием, и меняются осознанно, а не случайными правками в коде. Архитектура это не про технологии. Это про то, какое будущее Вы разрешаете своей системе.
