Планирование реинженеринга Проекта Э
October 24, 2022
В этом микропосте я решил рассказать, как я спланировал работы по реинженерингу Проекта Э.
Начал я с того, что с помощью одного из джунов построил граф эндпоинтов (как REST, так и RabbitMQ) микросервисов и зависимостей между ними. Каждому эндпоинту я на глаз присвоил "размер" - xs, s, m, l, xl. Для того, чтобы граф был более нагляден, я цветом закодировал тип эндпоинта (зелёных - REST, синий - RabbitMQ RPC, красный - RabbitMQ Event), а насыщенностью - его размер.
В итоге получилась вот такая иллюстрация термина "Distributed Big Ball of Mud" (по клику открывается 2-мегабайтная картинка в большом разрешении):
Этот граф в очередной раз подтверждает тезис "Если вы не можете сделать модульный монолит, то микросервисы вам не помогут".
Реинженеринг я в итоге решил делать в том порядке, в котором собираслся изначально - "снаружи" (микросервисы, от которых никто не зависит) "внутрь" (микросервисы, от которых все зависят). Я полагаю, это снизит вероятность тотального факапа на проде.
Далее я исходил из следующих идеалов:
- Один сервис переписывает один разработчик
- Один разработчик минимально скачет между сервисами
- Одну сущность внутри МС переписывает один разработчик
- Сначала переписываются рид-онли эндпоинты, потом эндпоинты удаления, потом эндпоинты обновления, потом эндпоинты создания
Первые три идеала призваны минимизировать конфликты между изменениями разработчиков и переключение контекста, и тем самым минимизировать издержки на групповую разработку. Последний - минимизировать вероятность порчи данных и проблем с интеграцией разных стеков через БД.
Но полностью достичь этих идеалов не получилось, конечно же.
В итоге у меня получилось, что реинженеринг удастся выполнить за 7 спринтов (при первичной грубой оценки в 8):
- Спринт 1
- Разработчик 1 полностью переписывает МС 1
- Разработчик 2 полностью переписывает МС 2
- Разработчик 3 реализует сложный метод из МС 3, требуемый для МС 2
- Спринт 2
- Разработчик 1 подключается к МС 3
- Разработчик 2 продолжает МС 3 (вместе они должны его закончить)
- Разработчик 3 начинает реализует сложный метод из МС 5, требуемый для МС 3
- Спринт 3
- Все разработчики занимаются разными частями МС 4
- Спринт 4
- Разработчик 1 делает первый метод из МС 6 и ещё несколько методов из МС 5
- Разработчики 2 и 3 доделывают МС 4
- Спринт 5
- Разработчик 1 продолжает делать МС 5
- Разработчики 2 и 3 подключаются к МС 6
- Спринт 6
- Разработчик 1 доделывает МС 5
- Разработчики 2 и 3 доделывают МС 6
- Спринт 7
- Все разработчики делают разные части МС 7
Работать мы будем по TDD:
- Сначала пишутся тесты, который по HTTP или RabbitMQ работает с бэком на дотнете
- Затем тесты перенаправляются на новый бэк и они снова делаются зелёные
Общий жизненный цикл каждого эндпоинта следующий:
- Эндпоинт реализуется в фича-ветке
- Затем он мёржится в ветку re-integration и деплоится на дев стенд
- Баги фиксятся в фича-ветке
- После приёмки QA, фича ветка мёржится в develop и деплоится на стейдж
- В конце каждого спринта, все коммиты, которые были в начале спринта в devlop мёржатся в master и деплоятся на прод
Первый спринт мы формально стартуем с понедельника, так что должны закончить всё к концу февраля.