Angular разработчик

Angular в Findev

Angular в Findev — это не типичная работа с веб-фронтендом. Интерфейсы, которые мы создаём, обрабатывают тысячи сообщений в реальном времени, отображают финансовые данные, которые должны быть точными при каждом обновлении, и обрабатывают действия, где одна отправка может представлять собой значительную сделку. Инженерное требование вытекает из этого: корректность — это не просто критерий качества, это функциональное требование. Данные, которые приходят с опозданием, отображаются неправильно или теряются под нагрузкой, — это не проблема UX. В финансовом контексте это операционная проблема.

Данные в реальном времени должны оставаться пригодными для использования

Торговый интерфейс может быть функционально корректным и при этом подводить своих пользователей из-за плохой производительности. В одном из проектов Findev трейдеры используют глобальную платформу для торговли и потребления данных в реальном времени о сотнях финансовых продуктов одновременно.

Есть ещё одна важная часть этой работы: один клик или отправка формы могут представлять очень крупную сделку. В этом контексте клик — это уже не просто событие интерфейса. Это шаг в значительной финансовой транзакции. Корректность UI, предсказуемое поведение и покрытие тестами имеют значение, потому что небольшая ошибка во фронтенде может повлиять на саму транзакцию.

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

Структура проекта и инструменты зависят от проекта

В Findev мы формируем каждый Angular-проект вокруг продукта, команды и способа его доставки. Нет фиксированных правил. Инженеры решают, что лучше подходит для проекта, и это решение может меняться по мере развития системы и команды. Некоторые проекты используют монорепозиторий, в то время как другие хранят приложения и библиотеки в отдельных репозиториях.

Для сфокусированного приложения Angular CLI может предоставить всё, что нужно команде. Современная система сборки Angular использует esbuild для компиляции и бандлинга, а сервер разработки — Vite. Эти инструменты уже входят в текущий набор инструментов Angular.

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

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

Инженерный подход

Текущий стек торговой платформы включает Angular 20+, TypeScript, RxJS и JavaScript.

RxJS помогает нам выражать асинхронные потоки, но использование observables — это простая часть. Инженерам всё равно нужно понимать время жизни подписок, частоту эмиссии, планирование, обработку ошибок и количество рендеринга, вызванного дальше по цепочке. Диагностика проблемы с производительностью может потребовать отслеживания обновления через реактивный конвейер, обнаружение изменений Angular и процесс рендеринга браузера.

Вот почему мы заботимся о JavaScript не только через API фреймворка. Расследование проблемы в продакшене может потребовать понимания вычислительной сложности, распределения памяти, V8 или цикла событий браузера. Экспертиза в Angular без экспертизы в JavaScript оставляет слишком много проблем с производительностью необъяснёнными.

Тестирование полных финансовых рабочих процессов

Модульное тестирование, разработка через тестирование и код-ревью остаются частью работы с большой кодовой базой Angular. Модульные тесты проверяют компоненты и изолированное поведение. End-to-end тесты проверяют, что полный рабочий процесс всё ещё работает в реальном браузере.

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

Сервер MCP Playwright даёт AI-агентам прямой контроль над браузером, а CLI построен для использования с такими инструментами, как Copilot и Claude Code. Это может снизить механическую работу по созданию и поддержке тестов, но сгенерированный код всё равно требует инженерного обзора. AI-инструмент может предложить тест; инженер остаётся ответственным за решение, доказывает ли он правильное финансовое поведение.

UI — это не изолированный слой. Некоторая работа распространяется на микросервисы Node.js, построенные с NestJS или Express и поддерживаемые MongoDB или Redis.

Что это стоит и что даёт

Angular обеспечивает структуру, но не даёт производительность или корректность бесплатно. Nx может упростить управление большим рабочим пространством, но добавляет концепции и конфигурацию. End-to-end тесты занимают больше времени, чем модульные, при этом покрывая рабочие процессы на уровне браузера, которые модульные тесты не могут покрыть.

Инструменты оправдывают своё место, когда снижают реальный инженерный риск. Общее требование — чтобы инженеры понимали фреймворк, среду выполнения под ним и финансовую значимость действий, представленных через интерфейс.