Редизайн чужого фронтенда: когда токенами покрыто 4% стилей

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

Что показал замер

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

Ответ дали замеры, а не осмотр.

Токенами покрыто около 4% объявлений стилей. То есть система тем существовала формально: переменные есть, но почти ничего через них не задано.

Около 280 цветов прибиты прямо в коде. Это палитра основного бренда платформы, зашитая в правила. Переключение бренда её не трогает, и она проступает везде.

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

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

Больше сотни эмодзи вместо иконок. Эмодзи рисуются шрифтом операционной системы: на разных устройствах они выглядят по-разному и никогда — как часть фирменного стиля.

Эти цифры важнее любого обсуждения вкусов. Они объясняют, почему «просто поменять цвета» не работало.

Тематический слой вместо правки основы

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

Собрал этот слой генератором: описание темы и набор иконок на входе, готовый файл стилей на выходе. Генератор здесь не украшение процесса, а необходимость — руками поддерживать полторы сотни правил, каждое со скоупом, невозможно без ошибок.

Что в слое:

Палитра и шрифт из бренд-бука заказчика, с проверенным контрастом пар.

Замена эмодзи на встроенные векторные иконки. Больше сотни штук, одним стилем, с наследованием цвета от текста.

Перекраска модальных окон — отдельными правилами, потому что они живут вне области бренда.

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

Генератор заодно решает задачу повторяемости: тему можно пересобрать под другой бренд, поменяв описание, а не переписывая правила.

Граница между своим и чужим

Самая полезная часть работы — список того, что слоем стилей не чинится.

Есть вещи, которые нельзя исправить снаружи: разметка, где отсутствует нужный класс; компоненты, монтирующиеся вне области темы; тексты, зашитые в код. Их можно только переписать в основной базе.

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

Заодно это защищает от ситуации «мы заплатили за редизайн, а вот это место всё равно кривое». Оно кривое по известной причине, названной заранее.

Про референс заказчика

Заказчик показал сайт, который ему нравится, и попросил «так же». Здесь важно, что именно переносить.

Переносить стоит язык: типографическую пару, характер палитры, ритм отступов, отсутствие теней. Не стоит переносить вёрстку — у референса другой продукт, другая структура каталога и другие сценарии.

Копирование раскладки чужого сайта на свой продукт даёт результат, который выглядит знакомо и не работает: блоки не по размеру содержания, экраны под другой сценарий.

Что проверял вживую

Тема залита в живой стенд, дальше — замеры на нём, а не в редакторе:

Применился ли фирменный шрифт или подменился системным. Применились ли брендовые цвета там, где были хардкоды. Проходят ли контрастные пары норму. Как ведёт себя раскладка на узком экране.

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

Стенд превью как рабочий инструмент

Отдельно стоит сказать про способ работы, потому что он нетипичный.

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

Такая схема сначала кажется ограничением, а на деле удобна: правка проверяется на настоящем окружении со всеми чужими стилями, а не в изолированном песочнике, где всё выглядит хорошо и ничего не значит.

Минус один и существенный: цикл правки равен времени пересборки. Это отучает от привычки менять по одному значению и смотреть — приходится думать перед правкой и отправлять осмысленными порциями. Для работы с чужой кодовой базой это, пожалуй, даже к лучшему.

Частые вопросы

Почему просто не переписать стили платформы?

Потому что база общая для нескольких брендов, и правка в ней ломает остальных. Слой поверх — единственный способ изменить один бренд, не трогая другие.

4% покрытия токенами — это много или мало?

Это почти ноль. Работающая система тем начинается примерно с 70-80% объявлений через переменные. При 4% система тем существует на бумаге, а цвета живут в коде.

Чем плохи эмодзи вместо иконок?

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

Сколько живёт такой слой?

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

Как убедить разработчиков платформы принять список правок?

Формулировать их как конкретные места в коде с описанием следствия, а не как претензии к качеству. «Модалка монтируется вне скоупа, поэтому в ней чужая палитра» — это задача. «У вас плохая архитектура» — это спор.

Что делать, если бренд-бук противоречит доступности?

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

Коротко о главном

Прежде чем спорить о цветах на чужой кодовой базе, надо замерить, сколько в ней вообще управляется темой. Число вроде «4% покрытия и 280 хардкодов» объясняет проблему лучше любого обсуждения.

Дальше — слой поверх, собираемый генератором, и честный список того, что слоем не чинится и требует правки в основе.

Если у вас мультибрендовая платформа и один из брендов выглядит чужим — начните с замера покрытия токенами. Могу сделать этот замер и показать, что реально переключается, а что нет. Напишите в Telegram, MAX или VK.