Привет, Хабр! Меня зовут Олег Рогов, я руковожу фронтенд-разработкой НЛМК. У нас команда на 70+ человек, в основном мы делаем интерфейсы для промышленных систем. Например, дизайнеры рисуют схему цеха или огромную таблицу сравнения для коксохима, мы всё это внедряем и потом поддерживаем на фронтах.
Наши фронты — это в основном широкоформатные экраны, поэтому мы пишем приложение под них в первую очередь. Причём экран такой, около которого сидит инженер (часто в защитных очках) и смотрит на него при не самом хорошем освещении.
По большей части мы визуализируем производственные системы, дашборды состояний цехов, разные прикладные штуки вроде больших таблиц выработки руды, временные ряды загрузки оборудования, финансовый анализ производства, логистику, инженерный анализ возможного отказа оборудования.
80 % наших задач крутится вокруг систем управления производством, то есть мобильное приложение или планшет — это для нас редкий экран, но и такое разрабатываем.
Наш типичный фронтенд: оператор смотрит на схему техпроцесса
Для чего нужны интерфейсы в сталелитейной компании
В целом — для всего. Причём от многих интерфейсов зависит эффективность производства, то есть появляется прямая потребность их делать, на эту тему есть статья «Интерфейсы для производств — это не сайты штамповать» моей коллеги Анны Труфановой. Если сделать правильный UX, то можно решать какие-то задачи точнее, какие-то быстрее, а какие-то — гораздо безопаснее. Одна из вещей, которой мы гордимся, — это то, как мы помогали повысить безопасность производства на разливочном ручье. Причём конечные пользователи сами этого хотели, иногда даже торопили нас и вообще помогали, что случается нечасто. Там есть огромная 3D-схема ручья, которая не очень характерна для фронта сталелитейной отрасли, но именно такая была нужна работникам, чтобы видеть, где в каком состоянии форсунка.
Вот она, а дальше ещё примеры, где нужна наша работа:
Вот такие таблицы
Графики
Мнемосхемы процессов
Расходы материалов
Стек и среда
У нас есть внутренний реферер для проектов НЛМК на React c TypeScript, свой линтер, своя конфигурация сборки. Компоненты лежат в дизайн-системе, то есть если вам нужен календарь, таблица, график или вьюха на камеру в цехе, можно взять готовый компонент из дизайн-системы. Если это не соответствует вашим задачам полностью или если нужного компонента нет, можно контрибьютить в дизайн-систему. Сама дизайн-система (базовая) в опенсорсе, кстати.
При текущем размере команды хаоса нет: обычно сначала люди спрашивают в общем чате про особенности работы с каким-то компонентом, им подсказывают, что можно использовать. Если надо писать новый — все в курсе, что кто-то им занимается.
В целом вся команда пишет на Реакте и одинаково хорошо разбирается в наших инструментах, но есть несколько проектов-исключений. Есть легаси-системы — например от подрядчиков осталось несколько проектов на Vue и Angular. Их всё же надо поддерживать, поэтому есть как Vue-специалисты, так и Angular.
Производственные дашборды
Мы организовали нашу рабочую среду таким образом, что большие программы и системы управления разделены на небольшие части. Каждую такую часть обрабатывает конкретная группа специалистов из нашей команды. Вместо того, чтобы работать всем вместе как единый большой отдел из более чем 70 человек, мы разделились на мелкие группы, каждая из которых занимается своими конкретными заданиями. В каждой такой группе есть человек, отвечающий за связь со всеми остальными в этой области. Допустим, специалист по интерфейсу в группе по производству будет отчитываться перед своим начальником в этом подразделении, но в технических вопросах он будет обращаться ко мне. Мы также поддерживаем сотрудничество и обмен знаниями внутри нашего отдела. Это объединяет.
По поводу нашей работы с NPM-библиотеками — мы их всегда держим в актуальном состоянии. В прошлом году мы столкнулись с некоторыми проблемами, когда библиотеки стали нестабильными из-за ошибок в программном коде. Мы занялись этим, зафиксировали версии библиотек, проверили их на безопасность и стали внимательнее следить за обновлениями. Для большей безопасности мы используем прокси-сервера, которые собирают пакеты с программным обеспечением только из источников, которым мы можем доверять. Перед тем как использовать что-то новое, мы тщательно изучаем, кто его создал и поддерживает. После того как программное обеспечение проходит все наши проверки безопасности, мы вносим его в список используемых в проектах ресурсов.
Наконец, мы стараемся не зависеть от одного поставщика или компании. К примеру, мы отказались от использования таблицы DevExpress — у них внезапно лицензия стала платной. Даже если бы мы захотели за это платить, мы предпочли найти другое решение, которое соответствует нашим потребностям.
У нас очень хорошая процедура деплоя с регрессионными тестами, апрувом дизайнера (что мы сделали то, что он рисовал), апрувом разработчиков и сдачей кода в эксплуатацию с документацией.
После сдачи в эксплуатацию проект может остаться без поддержки — такое случается, многие системы пишутся, чтобы считать что-то, что привязано к производству, и до модификации проекта будут просто работать. На таких проектах есть таймеры на «обновить библиотеки и проверить, что всё хорошо». Если в проекте надо расширить функционал, мы начинаем с небольшого рефакторинга, когда обновляемся, и следим за консистентностью.
Особенности фронта на производстве
Мы часто сталкиваемся с необходимостью отображения больших объёмов информации и данных на экранах. Раньше использовали дизайн-систему, основанную на Material UI, но она много в чём нас не устраивала. Одним из недостатков было то, что она не позволяла легко создавать настраиваемые компоненты. Также мы столкнулись с проблемой масштабирования: нам нужно было уместить много информации на одном экране, а существующая система с этим не справлялась хорошо.
Итак, после многих попыток приспособиться, мы решили разработать собственную дизайн-систему. Она учитывает наши специфические нужды и требования̆, так что теперь каждый компонент можно настроить или изменить, чтобы он идеально соответствовал задачам.
При этом компоненты внутри этой системы могут очень широко варьироваться, вот, например, выбор времени для разных задач:
Есть очень сложные компоненты, например, от некоторых таблиц люди ждут экселеподобного поведения, когда можно скопировать и вставить в другое место столбец данных или отредактировать несколько ячеек.
Мы заботимся о том, чтобы наши интерфейсы были комфортными для работы в различных условиях, включая тёмные производственные помещения. В таких местах яркие цвета экранов могут ослеплять, поэтому мы обеспечиваем опциональную тёмную тему, а для некоторых интерфейсов она основная.
Цвета в наших интерфейсах не фиксированы, а могут быть изменены дизайнерами через токены и автоматически применены ко всем экранам. Это гарантирует гибкость и логическую взаимосвязь в выборе цветов.
Когда дело доходит до форм, то иногда описания для них поставляются нам в формате JSON с сервера и мы реализуем их визуализацию. Мы проверяем введённые данные дважды, на клиентской и серверной сторонах, чтобы гарантировать их корректность. Мы также используем определённые правила (манифест) для каждого поля формы, чтобы убедиться, что данные соответствуют требованиям.
Перед тем как мы запускаем новый компонент, его тестируют рабочие прямо на производстве, чтобы оценить, насколько он удобен в эксплуатации.
Мы делаем упор на обработку данных на стороне клиента, то есть сервер отправляет только чистые данные и логику. Все графики, таблицы и визуализация делаются на устройстве пользователя.
Учтены и такие нюансы, как необходимость обработки больших объёмов данных, для этого мы используем сокеты. Данные обновляются в реальном времени и без необходимости полной перезагрузки страницы каждые несколько секунд. Кроме того, важно, чтобы пользователь мог ясно видеть, что соединение поддерживается и данные обновляются без задержек, чтобы избежать беспокойства или путаницы.
Нужно было суметь построить графики и отобразить наложение динамики в промежуток между показателями
В наших интерфейсах мы используем много видео высокого качества. На каждый производственный агрегат можно посмотреть в режиме трансляции. Например, вместо того чтобы смотреть только на график остывания стали, вы можете взглянуть на неё через камеру, установленную над печью, и увидеть, какого она цвета, сколько там шлака и так далее. Сейчас, благодаря сетям pLTE, которые доступны в некоторых цехах, передача видео улучшилась и на любой экран можно транслировать видео высокого разрешения в реальном времени без задержек.
Примерно 70 % рабочего времени у нас уходит на написание кода или его проверку. Около 20 % — посвящаем размышлениям и планированию, а последние 10 % тратим на детальное изучение и разбор конкретных задач. Мы регулярно посещаем встречи, на которых обсуждаем новые технологии, даже если они не связаны напрямую с нашим производством, но важны для понимания общих трендов в технологической индустрии. А также принимаем участие в мероприятиях и практиках внутри нашего профессионального сообщества.
Вот примерно так выглядит фронт на заводе. В следующей части статьи мы поговорим про использование генеративного ИИ для работы с дизайн-системой.
