...они делают больно иначе. Методично... Каждый день...

Такие баги не вызывают 500-х ошибок. Не роняют сервисы. Не будят дежурную смену среди ночи.

И именно поэтому могут обходиться бизнесу гораздо дороже любых аварий.

На одном из проектов нужно было реализовать автоматический перерасчет комиссии для определенной категории клиентов.

Задача была согласована, реализована и успешно прошла тестирование. Казалось, все прошло идеально. Но…

…во время разработки произошло одно небольшое не запланированное изменение. Вместе с новой логикой перерасчета разработчик случайно включил уже существующий механизм начисления другой комиссии, в функционал перерасчета.

В результате новая функциональность работала корректно.

А вот вторая комиссия стала начисляться только тем клиентам, которые одновременно попадали под оба условия. Таких клиентов оказалось значительно меньше.

Система не падала. Ошибок в логах не было. Клиенты не жаловались.

Система продолжала делать именно то, что в нее заложили. Просто это оказалось не тем, что ожидал бизнес.

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

После этой истории я понял одну вещь.

Мы привыкли бояться багов, которые ломают систему.

Но самые опасные баги — те, которые незаметно меняют бизнес-логику.

Именно поэтому изменения, связанные с расчетами, деньгами, тарифами или начислениями, требуют особого внимания.

Иногда один неверный логический оператор может стоить компании дороже, чем масштабный сбой.

А как вы защищаете критичную бизнес-логику на своих проектах?

Достаточно ли код-ревью и тестов, или такие изменения требуют дополнительных проверок со стороны аналитиков, QA и бизнеса?