Стайлгайд и компонентная разработка

"Мы не разрабатываем страницы, мы разрабатываем системы компонентов"
Стивен Хэй (дизайнер)
("We are not designing pages, we are designing systems of components" Stephen Hay)

Стайлгайд (от англ. styleguide) - это паспорт корпоративных стандартов. Руководство по использованию фирменного стиля, регламентирующее корпоративные цвета, шрифты, формы и блоки, размеры и расположение элементов. Это подробное описание дизайнерских решений для каждого элемента в отдельности и в случае необходимости вместе с другими компонентами.

Введение

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

Брендбук (англ. brand book) — официальный документ компании, в котором описывается концепция бренда, атрибуты бренда, целевая аудитория, позиционирование компании и другие данные, которыми руководствуется отдел маркетинга и руководители бизнеса для построения коммуникации с потребителями и развития компании в целом. Кроме этого, бренд-бук содержит полное руководство по фирменному стилю, которое включает в себя подробное описание использования каждого фирменного элемента на различных носителях, как рекламных, так и корпоративных. (с) википедия

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

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

Стайлгайды для разработчиков

Как было сказано ранее, у каждого языка программирования также существует свой стайлгайд, набор правил написания и оформления кода:

• Rails styleguide
• Ruby styleguide
• JavaScript styleguide
• HTML CSS styleguide
• Google HTML CSS styleguide
• ...

Но это очень узкоспециализированные стайлгайды. Что же они из себя представляют в более широком смысле? Какие функции они должны выполнять?

На примере KSS в прошлой статье я рассказывала о документирования CSS, но покрывает ли этот способ задания стайгайдов весь диапазон компонентов приложения?

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

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

В зависимости от вашего приложения они могут выглядеть совершенно по-разному:

Пример 1:


Пример 2:


Пример 3:


Пример 4:


Пример 5:

Преимущества стайлгайдов

1. Легко тестировать

Когда все компоненты находятся на одной странице очень просто заметить не влияет ли поведение одного компонента на другое, не перекрываются ли стили, насколько они сочетаются и вписываются в общую модель сайта. Легко тестировать их на различных платформах: мобильной, планшетной и десктопной. Для тестирования компонента не нужно переходить на сайт (иногда для этого нужно залогиниться пользователем с определенными правами и перейти на страницу, доступную по каким-то сложным условиям), здесь же достаточно заглянуть в стайлгайд, ибо он "живой" и отражает текущее состояние используемых компонентов.

2. Налаженный рабочий процесс

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

3. Общий словарь

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

4. Удобная ссылка

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

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

Разработка приложения через стайлгайд

Как выглядит процесс разработки приложений:

1. Выделение особенностей приложения

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

2. Разбиение на компоненты

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

3. Реализация и документирование

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

4. Сборка приложения

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

Заключение

Изначально эта статья планировалась только о styleguides, но разбираясь с ним все больше и глубже, понимаешь, что этот подход (разбитие на компоненты) очень хорош не только для стилей. Компоненты - это маленькие кирпичики, их которых строится все вокруг:

1. В функциональном программировании - это чистые функции. В ООП - это просто правильно написанные функции, небольшие, реализующие какой-то кусочек логики, но без сайд-эффекта, не влияющие на работу других функций и методов.
2. HTML: разбиение на преиспользуемые блоки: паршалы.
3. CSS: методология веб-разработки БЭМ (Блок-Элемент-Модификатор) или ее улучшенный аналог CSS Bliss. Оба подхода идеально вписываются в структуру компонентов. В Блиссе для каждого компонента создается отдельный файл с описанием стилей для этого компонента и вложенных элементов и модификаторов.
4. В дизайне компоненты - это элементы дизайна, из которых строится будущий макет. Так, например, как частный случай можно рассмотреть Bootstrap: набор предустановленных компонетов, таких как заголовки, кнопки, тексты, колонки, меню и проч. В более общем случае - это проектирование больших приложений из меньших составляющих, которые в свою очередь тоже состоят из более мелких. Это основная идея Атомарного дизайна, которую можно так же описать эпиграфом к этой статье известного дизайнера Стивена Хэя ("Мы не разрабатываем страницы, мы разрабатываем системы компонентов") и проиллюстрировать картинкой процесса создания дизайна:
   

Ссылки

• http://styleguides.io/ - огромная коллекция статей, инструментов, книг, подкастов и проч. по стайлгайдам
• набор стайлгайд-генераторов