Меня часто спрашивают, как я структурирую файлы CSS для проектов, почему я делаю что-то определенным образом и почему я так тщательно отношусь к процессу Git. У меня есть опыт разработки проектов с такими CMS, как WordPress, Drupal и Magento E-commerce. Я также создавал собственные решения для приложений PHP, созданные с помощью Codeigniter и Laravel. И, наконец, я реализовал приложения Javascript с помощью React, Vue и Angular в проектах. У меня так много опыта, которым я хотел бы поделиться с вами.

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

Как мне лично структурировать файлы CSS для проекта?

Когда вы вводите соглашение об именах каталогов CSS для своей команды разработчиков, это часто сбивает с толку. Мысль такова: зачем усложнять поиск вещей с помощью CSS? Если вы задаете себе этот вопрос, то позвольте мне задать вам его в ответ. Почему все ваши компоненты находятся в отдельных файлах? Это та же самая причина, по которой CSS должен быть разделен для простоты определения того, где находятся изменения, чтобы позволить объектно-ориентированное программирование и уменьшить вероятность конфликтов слияния.

Лучшее, что я испытал, — это разделить структуру вашего проекта. Я начинаю с шаблона именования папок 7–1. Если вы работаете с CMS, ограничьте структуру папок CMS. Например, в Drupal у вас есть блоки, представления, узлы, страницы и т. д. Эти термины относятся к CMS. Поэтому, если я пишу стили для представления, я собираюсь создать файл в каталоге представлений моего проекта SASS только для этого представления. Поэтому я бы получил эту структуру папок:

sass/
база/
блоки/
узлы/
макет/
страницы/
представления/

Теперь, если бы я работал с приложением Javascript, моя структура сгиба была бы другой. Это было бы более компонентно-ориентированным, но придирчиво следовал бы Шаблону 7–1. У каждого компонента будет свой собственный файл SCSS, чтобы они были полностью изолированы от других компонентов. У них будут общие стили, но это когда вы помещаете глобальные или общие стили в определенные файлы. В случае шаблона 7–1 компоненты — это компоненты HTML DOM, а не компоненты вашего приложения. Я создаю новый каталог с именем элементы и помещаю в него свои элементы компонентов HTML.

sass/
аннотации/
основа/
компоненты/
элементы/
макет/
страницы/
поставщики/

Как видите, паттерн 7–1 — хорошее начало, но вам следует изменить его, чтобы использовать аналогичные соглашения об именах для вашего проекта. Нет правильного или неправильного способа сделать это, потому что, в конце концов, все эти файлы все равно будут скомпилированы в мини-файл CSS. Это скорее личное или командное предпочтение того, как вы хотите организовать свои файлы SCSS.

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

«Стремитесь к постоянному совершенствованию, а не к совершенству».

Так верно, потому что всегда есть лучший способ сделать что-то, вам просто нужно понять, как это сделать.