Большие команды разработчиков могут ' не могу справиться с одной таблицей стилей CSS?
В настоящее время я работаю в 5-7 большой команде разработчиков, создающей действительно большой веб-сайт с большим количеством страниц и функций.
Я чувствую, что мы находимся в такой ситуации, когда разработчик может изменить таблицу стилей в соответствии со своими потребностями, но не знает о 1000 местах, где он, вероятно, изменит ее на что-то другое. Я также не могу винить его, так как знаю, что все сложно проверить.
Это полный беспорядок.
Я знаю, что использование одного файла таблицы стилей экономит полосу пропускания и предотвращает дублирование кода и обслуживание, но я не могу не задаться вопросом - Использование таблиц стилей хорошая идея для больших сайтов, или он должен быть более ориентирован на объект / элемент.
Допустим, вы забыли о безумно большом CSS и вместо этого определяете CSS для каждого элемента. Поэтому каждый раз, когда вы визуализируете GreenBuyButton, на нем отображается «style = 'bla bla bla'". И это в значительной степени сделано для всех элементов.
Это увеличит пропускную способность, но не создаст дублированный код.
Может ли это быть хорошей идеей или как действительно большие команды работают на одном сайте с CSS чтобы не было путаницы?
4 ответа
Я бы порекомендовал вам использовать правила CSS для специфики, чтобы помочь вам. Для каждого CSS, который не является глобальным, включите селектор активации, например
.user-list .p {
font-size: 11pt
}
.login-screen .p {
font-size: 12pt
}
. Это позволит легко определить, какие правила для каких страниц и какие правила являются глобальными. Таким образом, разработчики могут придерживаться своего собственного набора стилей и не путать чужие.
Использование таблиц стилей на больших сайтах — отличная идея. Однако это действительно работает только тогда, когда вы применяете стандарты своей команды к стилю. Имеет смысл иметь единый контроллер шаблона, который связывает ваши таблицы стилей. Также имеет смысл назначить кого-то из команды «хранителем стиля», через которого должны проходить все изменения в таблице стилей, прежде чем вносить существенные изменения.
Как только стандарты стиля согласованы и определены, все элементы управления на сайте должны реализовывать определенные стили. Это позволяет разработчикам отказаться от написания кода в соответствии со стилем и просто кодировать в соответствии со стандартом. Вводы — это вводы, абзацы — это абзацы, а плавающие элементы div — головная боль.
Ключевым моментом является стандартизация внутри команды и соблюдение всеми разработчиками. В настоящее время я руковожу групповым сайтом, который имеет более 30 таблиц стилей для управления макетом, шрифтами, отображением данных, всплывающими окнами, меню и пользовательскими элементами управления. У нас нет ни одной из этих проблем, потому что разработчикам очень редко приходится напрямую редактировать таблицу стилей, потому что стандарты четко разработаны и опубликованы.
Несколько файлов CSS и объединение в коде
Во время разработки я обнаружил, что следующий способ кажется разумным и хорошо подходит для групп разработчиков:
- Не добавляйте никаких стилей в HTML. Ремонтопригодность, а также много головоломок, почему некоторые вещи не отображаются должным образом, будут очень плохими.
- Иметь один (или несколько) глобальный CSS, определяющий стили для глобальных частей. Обычно все определяет в template/master. Может быть привязан к главной странице или к универсальным элементам управления, используемым на большинстве страниц.
- Имейте CSS-файлы для каждой страницы/элемента управления, когда они действительно необходимы. Большинству страниц они не понадобятся, но разработчики могут их написать.
- Хорошо структурируйте эти файлы в папках.
- Используйте рекомендации по именованию и форматированию, чтобы каждый мог писать/читать код.
- Писать код на стороне сервера. taht объединит несколько файлов CSS в один для экономии пропускной способности.
Вы также можете автоматизировать некоторые другие задачи, такие как автоматическое добавление файлов CSS для каждой страницы, если они называются так же, как и сами страницы.
Такой подход облегчит разработку, поскольку с отдельными файлами CSS будет легче работать из-за меньшего содержания, и у вас будет меньше конфликтов при слиянии кода, поскольку большую часть времени пользователи будут работать над отдельными функциями.
Но невозможно автоматизировать модульные тесты CSS, чтобы гарантировать, что изменение существующей настройки CSS не нарушит работу других частей вашего сайта.
Вы не хотите определять CSS для каждого элемента, потому что, если вам когда-нибудь понадобится внести изменения, которые однажды повлияют на многие элементы, скажем, на внешний вид всех кнопок или заголовков, вы будете делать много поиска/замены. И как проверить, не забыли ли вы обновить одно правило, чтобы ваш сайт оставался согласованным?
Стивен затронул очень сильную сторону CSS. Вы можете назначить несколько классов элементу. Вы должны определить некоторые основные правила, которые «обычные» разработчики не могут трогать. Они обеспечат согласованность через сайт. Затем разработчики могут назначить дополнительный класс для персонализации любого свойства. Я бы не стал назначать более двух классов: глобальный и персонализированный.
Учитывая, что у вас уже есть эта огромная таблица стилей, я не уверен, как вы выберете, кому из 7 разработчиков придется сесть через месяц и организовать ее. Вероятно, это будет трудная часть.