2 заметки с тегом

оптимизация

Синхронизация команды и работа над общими исходниками

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

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

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

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

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

Открывая оригинал — вы рискуете по неосторожности испортить чужой исходник не заметив этого. Зачем потом тратить время на поиски и исправления подобных курьезов?

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

В этом скриншоте видно, что в проекте уже теперь две папки — появилась Sedisheva

4. Архив без мусора

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

Дубликаты, которые нужны только для открытия и копирования отдельных данных лучше переименовывать для отличия.

5. Читаемость исходника

То, насколько легко вы или любой другой участник команды сможет сориентироваться в исходнике зависит от ряда важных моментов:

  1. Как выставлены имена артбордов и групп
  2. Есть ли порядок в рабочей области
  3. Как построена работа с листами
  4. Где хранятся утвержденные и не утвержденные макеты.

Про имена

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

Для отображения разных состояний одних и тех же экранов в нумерации дописывается алфавит.
01. Название экрана — Деятельность на нем
01а. Состояние А
01б. Состояние Б
02. Название экрана — Деятельность на нем

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

1-01. Флоу 1
2-01. Флоу 2
3-01. Флоу 3

Порядок в рабочей области

Хорошим тоном считается нормальная сетка из артбордов. Помимо того, что она радует глаз, так же легко «читается», а главное создает четкую структуру в хаосе драфта из кучи версий.

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

Для отображения нескольких флоу на одном листе я пользуюсь визуальным разделением.

Работа с листами

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

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

Утвержденные и не очень макеты

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

Я стараюсь располагать весь драфт на отдельной странице и копировать оттуда последние версии макетов в проектные страницы. Чтение версий драфта чаще всего происходит слева направо, сверху вниз, а для групп экранов просто сверху вниз, т.е самые свежие макеты расположены всегда правее и ниже всех остальных.

 26   2017   оптимизация   организация   работа

Структура хранения проектов

cover! white

О том, как больше не мучать себя беспорядком в рабочей папке и находить проект со скоростью обслуживания болида на пит-стопе

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

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

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

Не усложняй

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

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

Базовые правила

  1. Должен быть универсальный шаблон для новых проектов;
  2. Каждый проект хранится в отдельной папке;
  3. Имя папки должно содержать имя клиента и проекта;
  4. Все файлы, относящиеся к проекту разбиваются на 5 категорий и хранятся в соответствующих директориях;
  5. Версии рабочего файла идут через двойную нумерацию с префиксами -001-01, -002-01 и т. д.;

Шаблоны

Для экономии времени на организацию каталога в новом проекте, использую папку-шаблон _Inc Project. Нижний слэш переносит папку вверх списка.

В ней хранятся ряд других папок, для дополнительных файлов:

Approved — Финальные файлы, на передачу;

  • Data — Для документации, заданий и исходников высланных клиентом;

Revision — PNG макеты для обсуждения и комментариев. Если проект идет в сбор на Invisionapp, каждую итерацию правок я сохраняю в поддиректоритою с указанием даты и времени. Например, «2016-05-17 13.20»;

  • Source — содержит в себе все данные, которые я нашел для данного проекта или посчитал интересными: Скриншоты, ссылки на сайты-примеры, фотографии с фотостоков. Все это опять же сортируется в поддиректории buy, search, url.
Помимо папок, корень содержит в себе еще два файла-шаблона для Illustrator и Sketch и служит основной директорией для рабочих файлов.

Ранее для рабочих файлов я использовал папки с именами WIP (work in progress), затем просто work, пока не понял что эту папку использовал строго для того чтобы файлы не пошли вперемешку с остальными. А раз все прочие уже раскиданы по другим дополнительным папкам, то зачем делать лишние телодвижения и двигаться в отдельную папку, когда корень проекта идеально подходит для основных исходников?

Имена файлов

Все достаточно просто. Люди придумали много вариантов того, как называть файл (особенно для верстки), но я как человек чаще творящий и значительно реже верстающий (и то сугубо для своего бложика) никаких особых правил по именам не придумывал.
Их всего 3:

  1. Называть файл понятно и доступно: call-me-latter.psd — значит картинка для блока «перезвонить» на сайте;
  2. Приоритетный файл проекта включать вверх нижним слешэм, вспомогательным исходникам давать простые имена;
  3. Использовать дедуктивный метод сортировки, в котором первое число — итерация для клиента, а второе — личная.
Проект прошел одну итерацию с заказчиком. Его имя _store-new-tp-002-02.ai

Сортировка проектов

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

Затем стал заводить одну общую папку для конкретного клиента и уже в ней держал проекты, а в начале писал дату формата гггг-мм.
При обслуживании постоянных клиентов это обретало смысл. Хотя сейчас понимаю, что достаточно было просто писать версию «переиздания», а не ссылаться на даты.
Ниже можно наблюдать структурирование папок с 2009 по 2016 года.

Структура образца 2009-11, когда было все раскидано по годам. В 11 году начал добавлять папку Source. Структура была старой, как в прошлом слайде. Позже в 2012 году просто навел порядок. Ближе к концу 2012 составил полный список папок. В 2013 список папок утвердился до необходимого минимума. 2016, Обновленная структура папок. Удалена папка WIP, которая до удаления уже звалась work.
В качестве примеров прилагаю скриншоты папки клиента SDI Solution. Именно тут видно как я пробовал различные варианты и отказывался от разных функций.

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

Кто-то спросит: Зачем в папке имени проекта фигурирует имя клиента?
Ответ: Папка с конкретным проектом, отправленная по почте теряет часть структуры и начинается боль, если таких папок больше чем одна. Я сохранил однажды на флешку несколько проектов от разных клиентов, а имена папок были «A4 акция» и «А4 + Диск», ругался на себя пока не надоело путаться и не переименовал папки по-человечески.

Сортировка папок

Итак, с внутренними папками клиентов мы разобрались. А как быть, когда число клиентов перешло за первую десятку?

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

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

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

 11   2016   оптимизация   организация   работа