Как разобраться в новой кодовой базе По просьбе https://t.me/MicroservicesThoughts/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 после такого появляется понимание - общего контекста и задачи сервиса - как устроены данные - как в коде реализованы основные сценарии, по каким компонентам они проходят - в каких местах находили баги И делитесь в комментах, если у вас другой подход:)