Как разобраться в новой кодовой базе

По просьбе https://t.me/fedkin_thinking/213?comment=2217

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

Думаю с опытом у каждого вырабатывается свой подход, поэтому ниже субъективщина, как разбираюсь в новом сервисе я (зачастую неосознанно)

1. Посмотреть что снаружи

Обычно сервис живет в рамках какого-то bounded context-а, где он закрывает определенную задачу

Например:
- есть pricing-service
- выясняем, что он живет в рамках контекста checkout (оформление заказа). Там есть checkout-service, cart-service, pricing-service
- pricing-service закрывает собой задачу ценообразования: хранит в себе правила расчета итоговой цены с учетом скидок, промокодов и доставки

Артефакты:
- контекст
- задача, которую закрывает сервис

2. Модель данных

На этом этапе хочется понять, какие основные сущности есть внутри сервиса, и какие между ними связи

Здесь удобно сгенерить ER-диаграмму по сущностям БД (делается за пару кликов в ide/dbeaver/...), и на основе нее подопрашивать коллег

Артефакты:
- ER диаграмма

3. Инварианты

Самые основные бизнес правила, которые в себе инкапсулирует сервис. Например, в pricing-service могло бы быть что-то такое:
- Итоговая цена = базовая цена + надбавки – скидки
- Итоговая цена всегда неотрицательна

Артефакты:
- Список инвариантов

4. Посмотреть на основные сценарии

И только тут начинаем детально копаться в коде

Зачастую есть 4-5 основных апишек, благодаря которым происходит вся основная работа

Нужно их взять и детально раскрутить, как по коду происходят вызовы: что вызывается и в какой последовательности

Только ради бога в 2025 не занимайтесь этим полностью вручную, когда есть Cursor и ask mode))

Артефакты:
- Основные сценарии и их цепочки вызовов

5. Разобрать пару баг репортов

Неочевидный совет, но лично мне это давало наибольший профит в понимании, как работает сервис. Мейби потому что у тебя есть конкретная цель, и чтобы ее достичь надо понять "а как должно работать", "а как сейчас работает", "а почему так работает" и т.д

Также багрепорты зачастую подсвечивают херовые места в коде (без них скорее всего баг бы не произошел)

---

Overall после такого появляется понимание
- общего контекста и задачи сервиса
- как устроены данные
- как в коде реализованы основные сценарии, по каким компонентам они проходят
- в каких местах находили баги

И делитесь в комментах, если у вас другой подход:)