В 2020 году я написал робота, который закрывал за меня клиентские валютные сделки на Мосбирже. Схема оценки рынка у него была, прямо скажем, наивная: восемь метрик, пять состояний и лестница if-ов. Эта схема два года зарабатывала банку его копейки — и умерла не от наивности.

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

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

Я сделал его в 2002 году, выбрал хранить, и получил вместе со скоростью проблему на двадцать лет вперёд.

Проблема выглядела так. Хранимые остатки по счетам время от времени переставали сходиться с операциями, которые их формируют. Иногда на копейки, иногда на миллионы. Я написал утилиту, которая находила такие счета и правила цифры. Потом встроил её в запуск приложения. Потом добавил кнопку в интерфейс, потому что остатки успевали скривиться и среди дня. Костыль на костыле, зато быстро. Причину я нашёл только сейчас, когда сел писать систему заново: в новой архитектуре каждый случай приходится описывать явно и покрывать тестом, и на этом всё и вскрылось.

Причина оказалась не в триггерах и не в производительности. Она в том, что одно бизнес‑правило было записано в коде шесть раз в разных местах, а в седьмом его забыли написать.