Первая неделя на проекте. Задача кажется мелкой: добавить поле в профиль пользователя. Код написан за час, тесты зеленые. А на следующее утро падает сервис рассылок, о котором тебе никто не рассказывал.
Junior не решает, какой будет архитектура системы. Зато каждый день работает внутри уже принятых решений. И чем раньше становится понятно, почему система устроена именно так, тем меньше таких утр. Разберемся, почему Junior должен понимать архитектуру проекта.
Что такое микросервисная архитектура и где с ней сталкивается Junior
Микросервисная архитектура делит приложение на небольшие сервисы, каждый из которых отвечает за свою часть бизнеса. Один сервис ведет заказы, другой считает оплату, третий отправляет уведомления. У каждого микросервиса свой код, часто собственная база данных, и разворачивается он отдельно. Общаются они через API (оговоренный интерфейс для запросов между программами) или через брокер сообщений.
Сам термин microservices закрепился после статьи Мартина Фаулера и Джеймса Льюиса 2014 года. В англоязычных поисковых запросах его еще пишут раздельно, micro services, но речь идет об одном и том же.
Junior сталкивается с этим не на уровне схем. Ты открываешь репозиторий одного сервиса и видишь, что половина данных приходит откуда-то извне. Задача звучит как изменение в одном месте, а затрагивает три.
Монолит или микросервисы: почему команда вообще выбирает архитектуру
Что такое монолит? Это приложение, где вся логика живет в одной кодовой базе и разворачивается одним пакетом. Монолитная архитектура проще на старте: один репозиторий, одна база, понятный дебаг. Для небольшой команды с молодым продуктом это часто самый разумный выбор.
Проблемы начинаются с ростом. Двадцать разработчиков коммитят в один код, релиз ждет, пока все договорятся, а одно медленное место тормозит все приложение. Тогда команда задумывается о разделении.
У микросервисов тоже есть цена: сетевые сбои, более сложное тестирование, отдельный мониторинг для каждого сервиса. Поэтому решение зависит от масштаба продукта, размера команды, нагрузки и того, сколько людей сможет это поддерживать. Подробнее о плюсах и минусах обоих подходов мы писали в сравнении микросервисной и монолитной архитектур.
Что меняется в работе Junior в микросервисном проекте
В монолите можно сосредоточиться на своем методе. IDE подсветит все места, где его вызывают, компилятор не даст сломать сигнатуру. В микросервисах этой страховки нет. Другой сервис вызывает твой через сеть, и компилятор о нем ничего не знает.
Отсюда новые обязанности. Перед изменением API нужно знать, кто им пользуется. Поле, которое кажется лишним, может читать аналитика. Переименование в JSON-ответе ломает контракт (договоренность о формате данных между сервисами), даже если твой код безупречен.
Меняется и дебаг. Ошибка часто возникает не там, где проявляется. Пользователь видит сбой в корзине, а причина в сервисе цен, который ответил с опозданием. Чтобы найти такое, приходится читать логи нескольких сервисов и понимать, как запрос проходит через систему. Привыкнуть к такой работе проще всего там, где ошибка стоит дешево, например на стажировке на IT-проекте.
Какие архитектурные решения Junior должен научиться замечать
Мелвин Конвей еще в 1968 году заметил, что организации проектируют системы, которые копируют структуру их коммуникаций. Границы сервисов часто совпадают с границами команд, и это ключ к пониманию проекта. Когда берешь новую задачу, полезно ответить себе на четыре вопроса:
- Кто отвечает за конкретные данные и бизнес-логику? Если сервис не владелец данных, менять их напрямую нельзя, только через того, кто за них отвечает.
- Как сервисы взаимодействуют между собой? Синхронный запрос ждет ответа, событие в очереди обрабатывается позже, и от этого зависит, что увидит пользователь.
- Почему ответственности разделены именно так? За каждой границей стоит чье-то решение, и его причину стоит знать.
- Что произойдет с другими компонентами после изменения кода? Кто читает эти данные, кто подписан на это событие.
Здесь и появляется связь с основами. ООП, GRASP, SOLID и GoF учат распределять ответственности внутри сервиса. Микросервисы ставят тот же вопрос на уровне системы.
Почему знания паттернов без понимания архитектуры недостаточно
Junior может рассказать о Factory, Adapter и Observer. На собеседовании это помогает. На проекте быстро выясняется, что название паттерна ничего не говорит о том, зачем его здесь использовали.
Возьмем Adapter. В микросервисах он часто стоит на границе с внешним сервисом и защищает твою логику от чужого формата данных. Кто понимает эту причину, тот не протянет формат партнера вглубь своего кода. Кто знает только название, сделает адаптер и все равно передаст сырой объект дальше. Название паттерна здесь второстепенно. Важна граница, которую он охраняет.
Профессиональный рост начинается с вопроса почему. Почему граница здесь, почему эта зависимость, почему именно такой шаблон. Как ООП, GRASP, SOLID и GoF складываются в одну систему, мы разбирали отдельно, и именно это понимание отличает Middle от Junior.
YouTube
Смотри на систему шире своей задачи еще до того, как стать Middle
Архитектурное мышление не появится от одних только книг, но его можно тренировать уже сейчас. Читай документацию проекта и схемы взаимодействия сервисов, даже если они немного устарели. Разбирай чужие pull requests и спрашивай автора, почему выбрано именно это решение.
Задавать вопросы Senior или Tech Lead нормально: каждый ответ экономит тебе недели догадок. Замечай, какие компоненты зависят от кода, который ты меняешь, и со временем в голове сложится карта системы.
Теоретическую основу дает книга Сергея Немчинского Фундамент архитектуры, где ООП, GRASP, SOLID и GoF объяснены как одна система.
Junior, который видит место своей задачи в системе, ломает меньше и растет быстрее. Следующую задачу начни с поиска тех, кого она затронет.
