Есть набор различных проектов. В которых есть расчетная часть и интеграционная часть. Расчетную часть пишут математики, интеграционную пишут программисты. Математикам удобнее всего питон. Ибо там куча либ из коробки на все случаи жизни, причем весьма шустро работающих, так как под капотом плюсы, а то и вообще CUDA и гоняется все на видеокартах.
Код математиков — это просто полный капец. Сплошной копипаст, хрен пойми как названные переменные, зачастую глобальные, вся логика в одной функции на 5000 строк и тому подобные прелести, и к этому еще многопоточность прикрутили.
Вопрос — как этот код использовать в реальном проекте? Собственно скорость кода вполне устраивает, вот только в таком коде кроме математиков никто разобраться не может, да и они сами после определенной сложности начинают делать кучу багов, и у них после определенного момента скорость разработки идет уже весьма низкая за счет ошибок, в том числе и ошибок типизации.
Какие вижу варианты:
1) Переписывать этот код. Причем на другой язык, чтоб статическая типизация была, покрывать тестами и т.д. Но получается двойная обезьянья работа — логика математиков весьма нетривиальна внутри, переписывать не быстро, разобраться в этом капеце и рефакторить весьма непросто, и в процессе переписывания хочется застрелиться. И одновременно с переписыванием нужно долго еще править баги, которые возникают в результате переписывания. Соответственно удовольствия от этого никакого, и у сотрудников сразу появляется желание к чертям менять работу и не заниматься этой хренью. Плюс нужно умножать сроки на время переписывания, причем коэффициент будет около четырех, то, что написали за месяц, переписываться будет 4 месяца.
2) Работать с этим кодом как с черным ящиком. Зафиксировать вход и выход. И вызывать этот питон через командную строку, а входные данные, если они большие, через файлы. Собственно пока так и сделал, ибо нужно все быстро показывать заказчику, а математики постоянно там логику черти как правят, причем еще и у них требования меняются. Но выглядит костыльно до ужаса, хоть и работает.
3) Оформлять питон код как сервис, упаковывать в докер контейнер, гонять в kubernetes, как все остальное приложение. Вроде выглядит более менее здраво и с минимум костылей, всю внешнюю обвязку в библиотеки. Возможно с большим скрипом проталкивать code reviev (почему с большим — математики это другое подразделение со своим начальником, а ревьюить их нужно со стороны программистов, по хорошему там нужно git flow попробовать заюзать вообще, но это малореально провести — это другой отдел). У программистов есть люди с хорошим уровнем именно питона, причем умеющие на нем писать. Вот только проблема — на питон они не вернутся, ибо язык не нравится, любят статическую типизацию. Соответсвенно непонятно, кого напрягать писать сервисную обвязку? Если математиков, то они нормально не напишут. Если программистов — есть риск что те, кому будет поручена такая задача, уволятся к чертям. Нанимать тех, кто на это подпишется?
4) Другой вариант.
Сам пока склоняюсь к третьему, но пока использую второй.
Но в идеале бы хотел, чтоб математики сразу писали на статически типизированном языке и писали нормально. Они на статически типизированном языке кстати пишут несколько получше, но на начальном этапе медленнее. После определенного этапа они даже на статически типизированном языке сами пишут быстрее. Правда для них библиотеки нужно писать и тому подобное. Вариант этот пробовали, кстати, и он работает удовлетворительно. Проблема в том, что без внимания биг босса все скатывается в хаос, а биг босс с этим хаосом несколько подустал бороться, да и у него начали возникать сомнения в том, что стоит бороться с этим зоопарком языков. Собственно понятно, что серебряной пули нет, во всех вариантах есть свои сильные и слабые стороны и нужно найти какой то компромисс.
Соответственно вопрос — какой из вариантов будет наименьшим злом? Третий?
