Программирование с ИИ
ENRU
4.7

Чек-лист приёмки

в каком порядке смотреть правку

Что это

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

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

Шесть шагов по порядку

1. Размер правки

git diff --stat

Совпадает с ожиданием? Одна строка вместо одной — дальше. Семь файлов вместо одного — остановись и разберись, прежде чем читать содержание (статья 3.13).

2. Удалённое

Смотри строки с - раньше строк с +. Удаление опаснее добавления: добавленный код виден, а исчезнувшая проверка — нет.

Типичные потери: if not data: return, проверки длины, обработка краёв.

3. Поведение в неудачном случае

Один вопрос: что будет, если данные придут не те? Если в правке появились .get() с умолчанием, except или подстановка значений — проверь, не спрятана ли ошибка вместо починки (статьи 2.8, 2.14).

4. Границы

Правка делает то, о чём просили, и ничего сверх? Логирование, кеш, повторные попытки, которых не заказывали, — это непроверенный код в проекте.

5. Запуск

Тот случай, ради которого всё затевалось, плюс один неудачный. Если есть тесты — прогнать (статья 4.6).

6. Объяснение

Можешь объяснить правку в двух предложениях? Если нет — вернись к чтению или спроси (статья 3.7).

Как сказать ИИ

Чек-лист можно отдать и ИИ, но с оговоркой: о своём коде он отвечает снисходительно (статья 3.8). Поэтому — в чистой сессии:

Запрос
Вот дифф. Я его не писал, нужна приёмка.
Пройди по порядку:
1. Что удалено и почему это могло быть важно
2. Что произойдёт при неожиданных данных
3. Что в правке сверх заявленной задачи

Задача была: <что просили>.
Если проблем нет — скажи прямо.

Для себя полезно другое — зафиксировать, что проверил:

Запрос
Составь из этой правки список того, что я должен
проверить руками. Коротко, пунктами, чтобы я отметил.

Что не надо проверять

Чтобы внимания хватило на важное, часть вещей стоит сознательно не трогать:

Не проверяй рукамиПочему
форматирование и отступыэто работа форматтера, а не твоя
стиль именованияесли читается — достаточно
микрооптимизациипока нет проблемы со скоростью, это не проблема
«я бы написал иначе»иначе — не значит хуже

Последний пункт самый важный. Спорить с ИИ о вкусовых вещах — потраченное время: он уступит, а код лучше не станет.

На что смотреть

Проверка начинается с содержания, а не с размера. Прочитал двести строк внимательно, а надо было остановиться на --stat и переспросить.

Удалённые строки пролистаны. Самый частый способ пропустить настоящую проблему.

Чек-лист превратился в ритуал. Шесть шагов подряд без вопросов — значит, смотрят, но не видят. Нормальная приёмка — это хотя бы один вопрос.

Приёмка отложена на потом. Пять правок, потом разбор всего разом. Ищи теперь, какая из пяти.

Шпаргалка

  • Порядок: размер · удалённое · неудачный случай · границы · запуск · объяснение.

  • Начинай со --stat, а не с содержания.

  • Строки с - читай раньше строк с +.

  • Не хватает внимания — остановись после шага 2, он ловит больше всего.

  • Форматирование, именование и вкусовщину не проверяй.

  • Приёмка без единого вопроса — это не приёмка.