fbakiyev Проверка кода
Область проверки
Изучи запрос, diff, относящихся к изменению потребителей, контракты и применимые правила проекта. Установи поведение до и после изменения. Просматривай связанный код настолько глубоко, насколько нужно для подтверждения замечания, не превращая проверку в постороннюю переработку.
Найти существенные ошибки
- Проследи входные данные через изменяемую границу до наблюдаемого неверного результата. Укажи условие достижимости дефекта: одной подозрительной строки без реалистичного сценария недостаточно.
- Для замечания о конкуренции опиши чередование операций и нарушаемое общее состояние. Проверь существующие транзакции, ограничения, блокировки и границы развёртывания, прежде чем сообщать о гонке между проверкой и записью.
- Для замечания о совместимости назови затронутого клиента или документированный контракт. Отличай сосуществование старой и новой версии приложения, порядок миграции и сохранённые данные от гипотетических предпочтений потребителя.
- Проверяй очистку после сбоя и повторы вместе с успешным возвратом. Таймаут после зафиксированного эффекта отличается от отклонённой операции, а обработчик всех ошибок с запасным результатом может скрыть потерю данных или повторную работу.
- Оценивай тесты по независимости ожидаемого результата и покрытию сбоев, а не по количеству. Тест может проходить, подменяя проверяемую границу заглушкой или вычисляя ожидаемое значение тем же ошибочным способом.
Существующие дефекты вне изменения служат контекстом, а не автоматически новыми блокерами. Если изменение делает старый дефект достижимым, объясни связь. Замечания по стилю отделяй, если они не создают конкретной проблемы сопровождения или корректности.
Доказательства и результат
Используй прицельное воспроизведение или относящиеся к задаче проверки, когда они доступны и разрешены. Неудачная подготовка окружения не доказывает дефект продукта; недоступные доказательства не равны успешному тесту. Не одобряй рискованный путь только потому, что прошли посторонние проверки.
Начинай с исправимых замечаний: место, условие возникновения, влияние, доказательство и предлагаемое исправление. Используй уровни серьёзности проекта; отличай доказанный дефект от гипотезы, требующей конкретной проверки. Не прячь замечания после длинного вступления.
Если замечаний нет, скажи об этом и укажи существенные границы охвата и проверки. Запрос только на review предполагает замечания, а не правки реализации, если исправления также не входят в задачу. Отдельный план тестирования и документ передачи работы не обязательны для каждой проверки.