Как просрать миллион.
sorhed — 10.05.2016 Не могу молчать! Захотел поведать миру профессиональную тайну о контроле качества в мире финансового программирования. Как проверяются системы, через которые проходят миллионы долларов в секунду?Формальные методы? Нет.
Покрытие юнит-тестами, контрактами и прочей ерундой, 100% coverage? Нет.
Staging? В какой-то мере да; как правило, каждая система задеплоена в трёх экземплярах: dev, UAT и продакшн. Но этап UAT короткий и это именно UAT (удостовериться, что программист всё правильно понял): человек проверяет пару дней, что нигде не перепутаны знаки и все сделки происходят в нужном порядке, и даёт отмашку, что всё ОК.
Так как же тогда?
Правильно. Сырая система, только что из-под трясущихся пальцев программиста, пройдя минимальный контроль UAT, попадает СРАЗУ В ПРОДАКШН НА ЖИВЫЕ ДЕНЬГИ. Но деньги это не очень большие; ставить заметный capital allocation и/или высокие лимиты на новую систему дураков нет. Только успешно проработав несколько месяцев или лет, она увидит эти самые миллионы долларов в секунду.
Этим убиваются сразу много зайцев:
1) Программисты мотивируются писать сразу хорошо (или по крайней мере, выполнять большую часть тестов самим, не дожидаясь фейла в продакшне).
2) Каждая система в финансах попадает в неизвестную враждебную среду, в которой кишат, как мудро сказал когда-то один начальник госдепа, unknown unknowns. Совершенно невозможно их все предусмотреть заранее, поэтому приходится вести разведку боем.
3) Функциональное программирование, формальные методы и прочие мазохистские развлечения отдаются на усмотрение программиста, который иногда от этого даже получает удовольствие. Если, конечно. не просирает дедлайн.
4) Любая система может упасть, ошибки неизбежны, а потому за продакшном всегда должен следить специально обученный человек, который кормит собак и ничего не трогает. Когда человека нет — обязательно происходит какая-нибудь гадость, no exceptions. (Это касается и других высокорисковых областей вроде полётов в космос или ядерных станций).
|
</> |