Ревью изменения, предложенного агентом

После появления featured_pages задача ещё не завершена. Нужно понять, соответствует ли изменение контракту и какие утверждения о результате подтверждены. Ревью — это чтение разницы и связанного поведения с позиции требований. В этом уроке создадим карточку, которая отделяет фактические изменения исходников, ожидаемые сценарии и проверки, ещё не выполненные. Такой документ помогает принять небольшой кандидат без выдуманного отчёта о запуске.

Сравниваем исходное состояние библиотеки и авторский кандидат из пятого урока. Настоящий AI-инструмент может предложить другой код; метод ревью сохраняется. Начинать полезно с границ: какие файлы изменены и почему. Если кроме catalog.py появились изменения URL, публичности или текстов, они требуют отдельного объяснения. Даже хорошее улучшение соседней области не становится частью исходного задания автоматически.

Разница и поведение

Diff показывает добавленные и удалённые строки. Он удобен для оценки объёма, но не содержит всего контекста исполнения. Например, строка public_pages(rows) выглядит безобидной, пока не прочитано определение этой функции. Для проверки приватности нужно видеть, что она оставляет только public is True. Поэтому ревью соединяет разницу с ближайшими определениями и входными данными. Одного цветного представления изменений недостаточно для объяснения результата.

У кандидата есть три существенные операции: публичный отбор, рекомендация и сортировка с ограничением. Каждую связываем с требованием. Публичный отбор сохраняет редакционную границу, featured реализует рекомендацию, сортировка задаёт устойчивый порядок, лимит ограничивает число карточек. Если какая-либо операция не имеет понятного основания, уточняем её назначение. Так можно заметить лишний шаг, например сортировку по названию, которая не была предусмотрена контрактом.

Отдельно смотрим неизменяемые свойства. Значение url передаётся из записи напрямую, манифест не перезаписывается, текст не участвует в решении о доступе. Сохранение этих свойств важно не меньше нового результата. Ревью не должно превращаться в поиск только добавленной функции: нарушение старого условия может находиться в основном блоке программы или в небольшом «упрощении» загрузчика, которое автор счёл сопутствующим улучшением.

Основание каждого утверждения

Карточка REVIEW.md содержит форму «изменено — основание — статус». Можно написать: «добавлена функция отбора», поскольку определение видно в файле. Можно написать: «при limit=True ожидается отказ», поскольку код проверяет точный тип. Нельзя написать: «все сценарии прошли», если их не выполняли. Разница между этими фразами сохраняет полезность отчёта: читатель понимает, где достаточно повторить чтение, а где ещё требуется самостоятельное наблюдение.

Слово «работает» особенно неоднозначно. Оно может означать, что код выглядит согласованным, пример успешно выполнился один раз или программа проверена на выбранном наборе входов. Вместо общего слова назовите действие: прочитано определение функции, сопоставлены поля, выполнена такая команда на таком состоянии. В этой серии последние действия не проводились по локальному режиму подготовки, поэтому карточка указывает not_run и не изображает результаты тестового отчёта.

В учебном ревью приведён кандидат дефекта: проверка isinstance(limit, int). В Python логический тип является подклассом целого, поэтому такой критерий допускает True. Это следует из устройства типов, но фактическое поведение полного проекта после изменения всё равно требует отдельного запуска, если он нужен владельцу. Окончательный архивный код использует точное сравнение типа. Не смешивайте демонстрационный дефект и текущую версию функции, иначе читатель будет искать ошибку там, где её уже заменили.

Замечание, которое можно исправить

Хорошее замечание описывает конкретный вход, нарушение и направление исправления. Вместо «валидация слабая» запишем: «логическое значение проходит проверку целого; контракт разрешает только числовой лимит; требуется отклонять bool без изменения правил отбора». Такое замечание позволяет выполнить небольшую правку. Оно также удерживает масштаб: исправление типа не требует переписывать формат данных или менять редакционный признак рекомендации.

Если замечание относится к предпочтению, а не нарушению, его следует обозначить отдельно. Например, имя featured_pages можно обсуждать как договор команды, но оно само по себе не меняет результат. Смешивание обязательных исправлений и вкусовых предложений затрудняет завершение задачи: исполнитель не понимает, что является условием принятия. В нашем маленьком ревью обязательны URL, публичность, порядок и тип лимита; дальнейшая реорганизация функций может стать отдельной задачей.

Не просите агента исправить замечание с помощью изменения исходных данных. Для входа True функция должна выдать отказ независимо от того, сколько страниц рекомендуются. Если уменьшить число записей в манифесте, симптом может стать менее заметным, но дефект границы останется. Поэтому карточка связывает замечание с механизмом, который нужно изменить. Это помогает избежать кандидата, который выглядит правильным на одном удобном примере и нарушает договор при соседнем входе.

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

Проверка объяснения кандидата

Допустим, агент объяснил, что функция «сортирует по редакционному приоритету». В исходниках сортировка идёт по id, а поля приоритета в манифесте нет. Сам код может соответствовать текущему заданию, но объяснение неверно. Такой дефект нужно исправить в отчёте, иначе будущий автор добавит числовой priority и будет ожидать, что функция уже учитывает его. Ревью проверяет не только программу, но и описание её фактического механизма.

Другой кандидат может содержать верное объяснение, но сортировать до публичного отбора и ограничивать промежуточный список. Тогда количество видимых карточек будет зависеть от private-записей. Убедительный текст не устраняет причинную ошибку в последовательности. Откройте выражение и проследите один вход, где служебная запись оказывается раньше публичной. Такой предметный разбор обычно полезнее общей оценки «код выглядит качественно».

Наш REVIEW является авторской карточкой и не приписывает эти варианты реальному AI-ответу. Если вы используете настоящего исполнителя, сохраняйте конкретную версию кандидата, к которой относится замечание. После исправления старое замечание может оставаться историей, но не должно выглядеть текущим дефектом финального файла.

В следующем уроке превратим замечание о типе лимита в диагностическое сообщение. В нём будут исходный вход, ожидание, возможная причина и минимальная область исправления. Такой набор данных пригоден и человеку, и помощнику: он заменяет расплывчатое «всё сломалось» воспроизводимым вопросом к конкретной границе программы.

Полный файл REVIEW.md из состояния lesson-06. Полное самостоятельное состояние находится в архиве серии; фрагмент не заменяет остальные определения.

# Авторская учебная карточка ревью

Изменено: добавлена featured_pages; default limit=2; порядок по id.
Реестр URL и тексты не меняются. Источник публичности — public is True.
Предложенный дефект для разбора: isinstance(True, int) == True.
В окончательном коде используется type(limit) is int.
Статус сценариев: не выполнялись; ожидается отказ при limit=True и limit=0.
Это карточка, написанная автором курса, а не полученный ответ модели.

Статус примера: not_run. При подготовке не выполнялись учебные программы, тесты, вызовы AI или деплой. Описанные эффекты ожидаемые.

Оглавление серии · Полные исходники

Первичные документы: Источник 1.