Открыть незнакомый репозиторий и сразу лезть в `src/` — надёжный способ потратить полдня и ничего не понять. Я сначала ищу точку входа в продукт: как поднять локально, куда стучится прод, что считается «здоровьем» сервиса, где лежат миграции. README врёт чаще, чем хочется, но даже кривой README показывает, о чём авторы думали в момент написания.
Дальше смотрю структуру верхнего уровня и сознательно игнорирую красивые папки с именем `utils` и `helpers`. Мне нужны границы: API, воркеры, очереди, конфиг, клиенты к внешним системам. Если есть `docker-compose` — поднимаю его раньше, чем начинаю читать бизнес-логику. Живой `/health` и успешный смоук экономят час абстрактных рассуждений у схемы.
Сначала карта, потом детали
На практике я выбираю один вертикальный срез. Например, «создать заказ» — от хендлера до базы и обратно к ответу клиенту. Не пытаюсь объять весь каталог в первый день. По пути записываю имена сущностей и странные термины в домене: у каждого проекта свой словарь, и без него код выглядит враждебнее, чем есть на самом деле.
Тесты — недооценённая карта местности. Даже кривые интеграционные тесты показывают happy path и то, чего авторы боялись. Если тестов почти нет, ищу логи, метрики и старые инцидент-разборы: по ним видно реальные сценарии, а не те, что нарисовали в Confluence три года назад и забыли обновить. Отдельно смотрю историю git по горячим файлам: кто трогал модуль и какие были инцидент-фиксы. Blame часто объясняет костыли лучше документации. Выписываю два-три таких места, чтобы случайно не «упростить» то, на чём держится прод.
Осторожно с рефакторингом «заодно». Пока вы не понимаете инварианты, любое «улучшение читаемости» — лотерея. Я сначала добавляю наблюдаемость или характеризационный тест на текущее поведение, потом уже трогаю структуру. Скучно, зато потом не откатываешь пятничный релиз из-за «очевидной» правки.
Что не делать в первый день
Если репозиторий огромный, договариваюсь с кем-то, кто жил в нём дольше месяца. Десять минут разговора экономят день блужданий. Вопросы конкретные: где лежат фичефлаги, что нельзя трогать без дежурного, какой кусок сейчас горит, где самые тонкие места с деньгами и правами доступа. Если сервис общается с соседями, рисую грубый граф вызовов: синхронно или через очередь, где таймауты. Без картинки легко сломать чужой контракт, думая, что меняете только внутренности.
Через пару часов у меня обычно есть черновая карта: вход, данные, внешние зависимости, зоны риска, способ локального запуска. Этого хватает, чтобы сделать первую маленькую задачу без ощущения, что я в чужом подвале без фонарика. Карту потом уточняю — она не обязана быть полной с первого дня.
И ещё: не стыдно гуглить внутренние аббревиатуры и спрашивать в чате «что такое X в этом сервисе». Притворство, будто вы всё схватили с лёту, только замедляет нормальное чтение и плодит странные PR.