1. Обзор
В процессе реализации проекта я столкнулся с проблемой растущей сложности управления цветами и стилевыми переменными в системе стилей на основе SCSS. Сначала было достаточно простого объявления переменных, но с увеличением масштаба сервиса и добавлением разнообразных UI-компонентов роль переменных стала неясной, а количество дублирующих определений возросло.
Особенно в структурах, где несколько сервисов используют общие пользовательские интерфейсы, возникали случаи, когда одинаковые цвета использовались под разными названиями, что приводило к снижению удобства сопровождения и эффективности совместной работы. С точки зрения дизайн-системы, «ценностная» структура также имела свои ограничения, и возникла необходимость в реконструкции на основе токенов значений.
В связи с этим существующая структура SCSS-переменных была переработана в структуру на основе дизайн-токенов, и система была重新 спроектирована с целью улучшения удобства сопровождения и расширяемости.
Также ранее определения стиля были перемешаны внутри компонентов, что затрудняло управление общими стилями. По мере увеличения требований для различных сервисов в одних и тех же компонентах стало много стилей, и возникла проблема низкой читаемости кода. Чтобы решить эту проблему, мы начали рассматривать возможность управления общими дизайнерскими стандартами на уровне токенов.
2. Проблемы существующей структуры
Существующая структура переменных управлялась названиями, близкими к фактическим значениям цвета, таким как --gray200, --primary600. Хотя этот способ обеспечивал быструю первоначальную разработку, с увеличением масштаба проекта возникало множество проблем.
Первое — это ограниченность передачи смысла. По имени переменной было трудно определить, является ли данный цвет для текста, фона или границы. В результате интерпретация могла различаться у различных разработчиков, что также увеличивало затраты на коммуникацию в процессе совместной работы.
Второй проблемой была проблема дублирующего определения. При разработке нового интерфейса стало больше случаев, когда вместо повторного использования существующих цветов новые подобные цвета определялись снова. В этом процессе последовательность дизайн-системы постепенно ослаблялась.
Третьей проблемой было увеличение затрат на обслуживание. Бывали случаи, когда при изменении определенного цвета было трудно определить область его влияния, что приводило к неожиданным изменениям интерфейса. Особенно неэффективным был процесс отслеживания влияния переменных, используемых в общих компонентах.
Также, с увеличением количества настроек стиля на уровне компонентов, возросла вероятность конфликтов стилей. По мере увеличения масштаба проекта только на основе системы переменных стало трудно обеспечить стабильное управление, и понадобилось более структурированное проектирование.
3. Направления улучшения
Чтобы решить указанную проблему, мы перешли от простой системы на основе значений к системе дизайнерских токенов, ориентированной на смысл. Токены разработаны в трехуровневой иерархии: Primitive, Alias, Semantic.
3.1 Примитивный токен
Primitive Token выполняет роль определения истинных цветовых значений. Например, управляет реальными HEX-значениями, такими как серый и основной.
3.2 Псевдоним токена
Alias Token определяет роль цвета. Например, текст, граница, фон и т.д. были сгруппированы для управления по смысловым единицам.
3.3 Семантический токен
Семантический токен - это этап, который применяется к фактическим элементам пользовательского интерфейса. Определены токены, которые используются на уровне реальных компонентов, такие как цвет фона кнопки, рамка карточки, сообщения о состоянии и т.д.
Благодаря этой структуре стало возможным управлять стилями на основе значений, а не просто значениями, что позволило более систематически управлять общим пользовательским интерфейсом и интерфейсом конкретных сервисов.
Также благодаря иерархической структуре токенов была создана основа для гибкого реагирования на расширение тем проживания темной темы или темы, специфичных для сервиса. Ранее при изменении цвета нужно было редактировать код по всему проекту, но в текущей структуре достаточно изменить только определенный уровень, чтобы это было последовательно отражено во всем интерфейсе пользователя.
4. Процесс применения
В процессе внедрения структуры токенов мы не просто изменили названия переменных, а переработали всю стилистическую структуру на основе реальных целей использования.
Сначала мы провели полный аудит существующих переменных SCSS, чтобы проанализировать, на каких экранах и компонентах они используются. На основе этого мы провели повторную классификацию по смысловым единицам.
Также была разработана модульная система с использованием @use и @forward в SCSS. Каждый слой токенов был разделен по файлам, а структура импорта была объединена через _index.scss. Это позволило четко определить зависимости и улучшить возможность явного использования только необходимых токенов.
Поскольку замена всего кода сразу оценивается как рискованная, была выбрана стратегия постепенного применения. Первоначально она была применена к новым страницам и областям, требующим изменений, а переход был осуществлен плавно в сочетании с существующим кодом.
Также мы в сотрудничестве с командой дизайна разработали правила именования токенов и задокументировали общие критерии. Этот процесс стал не только улучшением кода, но и значительно помог в упорядочивании процессов совместной работы.
В процессе реального применения мы многократно проводили QA дизайна, чтобы подтвердить диапазон применения токенов. В частности, стили, применяемые к общим компонентам, используются одновременно в нескольких сервисах, поэтому даже небольшие изменения могут повлиять на весь интерфейс, что требует тщательной проверки.
5. Улучшение эффекта
Наиболее значительно улучшенные аспекты после применения структуры дизайн-токенов – это удобочитаемость и эффективность совместной работы. Благодаря семантическим токенам стало возможным интуитивно понимать роли только по именам переменных, а коммуникация между дизайнерами и разработчиками стала более ясной.
С точки зрения обслуживания это также оказало эффект. Если изменить цвет определенного интерфейса, достаточно изменить лишь соответствующий семантический токен, и это последовательно отразится на всей стилистике. Теперь можно быстрее понимать область изменений, и неожиданное появление побочных эффектов сократилось.
Масштабируемость также значительно улучшилась. При добавлении новых компонентов можно было разрабатывать их с использованием существующей структуры токенов, обеспечивая согласованный подход, а также стало легче поддерживать единообразие дизайна между сервисами.
Дополнительно, была обеспечена возможность расширения тем для темной темы или по отдельным сервисам. Ранее значения цветов были разбросаны по коду, что затрудняло изменение тем; однако в текущей структуре теперь можно гибко реагировать, просто отрегулировав этапы Alias и Semantic.
Прежде всего, общие дизайнерские стандарты позволили новым сотрудникам быстро понять структуру проекта, когда они присоединяются к нему. Это принесло положительный эффект не только с точки зрения эффективности сотрудничества, но и с точки зрения стабильности проекта.
6. Выводы и размышления
Этот рефакторинг стал не просто упорядочиванием переменных, а опытом пересмотра структуры с точки зрения дизайнерской системы. Особенно я осознал, что только управляя стилями не по принципу «значений», а по принципу «смыслов», можно одновременно обеспечить поддерживаемость и расширяемость.
Также в процессе проектирования структуры токенов я снова осознал важность стандартов сотрудничества и правил именования. Дизайн-система — это не просто набор стилей, а общепринятый язык, который используется всей командой.
В будущем мы планируем применять ту же структуру токенов не только к цветам, но и к различным элементам дизайна, таким как расстояния, типография, радиусы, тени и т.д. Мы стремимся создать более систематичную и масштабируемую среду для дизайн-системы.
В ходе этой работы я смог увидеть важность проектирования структуры с учетом долговременной поддерживаемости и расширяемости, а не просто сосредоточения на простой реализации. В будущем я также намерен рассматривать проекты с точки зрения общей системы и стремиться к созданию более стабильной среды пользовательского интерфейса.
nature