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

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

База такая: архитектура — это инструмент, который позволяет быстрее доносить ценность как для пользователя, так и для заказчика. Хорошая архитектура дешевле и быстрее доносит ценность, плохая — медленнее и дороже.
Из этой базы исходит то, что архитектура должна решать следующие задачи:

• 💰 Сохраняет стоимость внедрения фичей. Бизнесу важно, чтобы стоимость внедрения новых фичей, которые по сложности не отличаются от предыдущих, не росла в цене. Если в начале проекта стоимость внедрения фичи X, а через полгода 2X — это проёб архитектуры, который реально может сильно ударить.

• 👥 Параллелизация работы. Представьте, что на проекте один разработчик, и у него весь проект в нескольких основных файлах. Пока он один, он, возможно, даже хорошо справляется и делает всё в срок. Однако с ростом бизнеса вам нужно открывать новые направления, и одного разраба уже не хватит. Вам нужно нанять ещё 2-3. В этом случае параллелизация работы практически невозможна, вы умрёте в конфликтах. Поэтому важная часть архитектуры в том, что она должна обеспечивать разделение работы.

• 🧪 Тестирование. Это может проявляться на уровне кода, когда вы забили на DI, и нельзя никак подменить зависимость для тестов, и никак нельзя протестировать отдельную фичу, не задев ничего другого. Также может проявляться на уровне всей системы, когда у вас нет возможности поменять конфиги для QA контура, и тестировать можно исключительно на проде — это, кстати, проблема как бэка, так и фронта.

• 🚀 Развёртывание. Не актуальный пункт для мобилок, но очень важный для бэка. Архитектура должна помогать в поднятии новой версии приложения. Если у вас приложение спроектировано так, что может работать только один инстанс и при этом много пользователей, то у вас проблемы. Ведь про zero downtime можно забыть.

• 🔄 Деградация. Хорошая архитектура должна отвечать на вопрос: "А что будет, если у нас отъебнёт база?" или, если мы говорим про мобилку: "Что будет, если инет пропадёт?"

• 👁 Observability. Это уже больше про SRE, однако каждому важно понимать, что архитектура должна давать возможность трекать состояние каждого элемента системы, чтобы быстро понимать, где именно проблема.

Мне очень нравится выражение Иванова: не бывает плохих архитектур, бывают дорогие.