В тикете будущая функция почти всегда выглядит скромно: добавить поле, расширить фильтр, ввести ещё один статус в знакомом процессе. Из-за этого её легко принять за безопасную мелочь. Но риск обычно прячется не в размере диффа. Он сидит в старом поведении, на которое новая ветка опирается. Если этот путь никто не перечитывал после прошлого сбоя, изменение просто вернёт ту же поломку под другим названием.

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

1. Никто не отвечает за поведение, которое изменит функция

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

2. Проверить изменение можно только на живом сайте

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

3. Сообщение «Спасибо» и реальная запись уже расходятся

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

4. Никто не может назвать, сколько секунд страница уже занимает

Новый фильтр, дополнительная колонка или более тяжёлый ответ ложатся на страницу, где пользователь уже ждёт. Если рядом с URL или названием задачи нет числа, вы не сможете честно сказать, стало ли хуже после изменения. Сначала нужно зафиксировать время. Потом, если он доступен, откройте медленный журнал за этот промежуток, сгруппируйте запрос и сравните число просмотренных строк с числом отданных. Пустой журнал сам по себе не доказывает, что страница быстрая. Порядок такого чтения описан в как читать медленный журнал до рефакторинга.

Фраза «вроде нормально» без секунд остаётся только предположением.

5. Та же задача уже способна создать две записи

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

6. Продукт общий для нескольких заказчиков, а страницу не открывали под двумя аккаунтами

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

7. Процесс уже растёт, пока кто-то его не перезапустит

Если на прошлой неделе всё закончилось перезапуском, новый цикл в функции легко приведёт к тому же результату снова. Зафиксируйте память до действия, на пике и после завершения. Дополнительная RAM только отодвигает повторение, но не объясняет причину роста. Такой проход описан в что проверить до покупки памяти. Ревью, которое обсуждает новый класс, но не спрашивает, что именно процесс удерживает в памяти, пропускает признак прямо перед собой.

8. Секрет для этой функции уже лежит в чате или в репозитории

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

9. Последняя выкладка удивила тех, кому потом пришлось всё объяснять

Такое удивление почти всегда означает разрыв между изменением и его описанием. Была неясная ветка, неясная команда или непонятно, кто вообще должен был это запускать. Иногда ночная задача падала до утра, а команда потом восстанавливала результат вручную. Перед тем как добавлять ещё одну подвижную часть, откройте журнал ошибок за последнюю неделю. Соберите повторяющиеся строки и привяжите каждый повтор к конкретной операции: письмо не ушло, карточка не создалась, отчёт пришлось набирать заново. Функция поверх ночного сбоя даёт два сюрприза вместо одного. Разовый шум можно оставить на потом, а повторяющийся ночной сбой оставлять не стоит.

10. Предложенное ревью уже стало переписыванием, хотя путь никто не читал

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

Очередь или кэш тоже могут оказаться преждевременным ответом. Фоновая задача, которая выполняет тот же цикл, всё равно читает те же строки. Человек просто видит состояние «обрабатывается» вместо прямого ожидания. Расход не исчез, он лишь сменил место. Когда очередь действительно уместна, работа должна уйти из клика, а повтор не должен дублировать побочный эффект. Это уже другое решение, и оно описано в когда очередь уместна рядом с приложением.

Что должно быть в ревью вместо этого

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

Когда вторая пара глаз и есть главная работа

Команда, которая умеет открывать журналы, может пройти этот список сама. Второй взгляд нужен, когда журнал лежит там, куда никто не заходит, когда поведение можно объяснить только на живой базе, или когда тикет уже скатился к переписыванию без секунд и без пути заявки. Пришлите операцию, секунды и результат одной тестовой отправки. Сырой журнал с данными заказчиков присылать не нужно.

Именно такое чтение и есть работа. Услуги охватывают скорость, восстановление систем, которые уже работают на проде, и связи вокруг них. Избранные работы показывают результат рядом с операцией, которая его дала. Если у вас уже есть страница и один из признаков из этого списка, пришлите именно их. Строки заказчиков оставьте у себя.