Я — разработчик серверных компонент со стажем в 10+ лет (C++, python). Не трейдер и не квант. Эта статья — результат моих годичных наблюденией, когда после 8 лет в больших IT‑корпорациях, я внезапно нырнул в HFT‑стартап с коллективом в сотню человек. Что в разнице подходов к разработке удивило меня сильнее всего?
Для начала, пара слов о рассматриваемых сторонах:

• Про FAANG, как работодателя, все миллион раз изложено и известно. В представлении многих разработчиков это последняя инстанция карьерного роста, бесплатная еда, огромные мониторы, гениальные коллеги. Я несколько скептичен по отношению к этим компаниям и успел уже немного поныть тут. Дело в том, что там много бюрократии, долгие циклы и часто встречающееся отсутствие интереса к результату. Но зато есть хорошая компенсация и стабильность, как минимум, до недавнего времени.

• HFT (high frequency trading) — ниша технологических компаний, которые занимаются автоматической торговлей на биржах, и, исходя из определения, делают это с высокой частотой. Термин весьма неспецифичен, и задачи, подходы, статусы на рынках у таких компаний довольно разные. Однако, технические решения похожи — критическим фактором для успешности в области является скорость реакции на рыночные изменения. Скорость позволяет обходить конкурентов и хорошо конвертируется в деньги. В этой сфере есть несколько больших игроков, но и множество маленьких компаний вполне способы зарабатывать себе на безбедное существование (если верить их hr).

В целом, многие из моих наблюдений могут быть объяснены значимостью скорости ваших программ и частотой релизных циклов. Вы можете возразить, что скорость важна и в корпорациях. Не зря же они все эти деревья просят развернуть на собеседованиях да асимптотики спрашивают. А как же экономия на тысячах серверов и мегатонны выбросов CO2? Но я не соглашусь, так как везде, где я работал, более важными свойствами систем были надежность и универсальность, а потом уже оптимизация, если вам совсем нечего делать. Выделить 19 ядер на простой веб сервис с БД при нагрузке в 1 rps? Почему бы и нет, зато все надежно, реплицировано и защищено от отряда экскаваторщиков в поиске кабелей датацентра.

Итак, перечисляю основные тезисы и стараюсь не нарушить никакие NDA:

Лучшие решения - простые

Вроде бы, ничего нового и особо умного. «Все гениальное — просто», принцип Парето, Бритва Оккама и т. д. отлично согласуются с этим наблюдением. Но есть нюанс: многие вещи вокруг нас только внешне очень просты.

Например, есть у вас дата+время в текстовом потоке данных, и их надо распарсить. Большинство разработчиков обратятся к документации их любимых языков в поисках нужного модуля, подключат эту штуку и будут молодцами в 99% случаев. Один вызов для конвертации текста в нужную структуру и все готово, что может быть проще? Но если посмотреть, что происходит в этом модуле, то мы обнаружим работу с текущей локалью ОС, какие‑то непонятные виртуальные функции для работы с календарем, всевозможными форматами дат и еще невесть что. А у вас всегда один и тот же формат, данные всегда в одном порядке, и потом еще выяснится, что вам из даты нужны только месяц и день. Код, который делает ровно то, что нам от него надо, будет работать очевидно быстрее.

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

Больше велосипедов богу велосипедов

Использование готовых решений — краеугольный камень эффективной разработки, но предыдущий пункт нас подводит к тому, что многие вещи придется писать самостоятельно. И не только потому, что у них скорость низкая, но и потому, что вы не доверяете решениям сторонних разработчиков. А цена программной ошибки (или взлома) может быть слишком велика. Например, исчезновение вашей компании.

Хотя отмечу, что велосипедные решения, которые неуместны в приличных местах, в очень больших корпорациях так же естественны. В многих компаниях FAANG вы встретите собственные решения для стандартных задач. Там это чаще всего мотивировано высокими нагрузками, желанием независимости от сторонней поддержки, а также наличием незанятых разработчиков.

Отсутствие авторитета стандартов и подходов

Раньше я довольно наивно полагал, что умение писать высоконагруженные системы на C++ так или иначе пересекается с владением многопоточностью. Активно применял ее в своих проектах, изучал свойства модели памяти, семантики атомарных типов и т. д. А потом, в окружении с приличной нагрузкой и огромной важностью задержки, я встретил постулат «никакой многопоточности». Так как это сложно, делает код неочевидным и обладает известными накладными расходами. А накладные расходы, как мы уже заметили, это плохо. И тут я напомню, что некоторая синхронизация потоков также проросла в такие безобидные инструменты C++ как static и в некоторые умные указатели. И вот вы в 2023 перестаете смущаться использования сырых указателей, которые были избегаемы вами много лет. Ведь вы знаете, что делаете. Что может пойти не так?

Сталкиваясь с подобными ситуациями, понимаешь, что многие наставления о хорошем написании кода или проектировании перестают быть авторитетными в экстраординарных ситуациях. Собственно, они для этого и не предназначались никогда.

Также отмечу, что это касается не только кода — популярные инфраструктурные решения, конечно же, также подвергаются пересмотру, будь это системы виртуализации/контейнеризации, транспортные протоколы и пр. Инфраструктура для высокочастотной торговли важна не менее кода.

Доступность не так уж и нужна

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

Для таких компаний репутационные потери от даунтаймов — это очень плохо, инвесторы такое не любят. Вот они и хотят, чтобы сервисы их компании были в работе все 100% времени. Но на разработку и поддержку подобных проектов, защиту от невозможных ситуаций и иные способы страховки разработчики тратят действительно много времени, которое они могли бы потратить на запуск чего‑то нового. Чего‑то, что принесет больше денег, чем защита от даунтайма на пару часов раз в несколько месяцев. Хотя, отсутствие этой защиты и сделает вашу работу несколько более нервной. Особенно во время дежурств.

В общем, идея страхования только там, где «тонко», и избыточности стопроцентной доступности может вас удивить после мании корпоративной стабильности. Кстати, это же касается и высоких процентов покрытия тестами.

Найм умер

Точнее, он сильно сломан в корпорациях. Алгоритмические секции, которые проверяют усердность в решении топ100 литкода, поведенческие и «культурные» секции, проверяющие вашу способность приукрашивать, это все очень интересно и, наверное, может дать объективность на большом потоке людей. Однако, этот подход очевидно плохо тестирует знания и умения нужные непосредственно вашей команде. А в местах с буткампом, попадание нового сотрудника в случайную (относительно его навыков) команду только усугубляет проблему. На выходе получается, что уровень коллег, после подобной фильтрации, не такой уж и высокий, как общепринято считать.

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

Насколько для вас это проблема или преимущество — вопрос открытый.

Интересные ежедневные задачи

Далеко не всем нравится работать «в финансах», и некоторые из аргументов против вполне логичны. Скромное влияние на общество, например. Мегакорпорации же позиционируют себя как важные явления современности, которые тут не просто рекламой деньги зарабатывают, а сеют разумное, доброе, вечное.

Правда, находясь там и занимаясь оптимизацией некоторой метрики, рост которой никто никогда нигде не заметит, вы также можете справедливо спрашивать себя: не ерунду ли я делаю? На некоторых проектах вы вообще будете игнорировать код месяцами, писать документы и посещать нескончаемые митинги. И только на словах ваша работа будет казаться окружающим чем‑то классным.

Большинству HFT‑компаний не особо выгодно разрастаться, а работая в компании с штатом в сто раз меньше, вы будут винтиком в сто раз больше. И даже если влияние на окружающий мир будет не таким большим, как вам хотелось бы, вероятность заниматься интересными инженерными задачами может быть существенно выше.

Что в итоге

Все это можно просуммировать как отрицание обобщений и уменьшение расточительности. Это кажется логичным, так как большие компании хотят универсальности для уменьшения порога вхождения в свои проекты, а также готовы потянуть некоторые перерасходы. В HFT же расточительность напрямую бьет по вашей годовой премии, а небольшие команды опытных специалистов могут себе позволить высокий порог вхождения. Таким компаниям нужно, чтобы ваш код помогал зарабатывать деньги, а не состоял из классных абстракций. И хотя это применимо ко всей коммерческой разработке, там это чувствуется острее, а многое из того, что везде считается хорошим тоном, может быть подвергнуто сомнению в пользу мгновенной выгоде.

С другой стороны, описанные практики вполне могут сделать вас весьма «деформированным» и не очень пригодным для работы в иных местах. Я бы рекомендовал движение от общего к частному. Но и грезить только огромными корпорациями, как местом, где можно сидеть до пенсии, возможно, не стоит.