В современном мире финансовых технологий каждое решение должно быть быстрым, надежным и удобным. Особенно это важно для трейдинга - сферы, где миллисекунды могут влиять на результаты сделок, а пользователи требуют максимально удобных и информативных интерфейсов. Именно с такой задачей столкнулась команда разработчиков крупного глобального банка, взявшаяся за перестройку устаревшего пользовательского интерфейса, используемого трейдерами при мониторинге волатильности опционов по ключевым регионам: EMEA, NAM и APAC. Долгое время этот интерфейс не обновлялся: кодовая база не видела правок с 2020 года, что сделало ее крайне сложной для поддержки и развития. Система была настолько запутанной, что даже опытные разработчики с трудом могли в ней погрузиться.
В этом проекте важнее стало не количество инженеров, а качество их экспертизы - небольшая группа старших разработчиков тщательно изучала код и курсировала по лабиринту устаревших решений, чтобы заменить устаревшие технологии на современные и простые инструменты. Почему не хватало простых исправлений в старом интерфейсе? Во-первых, архитектура унаследованного приложения базировалась на сложном переплетении sagas, Redux, styled components и React-классов. Почти каждый компонент был классом, со сложными жизненными циклами и множеством зависимостей. Это не просто усложняло поддержку, но и вводило большую вероятность возникновения новых ошибок после каждого изменения. Кроме того, контракт между клиентом и сервером строился на GraphQL-запросах, которые выглядели как непрерывно растущие монстры - глубоко вложенные, с огромным объемом данных.
Это приводило к тому, что запросы были неэффективны и не соответствовали реальным потребностям UI. Отдельной сложностью стали тесты. Казалось бы, покрытие кода тестами было хорошим, но на практике многие из них были слабыми, что создавали ложное ощущение безопасности. Из-за этого исправление одной проблемы нередко приводило к появлению другой - текучка багов буквально тормозила развитие. Первым вызовом на пути рефакторинга стало полное распутывание кода.
Сложный взаимосвязанный механизм, в котором каждый виджет вытягивал данные, обрабатывал их особым образом и взаимодействовал с другими элементами, требовал пристального внимания и детального анализа. Ни один из первоначальных авторов кода уже не работал в компании, что исключало возможность задать вопросы и прояснить детали. Это поставило команду перед необходимостью проявить максимальную ответственность и разбираться во всех нюансах самостоятельно. Подход заключался в визуализации и тщательном картировании. Разработчики рисовали схемы, фиксировали все найденные связи, определяли пути передачи данных и взаимодействия компонентов.
Эти визуальные схемы служили не только внутренним инструментом для единого понимания, но и помогали в общей координации с backend-командой, позволяли совместно оптимизировать API для более логичных и эффективных операций. В процессе анализа стало очевидно, что многие задачи в UI можно перенести на backend. Например, UI запрашивал торговые праздники для вычисления даты окончания дня, хотя это можно было реализовать на сервере и передавать готовое значение. Такие наблюдения стали отправной точкой для упрощения архитектуры и минимизации излишних вычислений на клиенте. Для нового интерфейса команда не имела полной свободы.
Он должен был работать в рамках уже существующего монорепозитория, где сосуществовали несколько проектов банка. С одной стороны, это накладывало ограничения, но с другой - давало преимущества: общая техническая база и одинаковый стек упрощали взаимодействие с другими командами и позволяли быстро внедрять изменения. Выбор стека технологий был продуман до мелочей. Для работы над проектом избрали Nx в качестве инструмента управления монорепозиторием. Управление состоянием доверили Redux Toolkit вместе с RTK Query для удобной работы с серверным состоянием.
Для интерфейсных компонентов использовалась внутренняя дизайн-система, обеспечивающая консистентность и единые стандарты во всей экосистеме. Сборку проекта обеспечил быстрый и современный инструмент Vite. Тестирование реализовали через Vitest для unit-тестов и Cypress для интеграционного тестирования. Важным пунктом стало использование Mock Service Worker, который позволял имитировать работу серверных API и проводить разработку, не дожидаясь готовности backend-сервисов. Кроме того, для организации взаимодействия окон и управления виджетами применили Dockview - легковесную библиотеку с нулевой зависимостью и удобным API.
Эта библиотека обеспечила гибкость и комфорт в работе с интерфейсом, сводя к минимуму внутренние сложности. Главным принципом стала простота. Новый UI должен был стать настолько понятным и интуитивным, чтобы даже джуниор-разработчик мог быстро разобраться в коде и внести необходимые изменения без страха повредить существующую логику. Для этого было решено иметь единственный источник правды для всех типов данных - сначала генерация типов происходила из моков, а затем из контрактов OpenAPI, присылаемых backend. Такой подход обеспечивал строгость типов, моментально выявляя на этапе сборки несоответствия и предотвращая ошибки на ранних стадиях.
Архитектура нового решения базировалась на функциональном подходе с использованием React hooks, что позволило сделать код чище и проще для поддержки. RTK Query обеспечивал эффективное управление данными с сервера, включая возможность подписки на события в реальном времени через WebSocket. Проблема высокой скорости потоковых данных от трейдерских сокетов была решена с помощью небольшой клиентской буферизации. Вместо смены Redux на более специализированную библиотеку, команда реализовала буфер, который собирал сотни и тысячи сообщений в памяти и отправлял их в Redux с частотой около четырех обновлений в секунду. Такой подход сохранил производительность и не создавал дополнительной нагрузки.
Проект отказался от излишних сложностей, например, применения web workers. Эксперименты показали, что главный поток справляется с задачами вполне эффективно. Для стресс-тестирования использовалась имитация огромных объемов сообщений, что гарантировало устойчивость решения в реальных условиях. Первая версия новой платформы была выпущена с минимальным функционалом - включала сетку и график, отображающие основные показатели волатильности. На этом этапе решение еще не показывали трейдерам, так как требовался дополнительный полировочный этап, но руководство было вовлечено в процесс через регулярные демонстрации, что помогало сохранять прозрачность и понимание прогресса.
Одним из технически сложных моментов стал менеджмент подключения к нескольким WebSocket-сервисам и распределение данных между виджетами сетки и графиков. Команда смогла разработать простой и элегантный механизм обработки подписок с помощью жизненного цикла onCacheEntryAdded в RTK Query. Это позволило централизованно управлять подписками, слушателями и событиями, сохраняя код линейным и понятным. Данные в новом интерфейсе двигались по четко выстроенному конвейеру. Пользователь взаимодействовал с интерфейсом, вводя значения, которые сохранялись в Redux.
Компоненты подписывались на изменения и инициировали запросы к серверу через RTK Query. Полученные данные при необходимости преобразовывались и сразу отображались в сетках и графиках, построенных на популярных и производительных библиотечных решениях - AG Grid и Highcharts. Чтобы избежать хрупкой и неустойчивой имплементации, использовалась возможность отложенного выполнения запросов, когда следующая задача начиналась только после выполнения необходимых условий. Это устраняло необходимость писать сложный императивный код, повышало надежность и облегчало поддержку. Интенсивное взаимодействие со стороной backend стало ключом к успеху.
Регулярные совещания и прозрачный обмен информацией позволили быстро уточнять детали, исправлять архитектурные несовершенства и адаптировать API под актуальные нужды фронтенда. Благодаря такому открытом диалогу и постоянному обучению всей команды удалось последовательно распутывать сложные бизнес-логики и делать новую платформу лучше с каждым днем. Из опыта самой команды стало понятно, что глубокое понимание предметной области нельзя заменить никакими трюками или ускорениями. В этом проекте именно организационная культура - малочисленная, сплоченная и честная команда - стала главной составляющей успеха. Работа не была про патчи и быстрые решения, а про создание прочной основы, прозрачной, понятной и простой для будущих коллег.
Те принципы, которыми руководствовались разработчики, помогут избежать многих проблем, с которыми сталкивались с наследием. Сегодня новая система продолжает развиваться и радует трейдеров современным, отзывчивым интерфейсом, который отвечает всем требованиям скорости и стабильности. Для команды операционная задача начала течь проще, а внедрение изменений стало быстрым и безопасным. От начального этапа полного непонимания кода до создания масштабируемого и современного решения было пройдено много сложных, но важных этапов. Ключевой урок - смелость полностью отказаться от сложного и запутанного ради простого и надежного.
Такое решение дало возможность намного легче развивать продукт и поддерживать его в долгосрочной перспективе. Сегодня этот проект - пример грамотного и продуманного подхода к переписыванию сложных корпоративных систем, с акцентом на качество, командную работу и понимание бизнес-задач. В конце концов, настоящий успех создается там, где техническое мастерство сочетается с грамотно построенными коммуникациями и четким планом действий. Именно такой путь прошла команда, чтобы превратить старый "спагетти" код в понятную и красивую систему, работающую во благо трейдеров по всему миру. .
