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

Далее – коммуникация. История коммуникации получилась очень обширная. То есть мне пришлось буквально пообщаться с каждым бэкэнд-девелопером. Потому что было небольшое правило на старте - во все репозитории новых микросервисов я был добавлен как Code Owner в GitHub. Это значит, что я был обязательным ревьюером кода всех этих репозиториев. Да, я был вот этим боттлнеком, который на старте пропускал через себя все PR. У меня, честно, голова просто гудела. В этот момент, даже немножко раньше, я уже забыл, что такое кодинг. Я уже не кодил. Зачем я это делал? Мне нужно было тем самым заменторить людей, скажем так приучить к новым подходам.

Чтобы не потерять скилл кодить, приходилось подмечать в PR-ах какие-то интересные моменты. Где-то кто-то что-то вычитал, применил в PR-е, я увидел – запомнил. То есть старался этот момент не упускать. Когда, в принципе, ревьюишь код, если ты даже его не пишешь, хотя бы его видишь, то сильно скилл не потеряется. Ну, если ты осознанно смотришь PR, прям вникаешь.

Ревью было очень жесткое. Да, был какой-то момент, что люди даже в чатах шутили, типа, удалось сегодня через Пашу пройти, либо нет;) Соблюдение всех норм. Как построена модель, какие были объекты, а почему именно этот был объект. Я старался вникать в бизнес. Просмотр большинства PR-ов вытекали в звонок, потому что не всегда комментариями в PR-е можно пояснить как надо делать. Ну и вопросы по бизнесу у меня тоже возникали. Если девелопер не мог ответить, звали тимлида, не справлялся и он - звали Product Owner-а.

Единственное, что я, может, не все слои приложения в PR-е так дотошно ревьюил. Я определил себе определенную градацию. Иначе бы я просто сгорел. Для меня основа была Domain, Application и наверное API (исполняемые прожекты). Почему API? Потому что там я смотрел за контрактами сервиса, за соблюдением REST: какие статус-коды, какой URL, соответствует ли он RMM (Richardson Maturity Model) и т.д.

Процесс такого глобального код-ревью, имеется в виду ревью большого количества человек, на практике оказался задачей не из легких. Очень много раз приходилось объяснять одно и то же по много раз, приводить пруфы, примеры, best practice, это всё такое. Но в итоге добивался своего, ребята потихоньку начинали понимать, что я от них хочу. Овертаймы в этот период стали обычной практикой. И да, естественно они были за мой счет, на что не пойдешь ради общего блага;)

Но и конечно не всегда все было гладко. Учитывая большое число людей на проекте были люди, пару человек, но были, которые буквально не хотели делать даже то, на что вроде было получено согласие от них же, или упорно не понимали что от них хотят. Не знаю почему, может не признавали авторитет;) Может назло. Но и как результат я каким-то непонятным для меня образом выруливал на “360”. Не знаю в курсе вы или нет, что это такое. Но в целом психологически не очень приятная штука, особенно, когда стараешься на благо проекта, и по итогу получается вот такое. Но по итогу все разрулилось, я оказался прав и все вернулось “на круги своя”. Я считаю, что может и хорошо, что я прошел через это. Это точно хороший опыт для коммуникейшин скиллов.

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

Ну, смотрите. Рано или поздно ты захочешь покодить. Рано или поздно коммуникация из вот такой горячей фазы немного спадает. Почему спадает? По объективным причинам. Люди учатся. Ну или потому что можно просто сгореть от такого темпа, и ты сам будешь сводить коммуникации на минимум. Или по другим причинам, не зависящим от нас, разработчиков.

Ещё кстати важный момент. В каждой команде нужно найти точку опоры. Я бы его прям записал красными большими буквами. Иначе будет сложно, смотрите выше – сгорите. То есть, я на каком-то этапе старался находить такие точки опоры. Где-то это был Team Lead. В большинстве команд это был Team Lead. Почему? Наверное, ввиду какого-то опыта скорее всего, большего понимания целей, которых я добивался. То есть, Team Lead быстрее понимает/принимает все эти концепции.

С девелоперами иногда было сложнее. Но бывало и обратное. Где-то я находил точку опоры именно на уровне девелопера, например саксессора Team Lead'а. Есть у нас в компании и собственно на проекте практика саксессоров. Обычно это BE-девелопер. И вот он уже потом доносил какие-то идеи до остальной части команды.

Когда приходило время снимать с какого-нибудь репозитория микросервиса политику Code Owner-а в моем лице, я с чистой совестью оставлял вместо себя эту “точку опоры”. И уже он нес эту культуру дальше к себе в команду. Иногда я всё же просматривал их репозиторий, если находил там какие-то отклонения, то писал в чат команды, что тут и тут надо поправить. Получал обратную связь: “ОК, в ближайшее время поправим”.

На пике весь проект был около 100 человек. Это было 10 команд, включая отдельную команду Automation Team, автоматизаторы. Именно команд разработки было 9. Включая нашу, System Team. То есть объем коммуникации был просто сумасшедший. Моя команда, 4-5 человек, менеджмент и плюс еще 8 команд.

Я официально был Team Lead. То есть в своей команде я ставил задачи именно такого инфраструктурного уровня, например, разработать common функционал для мониторинга сервисов, разработать wrapper для Message Broker, какие-нибудь common middleware и т.д. Но это помимо того, что мы отвечали за Core (тот же сервис аутентификации, на самом деле он не только за аутентификацию отвечал, и назывался он немного иначе, и поэтому он продолжал расти по-немногу) и некоторые Generic микросервисы из домена. Разрабатывали их, полностью сами инкорпорировали.

Но действительно много capacity уходило на common функционал. Например, я был на каком-то мите с другой командой, увидел у них там какие-то моменты, которые по хорошему бы вынести в common. Все, берем это в наш Backlog и это выносится в common. Либо если мои ребята заняты, то я озвучиваю этой другой команде, договариваюсь с тимлидом, примерно смотрим, когда, в какой спринт мы сможем внести эту задачу, приоритизируем ее.

По объективным причинам она с более низким приоритетом, чем какие-то горящие фичи. Потом я в общих чатах объявлял, что вот такой-то nuget был разработан, лежит в Feed-е, пользуйтесь. Ну и смотрел потом, корректно ли его использовали, потому что очень много раз бывало, что какой-то важный функционал разработанный нашей командой не совсем корректно использовался. Тогда приходилось проводить Tech Talks дополнительные, писать документацию и всё такое. Плюс наша команда потихоньку распиливала так называемый core-сабмодуль в git из старого кода на отдельные nuget пакеты.

Common пакеты были скажем так поделены на специальные категории, в зависимости от того, для какого Layer-а из микросервиса они могут быть зависимостями. Какие-то могут быть зависимостями даже для Domain Layer, это как правило какие-то языковые utils, либо framework sdk utils. Какие-то могут быть зависимостями для Application Layer, такие как абстракция для какого-то third party, ну а реализация для этой абстракции соответственно могла быть зависимостью только для Infrastructure или API Layers. Ну и какие-то common пакеты были исключительно для API Layer, например wrapper для Message Broker-а.

У меня кстати была еще идея реализовать архитектурные тесты. А потом подумал, и так все уже всё знают, не буду.

В классической пирамиде тестирования у нас что? End-to-end, integration и unit-тесты. Основание пирамиде — unit-тесты, потом интеграционные тесты, потом end-to-end-тесты. У нас девелоперы реализовывали unit и integration. Integration включали в себя интеграцию компонентов всех уровней и плюс API-тесты. Естественно эта интеграция включала в себя коммуникацию текущего сервиса с другими микросервисами. Мы добивались этого путем развертывания тестового окружения в Docker, где каждый микросервис был представлен отдельным контейнером соответственно.

Ну а end-to-end тестами уже занимались QA и AQA.

А я говорю про архитектурные тесты. Они вроде как не входят в стандартную пирамиду (но могу ошибаться). Они позволяют заметить, не притянул ли кто-то лишний референс в прожект. То есть запрет на использование какой-то зависимости был в виде меня. Да, вот такой своего рода архитектурный тест был;)

Как говорил выше, в какой-то момент я был боттлнеком, и мне было важно, пока я был в этом “статусе”, обучить команды. Иначе я был бы постоянным боттлнеком. Я этого не хотел. Потому что выгорание там рано или поздно наступило бы. Десятки PR-ов через меня проходили.

За процессы внутри моей команды, да, конечно, я отвечал. За какие-то верхнеуровневые моменты на всем проекте, нет. На уровне всего проекта я (вместе с TPO) отвечал скорее за рефакторинг всего домена. Мне главное, чтобы эти верхнеуровневые процессы учитывали развитие продукта с точки зрения его технического состояния.

Project-менеджеров у нас нету. У нас структура менеджмента следующая: собственно клиент, Product Manager, Product Owners, Delivery Manager, Technical Product Owner, QA Owner, BE Owner, Team Leads. Ну и все проектные процессы выстраивались этим составом, ну еще при участии DevOps естественно. Ну, кстати, на правах Team Lead-а System Team или BE Owner сейчас, я могу посещать Scrum-ивенты других команд по необходимости.

На очереди предпоследняя часть нашего цикла. В ней Павел порассуждает о том, какие качества помогли ему драйвить такие масштабные перемены.