State Machine, дизайн-система и трудности перевода приложений: как прошёл первый день IT-конференции «Сибирь.JS»

Дата публикации: 4.07.2022

IT-конференция по JS-разработке — первая конференция для JavaScript-разработчиков в Омске от Purrweb, на которой выступили спикеры из крупнейших компаний России. 

JavaScript — один из самых популярных языков программирования в мире. Он используется для создания веб-, мобильных, десктопных и серверных приложений.

Этот язык начал свой путь в браузере, чтобы добавить интерактивности вебсайтам, то есть, в сущности, как безделушка, а сейчас на нём пишут огромные enterprise-системы. Популярность этого языка программирования требует аккумулировать сообщества, чтобы помочь разработчикам делиться опытом и идеями. 

Руководитель направления ивент-маркетинга Purrweb Екатерина Лапицкая уже говорила ранее «Трамплину», что цель конференции — собрать js-сообщество

В этом материале мы расскажем, о чём говорили спикеры, приглашённые из VK, «Яндекса», «Самоката» и других крупных компаний в первый из двух насыщенных мероприятиями дней JS-конференции.

Всё проходило на четвёртом этаже офисного центра Festival City. На входе мудрый охранник подсказывал, какой турникет разблокирован для прохода, а уже на этаже, оккупированном JavaScript, участников ждали организаторы. 

Purrweb подготовили качественный и запоминающийся мерч: мягкие игрушки, в том числе голову гуся от GreenHouse, фирменные футболки, стикеры и море других тематических сувениров. 

Гастрономическими партнёрами мероприятия стали ресторан «Шато» и компания по доставке продуктов Domka, так что участники были не только сытыми и довольными, но и не чувствовали чайно-кофейно-печенюшечного дефицита. 

Открыл конференцию технический директор Purrweb Сергей Пономарёв. Он рассказал, что за зверь State Machine (машина состояний — прим. ред.) и зачем она вообще нужна. 

— Состояния неоднородны и неравны, поэтому мы должны постоянно следить за ними, обрабатывать и исключать неработающие. 

Например, мы начинаем работать на React и используем такие условия: если дверь заперта, делай это, если открыта — другое. Здесь не бывает состояния, где дверь заперта на ключ, но открыта, вот в чём проблема. 

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

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

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

Используя этот инструмент, мы можем создавать иерархию состояний, запускать состояния в параллели и ограничивать их условиями, обрабатывать данные. Здесь есть action’s, контекст и возможность добавлять внешние данные. xState очень обширен, у него много возможных состояний, а значит, и много возможностей.


Старший разработчик интерфейсов Яндекс.Дзен Семён Левенсон поделился своим опытом внедрения дизайн-системы.

— Дизайн-система — задокументированные договорённости, налаженная коммуникация, понятные процессы и артефакты. 

Мы решили сконцентрироваться на базовых цветах, начали что-то делать. История не сработала, потому что основные задачи занимали слишком много времени. Когда появилась продуктовая задача реализовать тёмную тему, хотелось, чтобы при реализации мы оперировали не магическими цветами, а скорее семантической историей. 

Шаг 1. Формирование команды. 

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

Шаг 2. Создание токенов. 

Дизайнер собрал фиксированную и семантическую палитры цветов.

Мы делали группировку одинаковых цветов, потому что один цвет можно выразить по-разному. Хотелось привести всё к общему знаменателю. Я сгруппировал все библиотеки и получилось 612 цветов.

Всё это многообразие нужно было свести к семантическим токенам. 

Шаг 3. Сравниванием цвета. 

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

0 — точное совпадение, 100 — абсолютно разные цвета.

Я накидал дашборд и смотрю, что есть что-то странное: расстояние 4.2, но цвета вообще не похожи. Тут проблема в том, что все формулы не работают с альфа-каналами, потому что это четвёртая проекция, ещё одна единица измерения. 

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

Шаг 4. Сделать поиск.

Достаточно было сделать ещё одну страничку, которая указывала рандомный цвет. Так выводится фиксированный цвет и семантические пары.

Шаг 5. Ускорение прогресса.

Вот мы нашли ближайший цвет и прокидываем его в код. Но не всё так просто. Что, если совпадение не точное? А что, если семантических токенов несколько? А если замена опасная? Мы же не можем гарантировать, что подложка нормально отреагирует на альфа-канал.

Шаг 6. Мелкие шаги.

Мы на мастере делаем все изменения в один пул-реквест, распределяем по папкам и группы. Получилось 76 пул-реквестов. 

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

Получился интересный сайд-эффект в виде обучения. Пул-реквесты распылялись на всех в Дзене. Так все узнали, что токены внедряются, и они учились с ними работать. Ну, и нам попадались релевантные ревьюверы. 

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

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


Руководитель команды в VK Сергей Володин рассказал о трудностях перевода в интернациональных приложениях.

— У нас есть сервис, который поддерживает множество языков. Наша задача как сервиса — найти сочетание языков и показать более релевантный. Для этого нужны идентификаторы, например, BCP 47. Он вводит ленгвич-тайтлы. Так первым идёт язык, потом регион, например, en-US. 

Следующая задача — понять, какой язык какому пользователю показывать. Можно показывать по регионам, можно дать по выбору пользователя, но бывают ситуации, когда уже при регистрации нужно показать язык. Но есть Accept-Language, которому передаётся список локалей, и мы со стороны сервиса можем проанализировать более релевантный локаль или просто показать английский язык. 

Переводить текст можно машинно или с помощью людей. В первом случае сложно передать контекст. Мы работаем с людьми, поэтому мы не можем дать доступ к репозиториям. У переводчиков есть интерфейс, в котором они будут переводить локали.

Первая сложность — лингвистические различия. Например, плюральные формы: 1 письмо, 1 letter, 2 письма, 2 letters. 

Есть CLDR — проект с языками и локалями с описанием правил и историями употребления языка, склонений и применения.

В JS есть поддержка Ecma 262, поэтому он знает, как формируются плюральные локали.

Можно пользоваться системой библиотек Format.JS, там есть интеграция с библиотеками и фреймворками для рендеринга.


Senior full stack developer, ведущий подкаста «Веб-стандарты» и автор YouTube-канала «Девшахта» Андрей Мелихов о Node.JS фреймворках.

— Изначально у нас был классический Express, а позже подключались middleware и бизнес-логика. 

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

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

Мы раздробили код по командам, но так мы сделали множество маленьких монолитов. Команды писали как попало, ничего не изменилось, кроме появления типизации. 

Прежде чем приступить к работе на JavaScript, прочитали всякие умные книжки. Нам в любом случае была нужна чистая архитектура, чтобы обеспечить независимость бизнес-кода от фреймворка. Мы выбрали nest и писали на нём. У него под капотом как раз был Express. 

В итоге сделали микросервисы на nest: Typescript, DDD, дискоганальная архитектура, монада Either.

Мы всё это внедрили, но были и проблемы. Во-первых, высокий порог входа, из-за которого люди с React ничего не понимали и их было тяжело учить. Декораторы — самая опасная проблема, потому что мы использовали экспериментальные декораторы из Typescript. 

Есть и архитектурные проблемы. Например, у него нет внутри инверсии зависимостей. Бизнес-логика говорит: у меня есть такой вот адаптер, через который вы что-то подключаете, и у вас один логгер. Второй логгер идёт по такой же схеме. Бизнес-логике неважно, она знает только интерфейс.

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

Спасибо, что прочитали материал до конца. В ближайшее время выйдет второй репортаж с конференции «Сибирь.JS».

Автор: Ярослав Загородников

Фотографии предоставили организаторы

Поделиться:
Появилась идея для новости? Поделись ею!

Нажимая кнопку "Отправить", Вы соглашаетесь с Политикой конфиденциальности сайта.