Рефакторинг CSS: введение (часть 1)

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

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

Рефакторинг больших частей кода CSS — непростая задача по любым меркам. Иногда может показаться, что это всего лишь случай «удаления некачественного кода, написания лучшего CSS и развертывания блестящего улучшенного кода». Однако необходимо учитывать множество других факторов, таких как сложность рефакторинга работающей кодовой базы, ожидаемая продолжительность и использование команды, установление целей рефакторинга, отслеживание эффективности и прогресса рефакторинга и т. д. Также необходимо убедить руководство или заинтересованные стороны проекта в том, чтобы инвестировать время и ресурсы в процесс рефакторинга.

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

Побочные эффекты некачественного CSS

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

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

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

• Снижение качества кода по мере добавления дополнительных функций из-за разного уровня навыков CSS в команде разработчиков и отсутствия внутренних правил, соглашений и лучших практик.
• Добавление новых функций или расширение существующих селекторов вызывает ошибки и неожиданные побочные эффекты в других частях кода (также известные как регрессия ).
• Несколько разных селекторов CSS с повторяющимися блоками кода или фрагментами кода CSS можно разделить на новый селектор и расширить его вариантами.
• Остатки неиспользуемых фрагментов кода удаленных функций . Команда разработчиков потеряла представление о том, какой код CSS используется, а какой можно безопасно удалить.
• Несоответствие в структуре файла, именовании классов CSS, общем качестве CSS и т. д.
• «Ад специфики», когда новые функции добавляются путем переопределения вместо существующей кодовой базы CSS.
• Отмена CSS , где селекторы с более высокой специфичностью «сбрасывают» стиль селектора с более низкой специфичностью. Разработчики пишут больше кода, чтобы иметь меньше стилей. Это приводит к избыточности и большому количеству отходов в коде.

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

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

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

«(…) то, что началось с организованного PostCSS, постепенно превратилось в сложную и запутанную глобальную архитектуру CSS с множеством особенностей и переопределений. Как и следовало ожидать, есть момент, когда дополнительный технический долг, который он вводит, затрудняет поддержание быстрой доставки без добавления каких-либо регрессий. Кроме того, по мере роста числа фронтенд-разработчиков, вносящих свой вклад в кодовую базу, работать с такой архитектурой CSS становится еще труднее».

Рефакторить или переписать?

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

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

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

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

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

Подытожим плюсы и минусы каждого подхода.

Когда проводить рефакторинг CSS?

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

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

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

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

Когда переписывать CSS?

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

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

Аудит работоспособности кодовой базы CSS

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

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

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

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

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

«Такой инструмент, как CSS Stats, может легко помочь вам выявить проблемы согласованности в вашей кодовой базе. Указав, что может произойти, когда у всех разные мнения о том, как должен выглядеть серый тон, вы получите 50 оттенков серого. Кроме того, Specificity Graph дает вам хорошее общее представление о состоянии вашей базы CSS».

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

Уоллес также предлагает бесплатный инструмент-анализатор на веб-сайте Project Wallace, который использует, по-видимому, более продвинутую версию Wallace в серверной части, чтобы обеспечить некоторые полезные визуализации данных и еще несколько показателей, которые недоступны в CLI Wallace.

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

Написание высококачественного CSS

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

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

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

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

Говоря из личного опыта, я обнаружил, что следующее помогло мне значительно улучшить работу с CSS:

• Изучение архитектурных моделей.
  Руководство по CSS содержит обширную базу знаний и лучшие практики для написания высококачественного CSS на основе общих шаблонов программирования и архитектурных принципов.
• Практикуйтесь и совершенствуйтесь.
  Работайте над личными проектами или решайте задачи от Frontend Mentor, чтобы улучшить свои навыки. Начните с простых проектов (один компонент или раздел) и сосредоточьтесь на написании наилучшего CSS, пробуйте различные подходы, применяйте различные архитектурные шаблоны, постепенно улучшайте код и научитесь эффективно писать высококачественный CSS.
• Учимся на ошибках.
  Поверьте мне, вы напишете действительно некачественный CSS, когда начнете. Вам потребуется несколько попыток, чтобы сделать это правильно. Найдите минутку и подумайте, что пошло не так, проанализируйте слабые места, подумайте, что и как вы могли бы сделать по-другому, и постарайтесь избежать тех же ошибок в будущем.

Также важно установить правила и внутренние стандарты CSS внутри команды или даже для всей компании. Четко определенные общекорпоративные стандарты, стиль кода и принципы могут дать множество преимуществ, таких как:

• Унифицированный и последовательный стиль и качество кода
• Легкая для понимания, надежная кодовая база
• Упрощенная адаптация проекта
• Стандартизированные обзоры кода, которые может проводить любой член команды, а не только ведущий фронтенд-разработчик или более опытные разработчики.

Кирби Ярдли работал над рефакторингом системы дизайна Sundance Institute и CSS и указал на важность установления внутренних правил и лучших практик.

«Без надлежащих правил и стратегии CSS — это язык, который можно использовать неправильно. Часто разработчики пишут стили, специфичные для одного компонента, не задумываясь критически о том, как этот код может быть повторно использован в других элементах (…) После долгих исследований и размышлений о том, как мы хотели подойти к архитектуре нашего CSS, мы решили использовать методологию под названием ITCSS. “

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

«Мы представили библиотеку шаблонов, начали использовать атомарный дизайн в нашем рабочем процессе, создали новые рекомендации по кодированию и адаптировали несколько методологий, таких как BEM и ITCSS, чтобы поддерживать нас в поддержке и развитии нашего CSS/UI в больших масштабах».

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

Заключение

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

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

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

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

использованная литература

• «Управление проектами CSS с помощью ITCSS», Гарри Робертс
• «Крупномасштабный рефакторинг CSS в Trivago», Кристоф Рейнартц
• «Система проектирования Sundance.org и рефакторинг CSS», Кирби Ярдли.
• «От семантического CSS до Tailwind: рефакторинг кодовой базы пользовательского интерфейса Netlify», Чарли Джерард и Лесли Кон-Вейн.
• «Инструменты аудита CSS», Ирис Лешнянин