Ссылка на репозиторий ещё не говорит, что нужно проверить. В нём могут быть десятки файлов, устаревшая ветка и несколько незаконченных функций. Чем точнее вы обозначите задачу, тем быстрее разговор перейдёт к вашим решениям и коду.
Выберите часть проекта для первого разбора
Для начала подойдёт один сценарий: поиск, форма регистрации, список с фильтрами или обработка ошибки API. Нужен законченный фрагмент, в котором можно проследить действие пользователя и результат. Необязательно сначала переписывать всё приложение или доводить каждую кнопку до идеала.
Если есть Git-история, подготовьте отдельную ветку или pull request. Укажите базовую ветку, чтобы проверяющий видел ваше изменение. Для общего знакомства с проектом можно прислать репозиторий целиком, но всё равно стоит назвать точку входа: экран, URL, файл и сценарий.
Небольшие самостоятельные изменения проще обсуждать по существу. Такой подход описан и в рекомендациях Google о размере изменений. Для учебного проекта из этого не следует ограничение на точное число строк. Лучше спросить себя, можно ли объяснить назначение выбранной части одним абзацем.
Проверьте запуск по собственной инструкции
Откройте чистую копию репозитория в отдельной папке и выполните команды из README. Не используйте незакоммиченный файл из рабочей директории. Эта простая проверка часто обнаруживает пропущенную переменную окружения, локальный путь к файлу или неочевидный порядок запуска.
- Укажите нужную версию Node.js и пакетный менеджер.
- Добавьте команды установки, запуска и существующих проверок.
- Перечислите переменные в .env.example с безопасными примерами вместо реальных ключей.
- Если нужна база или другой сервис, объясните, как поднять тестовое окружение.
- Опишите тестовые данные и известные ограничения: какой сценарий можно пройти, а какой пока не реализован.
Не публикуйте пароли, токены и данные клиентов ради удобного запуска. Для учебного примера подготовьте тестовые значения и данные. В справке GitHub о README отдельно перечислено, какую информацию стоит дать человеку, который впервые открывает проект.
Напишите, что должно происходить и где вы сомневаетесь
В описании достаточно задачи, способа проверки и нескольких вопросов. Удобный пример сообщения: «Сделал поиск товаров. Запуск: команды в README, экран /catalog. При быстром вводе показывается ответ на последнюю строку, старый запрос отменяется. Не уверен, правильно ли разделил состояние формы и состояние запроса. Особенно прошу посмотреть search.ts и CatalogPage». Это условный пример, а не история конкретного ученика.
Если уже есть ошибка, укажите шаги воспроизведения и ожидаемый результат. Разделяйте наблюдение и догадку. «После второго запроса появляется первый результат» описывает факт. «React кеширует неправильный ответ» пока только предположение, которое может увести разбор в сторону.
Не прячьте неудачные попытки, если они помогают понять решение. Коротко объясните, что пробовали и почему отказались от варианта. Подобную структуру - что меняется и зачем - предлагает руководство Google по описанию изменений. Пример сообщения выше составлен для этой статьи.
Что обычно стоит проверить самому
Запустите существующие тесты, линтер и проверку типов, если они есть в проекте. Затем пройдите сценарий руками. Зелёные тесты не покажут ошибку, на которую проверки ещё не написаны, поэтому полезно подготовить и пример неудачного исхода: пустой ответ, отказ API, повторный клик или быстрый переход между экранами.
На frontend посмотрите загрузку, ошибку и восстановление после неё. На backend - входные данные, статусы ответа и отсутствие лишних подробностей во внешней ошибке. Для конкретных примеров есть разборы запросов в React и ошибок Node.js API.
Как работать с замечаниями после ревью
Сначала найдите замечания, которые влияют на поведение: потеря данных, неверный ответ, недоступная форма. Затем обсуждайте структуру и читаемость. Если замечание непонятно, попросите показать пример, на котором текущее решение ломается или становится неудобным.
После правки повторите исходный сценарий. Если была ошибка, добавьте проверку, которая отличает исправленный вариант от прежнего. Коротко напишите, что изменили и как проверили. Исправить строчку по образцу можно быстро, но для следующей задачи важнее понять, почему она была неверной.
Если хочется разобрать проект вместе с ментором, начните с формата занятий и условий работы. В сообщении можно использовать описание из этой статьи: задача, ссылка, запуск и вопрос. Написать о проекте.