Ломайте код и план до релиза четырьмя проходами

Первый проход смотрит на решение глазами злонамеренного пользователя: SQL-инъекции в каждом поле ввода, XSS в каждом выводе, IDOR через подмену идентификатора в запросе, обход авторизации и доступ к чужим ресурсам, подделка межсайтовых запросов, загрузка исполняемого файла под видом картинки и тысяча запросов в секунду в обход rate limiting.

Второй проход ищет гонки: что будет, если два процесса делают одно и то же одновременно. Двойной клик по кнопке оплаты, две открытые вкладки с одной формой, параллельные запросы к одному ресурсу, read-modify-write без блокировки, обновление кеша прямо во время чтения — классы дефектов, которые не видны в обычном прогоне и всплывают только под нагрузкой.

Третий проход подаёт данные на краю допустимого: пустая строка, null и undefined, максимально длинная строка вроде десяти мегабайт текста в поле имени, отрицательные числа там, где ожидаются положительные, Unicode с эмодзи, RTL-текстом и zero-width символами, даты 29 февраля, 2099 год и epoch 0, коллекции из нуля, одного и миллиона элементов.

Четвёртый проход выключает инфраструктуру по одному узлу: база данных недоступна, Redis упал, внешний API отвечает пятисотой, сеть теряется в середине запроса, кончился диск, кончилась память, DNS не резолвится, истёк сертификат. Проверяется не наличие обработчика, а поведение системы в этот момент — что видит пользователь и в каком состоянии остаются данные.

Это дополнение к обычному ревью, а не замена ему: обычное проверяет, что код делает задуманное, а adversarial-проход пытается его сломать, поэтому его имеет смысл тратить на критичные компоненты — оплату, авторизацию, интеграции. На вход годится и код, и pull request, и ещё не реализованный план решения, а разбор плана обходится дешевле всего.