Синхронизация команды и работа над общими исходниками
На написание данной инструкции меня побудила работа во множестве различных команд за последний год. Обилие разношерстных составов и задач создали необходимость к единому структурированию данных, иначе бы я больше бы путался, чем работал.
В ходе работ над совместными проектами были найдены, отрепетированы и составлены правила описанные ниже. Благодаря им отпали частично или полностью проблемы с синхронизацией. Искренне надеюсь, что эти правила помогут и вам.
Все правила легко применимы к исходникам с поддержкой артбордов и не требуют особых усилий к запоминанию, потому что являются логичными.
Не смотря на то, что описанные подходы уже используются и проверены временем, заметка будет обновляться по мере нахождения более эффективных приемов работы.
1. В проекте нужен «Мастер»
Задача Мастера в том, чтобы заниматься слиянием исходников (синхронизацией). Хотелось назвать его библиотекарем, но в продуктовых командах — библиотекарь это отдельный исполнитель, занимающийся исключительно библиотекой и гайдлайнами.
Слиянием может заниматься каждый участник команды, но Мастер нужен именно для того чтобы избежать путаницы, сократить трату времени на вникание в работу и обрести дзен.
2. Версии файлов заменяем датами
Новый день работы начинается с дубликата папки с самыми актуальными исходниками. Таким образом вы сможете откатиться обратно или восстановить хронологию действий, если этого потребует проект в любой удобный для вас момент.
Формат имени папки строится на привычном дедуктивном методе:
«Project-name-yyyy-mm-dd». Где имя может содержать дополнительную информацию, например «АЕ Анимация иконок меню». Это нужно для более быстрого поиска работ.
Папка нужна для того чтобы в ней хранить временные файлы и избавиться от бардака в общей папке проекта. Иногда требуется делать экспорт картинок, PDF или дополнительные работы: например, если делаем анимацию в АЕ, то большое число файлов неизбежно.
Изредка, случается, что необходимо иметь две разных версии в один день. Тогда рекомендуется дописывать версии и пояснять их при необходимости:
Project-name-yyy-mm-dd ver-1
Project-name-yyy-mm-dd ver-2
Поскольку мы полностью в курсе только тех изменений, которые произвели сами, необходимо следовать следующему правилу
3. Чужие исходники не трогать
Совместная работа над проектами подразумевает наличие исходников-дубликатов. Если вам необходимо взять исходник другого участника команды — берите его дубликат, а оригинал не трогайте.
Для удобства работы рекомендуется исходники делить именами, например:
Project-name-yyy-mm-dd User 1
Project-name-yyy-mm-dd User 2
Открывая оригинал — вы рискуете по неосторожности испортить чужой исходник не заметив этого. Зачем потом тратить время на поиски и исправления подобных курьезов?
Если один из дизайнеров привлекается к проекту периодично, то для удобства поиска его исходников рекомендуется хранить все его исходники в отдельной ветке.
Тогда папка проекта содержит в себе сначала каталог участников, а затем личный архив исходников по датам.
4. Архив без мусора
В актуальной папке дня рекомендуется держать только те файлы, которые претерпели изменения. Это позволит при необходимости быстро совершить откат, а не перебирать кучу дубликатов в поисках прошлой версии.
Дубликаты, которые нужны только для открытия и копирования отдельных данных лучше переименовывать для отличия.
5. Читаемость исходника
То, насколько легко вы или любой другой участник команды сможет сориентироваться в исходнике зависит от ряда важных моментов:
- Как выставлены имена артбордов и групп
- Есть ли порядок в рабочей области
- Как построена работа с листами
- Где хранятся утвержденные и не утвержденные макеты.
Про имена
Давайте нумерацию артбордам. Наличие порядковой нумерации сокращает издержки при поиске нужных экранов и синхронизации их со сторонними сервисами (например InVision). Работа с сервисами по прежнему связана с рисками неверной или частичной загрузки контента, которую проще отследить по легким отличительным чертам в именах.
Для отображения разных состояний одних и тех же экранов в нумерации дописывается алфавит.
01. Название экрана — Деятельность на нем
01а. Состояние А
01б. Состояние Б
02. Название экрана — Деятельность на нем
Я так же пользуюсь нумерацией для проработки разных флоу. Получается двойная нумерация, но ничего страшного в этом нет.
1-01. Флоу 1
2-01. Флоу 2
3-01. Флоу 3
Порядок в рабочей области
Хорошим тоном считается нормальная сетка из артбордов. Помимо того, что она радует глаз, так же легко «читается», а главное создает четкую структуру в хаосе драфта из кучи версий.
Когда создание отдельных страниц становится нецелесообразным, а разделение групп крайне необходимо, приходится поступать вот так.
Работа с листами
Разделение проекта на страницы — значительно упрощает работу. Например, использование отдельной страницы для GUI поможет сократить временные издержки на перемещение от экрана с которым работаете до GUI с которого необходимо взять нужный объект.
Каким образом будет разрастаться структура проекта — необходимо решать индивидуально. Иногда удобнее держать все в одной странице, потому что экраны между собой мало отличаются.
Утвержденные и не очень макеты
Макеты, которые еще не прошли этап утверждения и находятся в редактуре должны быть отличимы. Они или располагаются отдаленно и разделяются визуально, как это было на скриншоте выше с разными флоу, или же хранятся на другой странице. Важен лишь факт разделения.
Я стараюсь располагать весь драфт на отдельной странице и копировать оттуда последние версии макетов в проектные страницы. Чтение версий драфта чаще всего происходит слева направо, сверху вниз, а для групп экранов просто сверху вниз, т.е самые свежие макеты расположены всегда правее и ниже всех остальных.
