Ru

Ревью и тестирование новой фичи (code review + логика + use cases + регрессия)

ВВОДНЫЕ

Разбери $ARGUMENTS и контекст диалога, чтобы извлечь то, что дано; всё, что не дано явно, определи сам по коду и требованиям — не жди, пока пользователь перечислит это за тебя:

• Требования (YouTrack issue) — ссылка вида https://youtrack.example.com/issue/..., если есть в аргументах или в диалоге.
• Требования (файл в репозитории) — путь вида docs/qa/requirements/**/requirements.md, если есть.
• Ветка / диапазон коммитов для ревью — если не указано, бери текущую ветку относительно main/dev.
• Затронутый функционал / модуль(и) — опциональная подсказка; не ограничивайся ею, найди все реально затронутые модули сам (шаг 2).
• Смежные интеграции, которые нельзя ломать — опциональная подсказка; дополни собственным анализом зависимостей.
• URL/команда для локального запуска UI — если не указано, определи сам по README/package.json/docker-compose соответствующего сервиса.

Если из всех вводных не дано вообще ничего (ни ссылки на issue, ни файла требований, ни ветки) — прежде чем начинать полноценное ревью, кратко уточни у пользователя хотя бы один источник требований; без источника требований пункт 3 (сверка "требование → реализация") невозможен.

ЗАДАЧА

В репозитории были изменения — разработчик попытался реализовать новую(ые) фичу(и). Список затронутого функционала/модулей/сервисов/смежных интеграций в вводных может быть неполным или отсутствовать вовсе — не полагайся только на него, самостоятельно найди ВСЕ фактически затронутые модули, сервисы и функции по факту изменений в коде (см. шаг 2) и дополни/скорректируй то, что указано в подсказке.

1. Изучи требования: открой и прочитай issue по ссылке и (если указан) файл requirements.md. Зафиксируй список функциональных и нефункциональных требований, acceptance criteria и явных ограничений/edge cases, упомянутых в задаче.

2. Самостоятельно найди все затронутые модули/сервисы/функции — не жди, пока их перечислит пользователь:

   • Посмотри git log/diff по указанной ветке относительно базовой ветки (main/dev) и составь полный список изменённых файлов.
   • Для каждого изменённого файла определи, к какому сервису/модулю/ пакету он относится (в монорепе — конкретный сервис в services/*, конкретный фронтенд/пакет и т.д.).
   • Пройди "на один уровень вглубь": какие функции/классы/эндпоинты/ обработчики событий реально изменены или добавлены (не только имена файлов) — построй список конкретных точек входа (API-эндпоинты, обработчики webhook, консьюмеры очередей, cron-джобы, UI-компоненты/страницы).
   • Найди вызывающий и потребляющий код: кто вызывает изменённые функции/ эндпоинты и кто зависит от изменённых контрактов данных (grep по использованию, поиск импортов/ссылок) — это и есть кандидаты на регрессию, даже если они не были явно упомянуты в требованиях.
   • Зафиксируй итоговый список затронутых модулей/сервисов/функций — он используется во всех последующих шагах вместо/в дополнение к подсказке из "ВВОДНЫЕ".

3. Сопоставь требования и реализацию:

   • Каждое требование из issue/requirements.md — реализовано полностью, частично или не реализовано? Укажи конкретно, каких пунктов не хватает.
   • Есть ли расхождения между документацией/требованиями и фактическим поведением кода?
   • Есть ли скрытые допущения разработчика, которые не были явно оговорены в требованиях?

4. Проведи code review изменений (по полному списку модулей/файлов из шага 2, а не только по тем, что упомянуты в подсказке):

   • Корректность логики (граничные условия, обработка ошибок, race conditions, идемпотентность, повторные попытки/ретраи, транзакционность там, где это применимо).
   • Валидация входных данных и защита от некорректных/вредоносных данных (в т.ч. типовые уязвимости OWASP: инъекции, XSS, небезопасная десериализация и т.п., если применимо).
   • Логирование и наблюдаемость: достаточно ли логов для диагностики в проде, нет ли утечки чувствительных данных в логи.
   • Конфигурация/секреты: не захардкожены ли значения, которые должны быть конфигурируемыми (URL, токены, ключи, feature-флаги).
   • Совместимость со стилем и архитектурой существующего кода в модуле/ сервисе.
   • Наличие и адекватность тестов (unit/integration) на новую логику; чего не хватает.
   • Миграции БД (если есть) — обратимость, безопасность для продакшена, отсутствие блокировок на больших таблицах.

5. Проверь use cases на нелогичные моменты и несостыковки:

   • Пройди по всем сценариям использования (счастливый путь + альтернативные ветки) и проверь, нет ли противоречий между шагами.
   • Проверь граничные/крайние случаи: пустые значения, дубликаты, конкурентные запросы, повторная обработка одного и того же события, отсутствие сети/недоступность внешнего сервиса, некорректные форматы данных, устаревшие/просроченные данные.
   • Проверь мультиаккаунт/мультитенантность (если применимо к модулю) — нет ли утечки данных между аккаунтами/пользователями/проектами.
   • Проверь идемпотентность обработчиков webhook/событий (если применимо) — не создаётся ли дублирующаяся сущность при повторном получении события.

6. Проверь регрессию (по полному списку модулей/сервисов/интеграций из шага 2, включая те, что явно не были упомянуты в вводных, но зависят от изменённого кода):

   • Не сломан ли существующий функционал затронутых модулей и смежные интеграции.
   • Проверь обратную совместимость API/контрактов данных, если они менялись.
   • Если есть автотесты — прогони их и зафиксируй результат; если тестов нет — явно это укажи как риск.

7. Проверь UI, если изменения затрагивают фронтенд/интерфейс (страницы, компоненты, формы, виджеты, боты с UI-подобным сценарием — например диалоги телеграм-бота):

   • Подними приложение локально (используй URL/команду из вводных; если не указано — определи команду запуска сам по README/package.json/ docker-compose соответствующего сервиса) и открой затронутые экраны в браузере (или пройди сценарий бота вживую).
   • Не ограничивайся статическим чтением кода компонентов — реально пройди фичу руками: заполни формы, нажми кнопки, отправь сообщения боту и т.д.
   • Проверь golden path (основной сценарий из требований) и как минимум 2-3 граничных сценария (пустые/невалидные данные, повторный ввод, отмена действия, потеря соединения).
   • Проверь, что не появилось визуальных/поведенческих регрессий в соседних экранах/шагах флоу, которые не менялись напрямую, но могли быть задеты (общие компоненты, layout, состояние формы, роутинг).
   • Проверь состояния загрузки/ошибок/пустых данных (loading/error/empty states), если применимо.
   • Если UI поднять не удалось (нет окружения, нет доступа, headless- среда) — явно укажи это в отчёте как ограничение проверки, не выдавай статическое чтение кода за подтверждённую проверку UI.

8. Оцени готовность к продакшену (enterprise / best practice / prod-ready):

   • Обработка ошибок и graceful degradation при сбое внешних сервисов.
   • Производительность: нет ли N+1 запросов, лишних синхронных вызовов в горячем пути.
   • Безопасность: аутентификация/авторизация на новых эндпоинтах, ограничение доступа.
   • Мониторинг/алертинг: возможно ли отследить сбой этой фичи в проде.
   • Документация: обновлена ли документация/README/требования под фактическую реализацию.

РЕЗУЛЬТАТ (формат ответа)

1. Краткое резюме: готова ли фича к релизу (да / да с замечаниями / нет).
2. Список фактически затронутых модулей/сервисов/функций/точек входа, найденный самостоятельно на шаге 2 (в т.ч. те, что не были указаны в подсказке).
3. Таблица соответствия "требование → статус реализации → комментарий".
4. Список найденных проблем, разбитый по категориям: Критично / Важно / Незначительно — для каждой проблемы: файл:строка, описание, конкретный сценарий воспроизведения, рекомендация по исправлению.
5. Список найденных нестыковок в use cases (если есть).
6. Результат проверки UI: что именно проверено вживую (шаги, скриншоты/ описание), какие найдены визуальные/поведенческие проблемы, было ли ограничение по проверке (если UI не поднимался — явно указать это).
7. Результат проверки регрессии (что проверено, что сломано, что не покрыто тестами).
8. Итоговый чек-лист "prod-ready" с отметками done/not done.

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