Планирование реинженеринга Проекта Э

October 24, 2022

В этом микропосте я решил рассказать, как я спланировал работы по реинженерингу Проекта Э.

Начал я с того, что с помощью одного из джунов построил граф эндпоинтов (как REST, так и RabbitMQ) микросервисов и зависимостей между ними. Каждому эндпоинту я на глаз присвоил "размер" - xs, s, m, l, xl. Для того, чтобы граф был более нагляден, я цветом закодировал тип эндпоинта (зелёных - REST, синий - RabbitMQ RPC, красный - RabbitMQ Event), а насыщенностью - его размер.

В итоге получилась вот такая иллюстрация термина "Distributed Big Ball of Mud" (по клику открывается 2-мегабайтная картинка в большом разрешении):

project e small

Этот граф в очередной раз подтверждает тезис "Если вы не можете сделать модульный монолит, то микросервисы вам не помогут".

Реинженеринг я в итоге решил делать в том порядке, в котором собираслся изначально - "снаружи" (микросервисы, от которых никто не зависит) "внутрь" (микросервисы, от которых все зависят). Я полагаю, это снизит вероятность тотального факапа на проде.

Далее я исходил из следующих идеалов:

  1. Один сервис переписывает один разработчик
  2. Один разработчик минимально скачет между сервисами
  3. Одну сущность внутри МС переписывает один разработчик
  4. Сначала переписываются рид-онли эндпоинты, потом эндпоинты удаления, потом эндпоинты обновления, потом эндпоинты создания

Первые три идеала призваны минимизировать конфликты между изменениями разработчиков и переключение контекста, и тем самым минимизировать издержки на групповую разработку. Последний - минимизировать вероятность порчи данных и проблем с интеграцией разных стеков через БД.

Но полностью достичь этих идеалов не получилось, конечно же.

В итоге у меня получилось, что реинженеринг удастся выполнить за 7 спринтов (при первичной грубой оценки в 8):

  1. Спринт 1
    1. Разработчик 1 полностью переписывает МС 1
    2. Разработчик 2 полностью переписывает МС 2
    3. Разработчик 3 реализует сложный метод из МС 3, требуемый для МС 2
  2. Спринт 2
    1. Разработчик 1 подключается к МС 3
    2. Разработчик 2 продолжает МС 3 (вместе они должны его закончить)
    3. Разработчик 3 начинает реализует сложный метод из МС 5, требуемый для МС 3
  3. Спринт 3
    1. Все разработчики занимаются разными частями МС 4
  4. Спринт 4
    1. Разработчик 1 делает первый метод из МС 6 и ещё несколько методов из МС 5
    2. Разработчики 2 и 3 доделывают МС 4
  5. Спринт 5
    1. Разработчик 1 продолжает делать МС 5
    2. Разработчики 2 и 3 подключаются к МС 6
  6. Спринт 6
    1. Разработчик 1 доделывает МС 5
    2. Разработчики 2 и 3 доделывают МС 6
  7. Спринт 7
    1. Все разработчики делают разные части МС 7

Работать мы будем по TDD:

  1. Сначала пишутся тесты, который по HTTP или RabbitMQ работает с бэком на дотнете
  2. Затем тесты перенаправляются на новый бэк и они снова делаются зелёные

Общий жизненный цикл каждого эндпоинта следующий:

  1. Эндпоинт реализуется в фича-ветке
  2. Затем он мёржится в ветку re-integration и деплоится на дев стенд
  3. Баги фиксятся в фича-ветке
  4. После приёмки QA, фича ветка мёржится в develop и деплоится на стейдж
  5. В конце каждого спринта, все коммиты, которые были в начале спринта в devlop мёржатся в master и деплоятся на прод

Первый спринт мы формально стартуем с понедельника, так что должны закончить всё к концу февраля.