Чек-лист приёмки
в каком порядке смотреть правку
Что это
Статья 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, он ловит больше всего.
Форматирование, именование и вкусовщину не проверяй.
Приёмка без единого вопроса — это не приёмка.