Перейти к основному содержимому

Внедрение и управление

Проекты без design-системы​

Регламент не требует мгновенного рефакторинга всего UI, но запрещает ухудшать текущее состояние.

MUST​

  • Добавить минимальный централизованный слой:
    • файл UI-констант или набор CSS-переменных
    • базовый Icon компонент
  • Новый UI-код не содержит hard-code значений.

FORBIDDEN​

  • Добавлять новые "временные" hard-code значения.
  • Оставлять UI-код без централизованных базовых значений.

Правило нового кода (MUST)​

  • Весь новый UI-код использует дизайн-токены.
  • Используется единый Icon компонент.
  • Новый hard-code запрещён.

Пример

// ✅ Хорошо
<Button variant="primary" />

// ❌ Плохо
<button style={{ background: '#1b1b1b', color: '#fff' }}>Submit</button>

Правило "по касанию" (MUST)​

Если разработчик меняет компонент/стили/сценарий, он приводит затронутый участок к правилам design-системы без требования полного рефакторинга модуля.

✅ Хорошо

  • заменили локальный цвет на токен
  • перевели SVG на Icon компонент

❌ Плохо

  • добавили новый hard-code ради совместимости

Временные отклонения (MVP / small projects)​

Допускается​

  • не выносить токены в отдельный пакет
  • использовать ограниченный набор CSS-переменных
  • локально определить базовые цвета и типографику
  • простой Icon компонент без генерации типов
  • отсутствие SVG pipeline

Обязательные ограничения​

  • Запрещено хаотичное использование "магических" значений.
  • Значения централизованы в одном месте, а не размазаны по компонентам.
  • Новые hard-code значения не добавляются "на время".
  • Inline-стили и inline-SVG не используются без обоснования (например, анимация).
  • Упрощения не ухудшают консистентность интерфейса.

Когда возвращаемся к основным правилам​

  • рост проекта или команды
  • появляются требования к темам (light/dark)
  • планируется ребрендинг
  • UI используется в нескольких подпроектах
  • увеличивается количество повторяющихся компонентов

Управление изменениями​

MUST​

  • Изменения токенов и иконок согласуются с дизайном.
  • Изменения поставляются как версия (semver) с changelog.

SHOULD​

  • Депрекейшены объявляются заранее и имеют окно миграции.
  • Критичные изменения проходят через экспериментальную стадию.

Процедуры контроля (Code Review)​

Ревьюер должен убедиться, что:​

  • в новом UI-коде нет hard-code значений цветов/отступов/размеров
  • используются дизайн-токены или допустимые локальные UI-константы
  • новые значения не копируются из legacy-кода
  • иконки используются через Icon компонент
  • inline-SVG применяется только с обоснованием