# Как разобраться в чужом коде за первую неделю

> Как разобраться в чужом коде, не сломав продакшн: запуск локально, карта проекта, поиск того, что реально используется, и первые безопасные правки.

Published: 2025-04-10 · Source: https://subxcat.com/ru/articles/messy-codebase-first-week · Author: SUBXCAT

Тебе достался проект: его писал фрилансер, агентство или ИИ-ассистент под чьим-то руководством, документации нет, а пользователи уже есть. Разобраться в чужом коде за неделю реально, если не пытаться прочитать его целиком. Читать весь код подряд — всё равно что учить город по справочнику улиц. Надо пройти по нему пешком.

Главное правило первой недели: ты ничего не улучшаешь. Ты смотришь, записываешь и запускаешь. Правки в продакшн — только если что-то горит.

## День 1: запустить локально

Пока проект не запускается у тебя на машине, всё остальное — гадание. Склонируй репозиторий и попробуй поднять его так, как поднял бы новичок. Каждый шаг, на котором ты застрял, записывай: какой версии нужен Node или Python, какие переменные окружения, откуда взять ключи, какую базу создать.

Две вещи важны сразу:

- Локальная копия не должна смотреть в боевую базу. Если в `.env` лежит адрес продакшн-базы — замени на локальную или тестовую до первого запуска.
- Почта, оплата и прочие внешние сервисы в локальном запуске должны быть в тестовом режиме или выключены. Иначе одна кнопка «отправить» уйдёт настоящим людям.

К концу дня у тебя должен быть работающий проект и черновик инструкции, как его запустить. Это уже больше, чем было.

## День 2: нарисовать карту

Теперь сверху вниз. Открой структуру папок и ответь на вопросы:

- где точка входа: что запускается первым;
- где маршруты: какие страницы и какие эндпоинты API существуют;
- где модель данных: таблицы, схемы, миграции;
- какие внешние сервисы вызываются и откуда.

Хороший приём — выписать список таблиц в базе и рядом с каждой отметить, какие файлы её читают и пишут. Поиск по проекту (`grep -rn "orders"` или поиск в редакторе) даст это быстрее, чем чтение. В итоге получится грубая схема на одну страницу. Она будет неточной, и это нормально — ты её уточнишь.

ИИ-ассистент здесь полезен: попроси его описать, что делает папка или модуль. Но проверяй каждое утверждение по коду — он уверенно рассказывает и то, чего там нет.

## День 3: пройти по главным сценариям

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

На этом шаге становится понятно, какие части живые, а какие лежат рядом просто так. Записывай странности: проверка прав только в интерфейсе, цена, которая приходит из браузера, два почти одинаковых обработчика. Чинить пока не надо — только список.

## День 4: найти то, что реально используется

В проектах, которые росли быстро, заметная часть кода не используется: старые страницы, брошенные эксперименты, три версии одного компонента. Чтобы отличить живое от мёртвого:

- посмотри логи сервера и аналитику: какие маршруты вызываются, а какие нет;
- поищи использования функции или компонента по всему проекту;
- проверь историю файла в git: когда его трогали последний раз и зачем;
- спроси тех, кто был до тебя, если они на связи.

Ничего не удаляй. Просто пометь в своих заметках: «похоже, не используется, проверить».

## День 5: первые безопасные правки

Если до этого не было, настрой отдельное тестовое окружение, куда можно выкатить изменение и посмотреть на него, не трогая пользователей. Потом сделай одну маленькую, заведомо безопасную правку — поправь опечатку в тексте или обнови комментарий — и проведи её через весь путь до продакшна.

Цель не правка, а проверка процесса: как собирается проект, как выкатывается, как откатить, если что. Лучше узнать, что деплой занимает сорок минут и требует ручного шага, на опечатке, чем на срочном исправлении в пятницу вечером.

## Итог: что значит разобраться в чужом коде

Работающая локальная копия, инструкция по запуску, карта проекта на одну страницу, список главных сценариев с путями в коде, список подозрительных мест и проверенный путь выкатки. Это и есть основа для README и для плана, что чинить первым.

## Коротко

- Разобраться в чужом коде быстрее через запуск и сценарии, чем через чтение файлов подряд.
- Первым делом отключи локальную копию от боевой базы и боевых сервисов.
- Нарисуй карту: точка входа, маршруты, таблицы, внешние сервисы.
- Живой код отличай от мёртвого по логам, поиску использований и истории git, но пока ничего не удаляй.
- Первая правка должна проверять процесс выкатки, а не код.

Если нужен второй взгляд на доставшийся проект, SUBXCAT делает такой разбор вместе с командой.