➡️ Часть 1. Разочарование от нового проекта и фундамент для перемен
Часть 2. Выделенная команда и первый сервис по новому стандарту
Часть 3. Разбиение монолита по DDD
Часть 4. Создание шаблона микросервиса
Часть 5. Свой подход к интеграционным тестам
Часть 6. Что дало создание шаблона
Часть 7. Распиливание, миграции и оптимизации
Часть 8. Добровольный боттлнек, коммуникации и овертаймы за свой счет
Часть 9. Что нужно, чтобы драйвить такие перемены и оставить бизнес довольным
Часть 10. Почему распустили System Team и что в итоге?

Сейчас моя позиция называется Backend Owner. Это что-то техлидское, можно было бы назвать Technical Lead, Staff Engineer и даже немного от Principal Engineer. Сейчас у меня уже нет команды. Хотя до этого была. Но к этому мы скоро придём;)

Backend Owner – это не совсем архитектор. Потому что позицию архитектора у нас официально занимает другой человек. Он у нас и DevOps, и архитектор такой супер высокоуровневый. Непосредственно архитектурой и частично инфраструктурой все-таки занимаюсь я, принимаю решения тоже я, иногда в паре с еще одним человеком, но если у меня есть какие-то сомнения, я общаюсь с ним. Однако он все-таки больше в DevOps конкретно на данном проекте. Назовем его TeamMember S, это нам пригодится в дальнейшем.

На этот проект я приходил просто Senior BE-девелопером в конкретную фича-тиму. Было, по-моему, 4 или 5 команд на тот момент. В одну из них я и пришёл весной 2022 года. Познакомившись с кодовой базой, которая там была, как это часто бывает с новыми разработчиками на проекте, скажем так, я немного разочаровался.

Потому что на предыдущем проекте был крутой опыт, когда мы проходили от ужасного Legacy монолита до микросервисной архитектуры, построенной по всем канонам. И поэтому, придя сюда… В общем, немного отвык я от неструктурированного кода и хаоса в коммуникации сервисов.

Код был там абсолютно ужасным (имеется в виду код сервиса, за который отвечала команда, в которую я попал), там даже не трехслойка была, там что-то вообще ужасное было. И надо было с этим что-то делать. Я посмотрел другие сервисы этого проекта. Ситуация там была местами лучше, но в целом очень далеко от того, где мы уже находимся на сегодняшний день. Очень много путаницы. Был какой-то common code, но он был сделан через submodule, git submodule. Не знаю, встречались ли вы с таким. Лично мне по итогу не очень понравилось.

И естественно я сразу начал общаться с TeamLead-ом. Я сказал, что так и так, есть разные подходы, давай посмотрим, попробуем улучшить конкретный сервис. Ну, не сильно это было принято, не всем понравилось то, что я предлагаю.

И вот тут уже начала появляться возможность проявить communication skills в полной мере. Павел как-то говорил на лекции, что если вы хотите двигать проект, но вы сейчас не находитесь в той позиции, которая позволяла бы это делать, то надо найти людей, которые вам помогут это сделать. В тот момент я начал искать этих людей. Не найдя отклика в команде – я начал искать вне команды.

Тогда у руля проекта был delivery manager. Я начал искать выходы на него. Спросил, с кем можно вообще пообщаться на проекте. Он меня свел с человеком, который формально исполнял обязанности архитектора, но в связи со спецификой проекта, в полной мере погрузиться в архитектуру ему не представлялось возможным. Я детали раскрывать не буду. Но можно было бы назвать его архитектором на тот момент. Назовем его TeamMember V.

Я вышел на него, рассказал ему свои идеи. Говорю, так и так, у меня есть такой экспириенс рабочий. Этот экспириенс выработан кровью и потом на предыдущем проекте. Он рабочий. Принес определенные плоды, успехи на прошлом проекте. Показал ему конкретно, о чем я говорю. Вот такие подходы можно применить и т.д.

Он говорит:

Вот отсюда начинается моя история на этом проекте. Ключевой момент – инициатива была поддержана. Назовем это фактором везения, потому что ситуации бывают абсолютно полярными.

На тот момент, кстати, когда я пообщался с TeamMember V, я начал говорить с менеджером о том, что мне нет смысла находиться в той команде, в которую я попал, потому что взгляды команды не соответствуют амбициям и опыту, с которыми я пришел. Абсолютно.

У меня был достаточно большой опыт разработки. Не только кодинга, но и построения сервисов. Я понимал, какие подходы более выигрышные, какие менее выигрышные. Я понимал, какая архитектура хорошо сложена. Если даже не всего проекта, то как минимум конкретного сервиса.

То, что я видел там, это был просто ужас. То есть, буквально очевидные моменты. В архитектуре солюшена там было что-то вроде двухслойки, даже не трехслойка, и все это было приправлено приличной порцией Code Smells. То есть, казалось бы, все знают трехслойку. Ну, пожалуйста, хотя бы её сделайте, но увы. И я не находил отклика на решение проблем с банальными вещами.

И еще, кстати, важный момент, что этот сервис, который разрабатывала эта команда, куда я пришел, не был еще даже на Production-е. То есть, он был на этапе разработки и тестирования. И речь про стейдж или прод на тот момент даже не шла. И объем этого сервиса был небольшой. Я даже предлагал, переписать этот сервис. Сделать его красиво. И соответственно получал отказ.

Например у ребят были серьезные проблемы и по REST архитектуре. Я спрашивал:

— Мы юзаем, REST?
— Да, юзаем.
— Почему здесь не по RESTу, почему здесь не по RESTу?

И не получал ответ.
То есть, код писался наобум. В двух словах – философия команды не совпадала с моей философией. Тем более я был уверен, что то, с чем я пришел, тут заработает, потому что продукт немного похож.

Я, понятное дело, не говорил:

"Вот смотри, TeamMember V. На нашем предыдущем проекте было 4 сервиса. Такой-то, такой-то, такой-то. Там был такой-то домен. Реализовывали мы его так."

Абсолютно абстрактно, c теоретическими выжимками. Я сказал, какие технологии мы применяли, описал их плюсы. Он с ними согласился.

Говорит:

Но был нюанс, что эта команда, в которую я попал, она немного была отстранена от “хотелок”. И это вызывало у меня еще больше вопросов. То есть, раз она отстранена от “хотелок”, то почему бы не сделать этот изолированный сервис красивым, не показать пример.

Короче, я пришел с предложением. Он говорит:

У нас на предыдущем проекте была практика Tech Talk. То есть, такие, технические внутрипроектные, межкомандные миты. Я сказал:

"Ну, наверное, мы это сделаем вот так. То есть, я проведу, например, какие-нибудь Tech Talks."

С чего мы начали? Первый Tech Talk был вообще по истории развития архитектур. То есть, какие вообще архитектуры бывают: MVC, Трехслойки, Ports and Adapters, Onion, Clean Architecture, вот это вот все. То есть, всю историю. Плюсы и минусы каждой. Пример каждой.

Потом был Tech Talk по DDD и по использованию MediatR. Если тут есть дотнет-девелоперы, то они понимает, о чем я говорю. То есть, на этом проекте он не использовался. А относительно Clean Architecture он очень красиво ложится на понятие Use Case. Вот.

То есть, вот эти все подходы и практики я рассказывал на двух Tech Talk. Я зашел с этого.

Он поддержал. Я сказал, что вот я готов сделать по такой-то, такой-то теме. Он говорит:

Туда были приглашены все BE-девелоперы. И по-моему, там даже FE девелоперы были. То есть, было очень много людей. Там, по-моему, человек 50 было. На такую аудиторию я никогда не рассказывал ничего. Конечно, было волнение. Но как-то справился. Рассказал, показал.

Были вопросы. Откровенного такого отрицания или непринятия не было. То есть, были какие-то уточняющие вопросы. На них без проблем отвечал. В общем была проведена серия вот таких митапов. И плюс на втором или на третьем Tech Talk, точно не помню. Я показал POC на примере какого-то микросервиса, как можно его построить на вот этих подходах. Ну, про которые мы немножко позже поговорим. Сейчас я просто называю какие-то эти подходы.

Я показал POC, как это всё может работать. Там же выяснилось, что не все понимали, как работает MediatR. Ну, для меня, как для DotNet девелопера, это было странно. Для меня это был очередной звоночек. Какой именно? Что, скорее всего, придется мне серьезно поработать ментором на этом проекте. Потому что, раз люди это не знают, значит надо все это внедрять в массы, рассказывать.

И так оно потом и было. У нас проект был на 100 человек на определенном этапе. У меня Slack просто “дымился” было около 80 контактов, чатов. То есть, практически с каждым человеком. В том числе и с FE девелоперами. Было очень весело в течение этого года.

В общем, показал POC, как это все работает. Учитывая то, что был Tech Talk по DDD, показал, что такое модель. Показал на примерах, что такое Rich model и Anemic model, плюсы и минусы. Как будем разрешать DDD Trilemma (выбираем два вот этих поинта из трех). Вот так вот у нас “летают” ивенты и т.д. Там же четко разграничил, что такое event и что такое command в рамках общения между сервисами через Message Broker. Потому что на тот момент это понимание не у всех было. В рамках POC как раз тоже это и показал.

В следующей части вы узнаете про создание System Team, роль Павла в ней и создание первого сервиса по новым правилам. Stay tuned!