Прочитав все статьи, просмотрев все выступления и использовав их в своих личных проектах, вы решили начать использовать Sass на своем рабочем месте. Поздравляем! Но теперь у вас есть задача реализовать это в вашей команде.
О, парень.
Эта статья поможет вам убедиться, что миграция проходит гладко. Это покажет, что переход к Sass — это не только Sass. Это также касается командной культуры и наилучшего использования поддерживающих технологий.
Но давайте проясним: я не буду рассказывать вам здесь, как должна быть построена ваша цепочка инструментальных средств. Я также не скажу вам, как написать свой Sass — это зависит от вас и будет уникальным для потребностей вашего сайта. Но я собираюсь предложить, как вы можете работать со всеми, используя одни и те же инструменты, и как это поможет вам лучше писать Sass.
открытие
Хорошо, давайте начнем с обзора того, что у вас уже есть. Нет, я серьезно. Слишком легко разбираться в своей кодовой базе, полагая, что вы все знаете, как она работает. Если вы еще не задокументировали это, сделайте это сейчас, даже в грубой форме обзора. Когда вы закончите миграцию, вы захотите показать, как далеко вы продвинулись, и, как вы увидите, это будет полезно позже.
Теперь собери свою команду и поговори о своем предложении Sass. Да, говорить! Ваша команда будет использовать ее, поэтому вы должны убедиться, что все понимают ваши намерения, и вам необходимо выяснить, что все понимают о современных методах. Я не могу подчеркнуть это достаточно. Не обманывайтесь хвастовством и не думайте, что молчание — это знание. Вы должны честно оценить, где каждый находится со своими навыками, прежде чем идти дальше.
Дружественный способ дать оценку состоит в том, чтобы заставить всех исследовать конкретную область и дать пятиминутный доклад о том, что они нашли, наряду с созданием демонстраций в таких местах, как Codepen или Sassmeister . Я знаю, я знаю, это кажется немного младшей школьной выставкой и рассказом. Но если вы расскажете о своих выводах и заставите всех поделиться своими комментариями и порекомендовать ресурсы, вы сможете оценить, кто в курсе, а кому нужна помощь. Что еще более важно, вы заставите людей владеть своими знаниями. Вы возьмете на себя коллективную ответственность команды, а не просто что-то для технического лидера, чтобы сообщить им и для их принятия.
Когда вы все говорите на одном языке и знакомы с одними и теми же понятиями, вы действительно можете начать планировать переход на Sass. Но сначала нужно разобраться с местным барьером развития.
Синхронизируйте свою среду
Иногда легко забыть, что Sass не CSS. Он использует аналогичные правила и синтаксис, но это полный язык программирования, который используется для компиляции в наш любимый язык таблиц стилей.
Точно так же, как разные версии Microsoft Word создают документы, которые не могут использоваться друг другом, можно написать Sass, который не может использоваться другими версиями. Это может произойти, если один из членов вашей команды использует другой компилятор Sass от всех остальных. В конечном итоге они будут писать код, который работает для их версии компилятора. Но если кто-то еще использует тот же код в другой версии компилятора, он (вероятно) выведет другой CSS.
Если повезет, просто будут небольшие отличия. Но если оригинальный автор использует функции, которые не доступны всем остальным, то он будет впечатляюще сломан, что вызовет проблемы для вашей команды.
Контроль пакетов
Ключом к тому, чтобы избежать таких сценариев, является стандартизация, и не только для самого Sass — вся ваша цепочка инструментов должна быть синхронизирована. Каждый должен использовать одни и те же инструменты, одни и те же версии инструментов и одинаковые версии этих же инструментов.
Взгляните на некоторые из различных типов инструментов в вашей цепочке инструментов:
- Системные менеджеры пакетов: apt-get, Homebrew, cygwin
- Языки: Ruby, Python, PHP
- Менеджеры языковых пакетов: Ruby gems, pip, pear
- Языковые рамки: Rails, Node.js, Drupal
- Менеджеры пакетов языковых рамок: npm, drush
- Менеджеры веб-пакетов: Bower, Yeoman
- Менеджеры задач: Grunt, Gulp, Brocolli
- Веб-библиотеки: jQuery, Modernizr
Если хотя бы один человек использует другую версию какой-либо из своих товарищей по команде, это может вызвать проблемы с компиляцией в дальнейшем.
Но не волнуйтесь, вы можете стандартизировать все. Это займет немного усилий.
- Версии системных языков могут быть стандартизированы с помощью таких инструментов, как Node Version Manager и rbenv , которые позволяют обходить версии, которые могут быть предварительно установлены в ОС.
- Каркас можно стандартизировать, указав номер версии при установке.
- После этого все, вероятно, может контролироваться установщиками пакетов уровня проекта, такими как Node npm и Ruby’s Bundler . Сценарий установки пакета может быть сохранен в системе управления версиями вашего проекта, а затем использоваться всеми.
Найдите время, чтобы найти лучший способ установки программ в вашей системе. Иногда менеджер пакетов системного уровня, такой как apt-get или Homebrew, является лучшим способом сделать что-то. Иногда лучше использовать менеджер пакетов для конкретного языка, например, npm. Нет двух одинаковых настроек!
Документ все
Поставьте себя на место члена команды, усевшись с недавно установленной машиной или аналогичной ей на виртуальной машине, и установив все необходимые инструменты. Документируйте каждый шаг на ходу — вы можете обнаружить некоторые удивительные пробелы в своих предположениях — и сделать этот документ доступным для всех. Запишите каждую установленную программу, убедившись, что вы указали используемые версии (и как установить конкретную версию). Затем предоставьте вашей команде доступ к чистым виртуальным машинам и дайте им возможность попробовать этот процесс. Они скоро дадут вам знать, если вы что-то пропустили.
Это стоит того
Если все это звучит слишком странно, помните, что в будущем вы сэкономите много головной боли, пытаясь выяснить, почему разные машины разработчика по-разному компилируются в CSS. Если вы все используете версию X пакета Y, работающую на версии Z определенного языка, то отладку будет намного проще.
Преобразование из CSS в Sass
Итак, наконец, мы добрались до сути вещей! Теперь, когда все используют одни и те же инструменты сборки, вы можете начать писать Sass как команду.
Вам не нужно переписывать весь свой CSS в Sass, прежде чем вы сможете начать использовать стандартную настройку. Вы можете просто переименовать все старые файлы .css.scss Надеюсь, вы должны закончить тем, что имели ранее. Возможно, это не главное достижение на поверхности, но оно показывает, что созданная вами цепочка инструментов работает. Дай пять! Позвольте новой системе работать в течение недели и убедитесь, что все компилируют один и тот же CSS.
планирование
Прежде чем вы начнете реорганизовывать свой Sass, вам понадобится еще один раунд планирования, на этот раз о том, как вы собираетесь структурировать свой Sass . (Вы можете начать это раньше, когда все знакомы с концепциями Sass.)
Опять же, делайте это как команда — не позволяйте одному человеку решать, как все будет построено! Документация сайта, которую вы сделали ранее, будет здесь неоценимой. Получить комнату, получить доску и ручки, и набросать. Подумайте, что нужно сделать и как это будет достигнуто.
Если вы еще не используете методы атомного проектирования, тогда этот этап планирования — хорошее время, чтобы начать думать об этом. Начните просмотр вашего сайта и базы кода для областей кода, которые можно объединить в компоненты. Вы можете продемонстрировать эти новые компоненты, получив руководство по стилю. Это не только отличный визуальный индикатор, показывающий, как проходит реструктуризация, но и позволит вам позднее провести визуальный регрессионный тест .
Не пытайтесь делать все сразу! Например, создайте задачу, чтобы создать все необходимые компоненты в виде пустых файлов, и зафиксируйте их в своем репозитории. Есть еще одна задача для частичного заполнения нового компонента, а затем еще одна задача для преобразования всего связанного HTML-кода, чтобы использовать новую структуру компонента и схему именования. Возьми это медленно. Запланируйте это. Не торопись.
В зависимости от размера вашей кодовой базы преобразование вашего CSS в эффективно используемый Sass может занять дни или недели. Сколько времени это займет, не имеет значения. Важно то, что вы спланировали это хорошо.
Строительство
Надеюсь, что фактическое преобразование в Sass будет скучно простым. Начните применять все те лучшие практики Sass, о которых вы читали и которые вы определили в своих сеансах планирования.
Вам нужно перейти на RWD во время сборки? Планируйте сохранение текущего макета с фиксированной шириной, пока вы переключаетесь на использование компонентов. Как только они на месте, затем переключитесь на использование адаптивного макета сетки.
Придерживайтесь своего плана. Не пытайтесь спешить. Убедитесь, что у каждого есть шанс внести свой вклад в вашу новую систему на основе Sass.
Техническое обслуживание и будущее
Через несколько недель после успешного перехода на Sass начните думать о внедрении более совершенных инструментов в цепочку инструментов и свой Sass. Например:
- Консолидация общих значений в переменные Sass: цвета, значения заполнения и т. Д.
- Используйте миксины для повторного кода.
- Sass linting — начните со спокойных настроек, а затем, по мере роста опыта вашей команды, начинайте увеличивать уровни ошибок.
Снова, планируйте это, и не спешите. Дайте себе время на исследования и найдите лучшие практики.
В заключение
Переход вашей команды на новую технологию, такую как Sass, — это не технология, а планирование, ожидание и эффективное использование имеющихся ресурсов.