Обычно мы имеем дело с развивающимися проектами: добавить то, убрать это, а то переделать. И обычно все нужно быстро. Я терпеть не могу, когда мне, в качестве рабочих заданий пытаются пропихнуть «размышление об архитектуре». Код, который не работает — протухает. Однако со временем, количество странного кода, технологического долга (из-за спешки) или решений-экспериментов начинают затруднять работу. Проект становится сложно поддерживать. Особенно вредна смена людей на проекте — разобраться в чужом коде в 10 раз сложнее, чем написать свой (актуально для проектов, которые сложнее чем сайт-визитка).

Рефакторинг — это переработка и оптимизация кода (или дизайна), когда из разрозненных решений мы делаем красивую систему. Это как точить пилу — можно и тупой поработать, но КПД будет так себе. Есть, правда, любители точить пилу до усрачки, ничего ей не делая. Вот за это нужно давать по рукам. Итого: как только мы видим, что команда буксует — возможно дело в наслоениях кода.

Как его делать? Мы составляем план рефакторинга — список самых заскорузлых мест, которые нас самих пугают. Делаем оценки в часах. Проверяем целесообразность (в том числе экономику) рефакторинга (к сожалению, тут формулы я не придумал, только опыт и эмпирика). И по чуть-чуть начинаем внедрять изменения в продукт. Общее правило такое: рефакторится тот участок кода, который требует рефакторинга и с которым команда работает в данном спринте. Это хорошее правило (работает — не трогай), поэтому какие-то вещи могут долго оставаться нетронутыми, хоть они и требуют рефакторига (эстетически), но функцию свою выполняют. Например, какой-нибудь импорт: там вроде бы все сложно, но он работает, а задач по его обновлению нет — значит, пока не трогаем.

Примерно так же можно чистить и рефакторить дизайн проекта, документацию или даже рабочие процессы команд.

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

Когда я впервые делала дизайн для Portobello, то ощутила на раскопках: у проекта было штук 7 стилей чекбоксов. Сколько дизайнеров проект трогало, столько стилей и образовалось. Найти актуальный было невозможно, потому что верстка кодом нарисовала его сразу на сайте.

Эта система была моей первой :) И хотелось сделать не какую-то лайтовую, а осмысленную инструкцию, где даже интенсивность теней логически зависит от элементов. По ходу правок к системе подключался наш другой дизайнер и отзыв был положительным — он в 2 раза быстрее закончил свою часть сборки! Тем и хороша дизайн-система: почти любой компонент создается копипастом. То есть, дизайнер, не причастный к системе, легко сориентировался на новом для себя проекте.

Дизайн-система дала нам возможность навести идеальный порядок в процессах проектирования интерфейса сайта. Новые страницы и разделы готовятся в разы быстрее. Для разработчиков — это рай: единые стили, никакого пиксель-перфекта при верстке — можно положиться на уже выверенные отступы.

Особую «радость» работы без дизайн-системы ощутили на иконках. Изначально рисовали их под web: бразуеры умеют обрабатывать картинки формата svg и рендерить их, iOS и Android — нет, у них свои четкие требования. Подогнать иконки под нужные размеры — даже не полдела. Размерность тянула за собой искажение их визуального восприятия и юзабилити. В итоге перерисовывали иконки 3 раза, а их 140 штук.

Это не единственное, что сподвигло нас на создание дизайн-системы. И то, что мы проживаем на своей шкуре, пополняет чек-лист для дизайнеров.

Я заметил, что дизайн-системы хоть и призваны стандартизировать все и вся, но в реальности только добавляют хаоса. В дальнейшем подключать дополнительных людей к проекту с дизайн-системой — это саморучно «расшатывать» сформированные в ней правила. Бить палками за ошибки тут сложно: чтобы найти эти ошибки, нужно потратить уйму времени. Не думаю, что кто-то из маленьких компаний может финансово позволить себе содержать и поддерживать дизайн-систему в порядке (подойдет UI-кит). Однако, если на продукте десятки или сотни экранов, над которыми трудятся разные команды, дизайн-система — это хоть какой-то шанс управления хаосом. Голову при этом никто не отменял!