07. Проверки и ревью: доказать изменение
← Предыдущий модуль · Оглавление · Следующий модуль →
Если сейчас только читаете: русский разбор ситуации без запуска программ. После него ответьте на вопросы самопроверки модуля; практическое упражнение можно отложить.
Результат модуля: вы умеете отличить правдоподобное объяснение от проверенного исправления. Полезный итог работы — это изменение поведения, воспроизводимая проверка и понятные ограничения результата.
Ревью отвечает на вопрос, какие дефекты могли остаться. Тест отвечает на более узкий вопрос: выполнено ли конкретное проверяемое условие в конкретном окружении. Поэтому успешный тест не отменяет ревью, а фраза «замечаний не найдено» не доказывает отсутствие ошибок. Особенно внимательно рассматривайте изменения, которые затрагивают деньги, права доступа, удаление данных и миграции.
В приложении есть инструменты Code Review для изучения PR и локальных изменений; автоматическое облачное ревью GitHub требует подключения и соответствующих настроек. Эти сценарии отличаются от просьбы проверить файлы в текущем локальном чате. Не считайте просмотр PR подтверждением запуска проекта на Windows. Официальная документация Code review.
Практический порядок
Перед исправлением запишите пример входа, ожидаемый ответ и фактический ответ. Если ошибка проявляется только после нескольких действий, сохраните их порядок. Попросите Codex сначала воспроизвести проблему или объяснить, почему воспроизведение недоступно. Затем выберите самую короткую проверку, которая различает старое и новое поведение. Только после неё запускайте обязательные проверки проекта.
Для учебной ошибки достаточно одного содержательного регрессионного теста. Он должен ловить нарушение требования, а не повторять структуру новой функции. Например, проверка «пустой список возвращает пустой результат» устойчивее проверки количества внутренних вызовов, если эти вызовы не являются частью контракта.
Перед передачей на ревью полезно посмотреть размер и состав изменения:
git status --short
git diff --stat
git diff --check
git diff --name-only
Эти команды ничего не исправляют. git diff --check выявляет отдельные проблемы оформления патча; он не запускает тесты и не проверяет бизнес-логику. Если часть файлов уже добавлена в индекс, отдельно изучите git diff --cached. Сравнение рабочей копии и сравнение веток отвечают на разные вопросы; всегда называйте ревизию, которую проверяли.
Пример задания Codex
Проверь текущее изменение без редактирования файлов.
Требование: при пустой выборке показывается пустое состояние.
All остаётся фильтром по умолчанию. Проверь переходы между фильтрами.
Найди путь выполнения и существующие тесты. Для каждого замечания
укажи файл, условие возникновения, последствия и доказательство.
Предположения отдели от воспроизведённых дефектов.
В конце перечисли проверки, которые действительно запускались.
Сильное замечание объясняет причинную цепочку: при каком входе выполняется проблемная ветка, какое требование нарушается и что увидит пользователь. Замечание «здесь потенциально может быть ошибка» без такого обоснования требует дополнительного исследования. Предпочтения по стилю обсуждайте отдельно, чтобы они не скрывали существенные дефекты.
Упражнение
Возьмите небольшой уже завершённый учебный diff. Сначала самостоятельно запишите два риска и один граничный случай. Затем попросите Codex о независимом ревью. Для одного замечания найдите подтверждение в коде или выполните существующий тест. Если замечание не подтверждается, сохраните объяснение отклонения, а не исправляйте код ради согласия с моделью.
В итоговом отчёте используйте формулировки «прошло», «упало», «не запускалось» и «заблокировано окружением». Если тест не стартовал из-за отсутствующей зависимости, результат теста неизвестен. Не заменяйте это фразой «вероятно работает».
Готово, когда: исходная ошибка описана проверяемо; изменённое поведение покрыто подходящей проверкой; выполнены обязательные команды проекта; состав diff понятен; существенные замечания закрыты или явно приняты человеком; незапущенные проверки перечислены.
Самопроверка:
- Чем успешный регрессионный тест отличается от доказательства отсутствия регрессий?
- Почему рецензенту нужен фактический diff, даже если автор подробно описал изменение?
- Как записать результат, если тест не запустился из-за отсутствующего интерпретатора?