Чек-лист ревью кода

двенадцать пунктов на один экран

Что это

Список, по которому читается любой сгенерированный кусок кода, прежде чем он попадёт в проект. Подробности — в главах 2 и 4; здесь только порядок.

Я понимаю, что делает каждая строка? Если нет — не вставлять, а спрашивать (статья 2.1).
Это решает мою задачу или похожую? Самая частая подмена: решена задача, которую ИИ понял, а не та, которую ставили (статья 3.1).
Что будет, если это сломается? От ответа зависит, сколько времени тратить на остальные пункты (статья 1.5).

1. Ошибки. Есть ли обработка там, где что-то может не получиться: сеть, файл, разбор данных, деление. Пустой except — красный флаг.

2. Крайние случаи. Пустой список, None, ноль, отрицательное число, очень длинная строка, два одинаковых значения.

3. Внешние данные проверяются. Ответ API, ввод пользователя, содержимое файла — ничего из этого не разбирается без проверки (статья 7.3).

4. Секреты. Ключей, паролей и токенов в коде нет. Ни «временно», ни «для примера» (статья 5.7).

5. Новые зависимости. Появилась библиотека, которой не просили? Спросить зачем. Часто её можно не добавлять.

6. Зона правок. Изменено только то, о чём просили. Переписанные «заодно» куски — повод откатить и повторить запрос (статья 3.13).

7. Файлы и пути. Относительные пути к данным, жёстко вшитые адреса и /home/user/... в коде (статьи 12.1, 13.4).

8. Повторы. То же действие появилось в третьем месте — пора выносить.

9. Названия. Имена говорят, что внутри. data2, temp_fix, handle обычно означают, что автор сам не знал.

10. Зависимости слоёв. Запрос к базе из обработчика экрана, импорт наверх (статья 13.1).

11. Что удалено. В диффе смотреть не только добавленное, но и минусы: что исчезло вместе с правкой (статья 2.13).

12. Проверки на месте. Не отключены ли линтер, типы, тесты ради того, чтобы «прошло» (статья 2.14).

Чтение не заменяет запуска, запуск не заменяет чтения. Минимум:

запустить и пройти свой сценарий руками;
пройти неудачный сценарий: выключить сеть, подать пустое значение;
прогнать тесты, если они есть, и прочитать, что именно они проверяют (статья 4.6);
посмотреть на изменённые файлы в git diff целиком, перед коммитом.