Вы только что были включены в существующий проект, чтобы заменить уходящего разработчика. Или, может быть, вы только что открыли свой старый проект несколько лет назад. Вы сталкиваетесь с ужасом и ужасом, когда смотрите на код. Вы можете сделать только одно: навести порядок! Вам это знакомо? Конечно, мы все сталкиваемся с этим в тот или иной момент.
Вы знаете, что очистка кодовой базы CSS будет огромной задачей. Есть так много дел, но так мало времени, особенно когда клиент / начальник / коллега отстаивает добрую поговорку «не чинить то, что не сломано». Вы действительно не знаете с чего начать!
Что ж, вам повезло, потому что я сделал свою долю CSS-очисток, и я здесь, чтобы дать вам несколько советов, чтобы начать с этим. Это все о захвате низко висящих фруктов.
Вырваться из этого
В этом разделе я предполагаю, что ваша кодовая база использует Sass . Не только потому, что это разумное предположение в настоящее время, но и потому, что я заметил, что плохое использование Sass часто частично отвечает за грязную кодовую базу. Тем не менее, эта статья может иметь отношение к вам, даже если вы не используете препроцессор, так что терпите меня, пожалуйста.
Первое, что мне нравится делать, когда мне нужно захватить кодовую базу, это помешать. Linting — это процесс запуска программы, которая ищет потенциальные ошибки и плохие практики. Я считаю, что чистота кода — это первый шаг к хорошему коду. Вот проницательная тема переполнения стека об этимологии слова «линт».
У Sass есть основанный на Ruby линтер под названием SCSS-Lint . Вы можете настроить его самостоятельно или взять рекомендованный файл конфигурации из Sass-Guidelines, чтобы сразу приступить к работе. Существует также версия Node.js под названием Sass-lint , хотя они не на 100% совместимы, поэтому ваш пробег может отличаться.
Попробуйте запустить SCSS-Lint в папке Sass, чтобы проверить ошибки. Скорее всего, вы будете поражены стеной ошибок. Это обычно время, когда вы будете испытывать желание сдаться. Но потерпи меня! На этом этапе вы можете попытаться сделать свой файл для подшивки немного менее строгим по отношению к правилам, которые вас не интересуют (например, цветовой формат), или вы можете взяться за зверя спереди и черт побери!
Исправление ошибок Linting найдено
Пришло время исправить то, что нужно исправить. Есть два способа сделать это. Первый — просматривать файлы один за другим и обновлять то, что кажется неправильным и / или нечетным, например, соглашения о неправильном именовании, слишком глубоко вложенные селекторы, плохо отформатированный код и т. Д. Второй (и мой любимый) вариант — запустить с небольшим количеством поиска и замены. Я не знаю как вы, но я люблю регулярные выражения, поэтому всегда очень весело, когда мне приходится это делать.
Например, допустим, вы хотите добавить отсутствующий начальный ноль перед всеми числами с плавающей запятой (то есть числовым значением от 0 до 1) — правило LeadingZero из SCSS-lint. Вы можете найти \s+\.(\d+) (все числа после пробела и точки) и заменить его на \ 0.$1 (пробел, ноль, точка и найденное число). Или, если вы хотите соблюдать правило BorderZero для SCSS-lint, вы можете заменить border: none на border: 0 в вашей IDE. Просто как пирог!
Недавно я запустил репозиторий scss-lint-regex на GitHub, чтобы собрать эти регулярные выражения в одном месте. Обязательно посмотрите, если вы боретесь с созданием большого проекта. Также будьте осторожны с поиском и заменой, так как это иногда имеет неожиданные побочные эффекты. После каждой замены обязательно выполняйте git diff чтобы проверить, что было обновлено, чтобы вы могли убедиться, что вы не вносили ошибку.
Как только вы закончите с поперечным редактированием, вы не избежите ручного сканирования файла, чтобы очистить все, что нужно очистить (плохой отступ, пропущенные или лишние пустые строки, пропущенные пробелы и т. Д.). Это займет много времени, но очень поможет в следующем шаге, поэтому важно начать с этого.
Пересмотреть структуру
Что меня часто беспокоит, когда я подключаюсь к существующему проекту, так это отсутствие правильной архитектуры проекта. Вероятно, в самом начале был один, но вещи обычно выходили из-под контроля, и это краткое представление о методологии терялось где-то на линии. Тем не менее, это невероятно важно.
Неважно, какую методологию вы выберете, если вы чувствуете себя комфортно с ней и придерживаетесь ее. Это может быть SMACSS , это может быть 7-1 , это может быть ITCSS — сделайте свой выбор! Затем попытайтесь изменить структуру, чтобы сделать код соответствующим выбранной методологии. Я в основном использую шаблон 7-1, представленный в Sass Guidelines, поэтому я дам вам несколько советов, как улучшить ситуацию, если вы решите пойти по этому пути.
Начните с папки vendor, так как она не задает вопросов. Переместите туда любую неупакованную стороннюю библиотеку (то есть любую библиотеку, которая не рассматривается как обычная зависимость через npm или Bundler ).
Затем перейдите в папку тезисов . Убедитесь, что все переменные, миксины, функции и заполнители проекта определены там. Не стесняйтесь организовать это так, как вы хотите, пока вы не получите переменные и миксины во всех файлах кодовой базы. Я также склонен искать ненужные переменные (и миксины) в то время. Действительно, я часто нахожу бесчисленные переменные, которые используются только один или два раза (другими словами, это не стоит).
Как только вы закончите с этим, это ваш звонок. Вы можете либо попытаться убедиться, что все в базовой папке на самом деле является базовым материалом, а не связанным с компонентом, или вы можете взглянуть на папку макета, чтобы проверить, все ли в нем находится и правильно ли задокументировано.
Наконец, вам придется взяться за компоненты, что, вероятно, будет колоссальной задачей. Мой совет здесь состоит в том, чтобы попытаться сделать компоненты как можно меньше и использовать их повторно. Не имеет значения, удваиваете ли вы число, если вы можете сделать их контекстно-независимыми и легкими для чтения, понимания и обновления.
Например, неплохо иметь такой маленький компонент:
.quote { padding: 10px; } .quote__attribution { font-size: 80%; } .quote > :first-child { margin-top: 0; } .quote > :last-child { margin-bottom: 0; }
Думайте модульно. Небольшой. Просто. Independant.
Удалить излишки
Я считаю, что самая большая разница между хорошим и плохим CSS заключается в количестве кода, необходимого для того, чтобы заставить его работать ™. CSS как язык довольно легко понять. Любой может сделать практически любой макет с небольшим количеством проб и ошибок. Однако создать что-то с минимальным набором CSS, необходимым для того, чтобы это работало, и сохранить его таким, является настоящей проблемой.
Прошло более 3 лет, но этот твит от Николаса Галлахера остается моей любимой цитатой о CSS:
В «плохом» CSS очень сложно написать «хороший» CSS. В «хорошем» CSS очень легко использовать «плохой» CSS и инициировать гниение кода.
— Николас (@necolas) 26 сентября 2012 г.
Устаревание является настоящей чумой CSS. Создавая что-то с помощью CSS, мы часто возвращаемся и пробуем несколько вещей — до такой степени, что мы обычно получаем несколько ненужных объявлений. Например, overflow: hidden которое стало ненужным, или font-size который не имеет значения. Оставляя их, мы накапливаем технический долг. Это плохо ™.
Когда я пишу CSS, то, что мне нравится делать перед тем, как выполнять часть работы с CSS, — это открывать Инструменты разработчика и переключать каждую написанную мной декларацию CSS, чтобы посмотреть, как они влияют. Если они не делают, я спрашиваю себя, почему они там в первую очередь. Если они оказываются ненужными, я удаляю их. Делая что-то столь простое, как этот, я гарантирую, что только полезный код без мусора будет помещен в хранилище.
Очистка кодовой базы CSS ничем не отличается. Найдите компонент, который вы хотите очистить, откройте DevTools и попробуйте найти бесполезные объявления. Иногда, чтобы удалить CSS, нам нужно переместить некоторые стили вверх по дереву, чтобы воспользоваться каскадом. Рассмотрим следующий пример, приведенный к минимуму:
.parent { /* ...stuff here... */ } .child-A { color: red; } .child-B { color: red; }
Чистый способ оптимизировать это — переместить декларацию color: red к родителю и позволить каскаду делать все остальное. Конечно, примеры из реальной жизни обычно более сложны, но это показывает, как мы иногда забываем воспользоваться преимуществами C в * C * SS.
CSS умный, вы должны быть слишком
Я часто сталкиваюсь с недостатком понимания значений inherit , initial и currentcolor . Скажем, вы хотите, чтобы ваши ссылки были того же цвета, что и основной текст (потому что подчеркивания достаточно). Это плохой способ сделать следующее:
a { color: black; /* Nope */ }
Причина плохого решения должна быть очевидна: если вы измените цвет основной копии, цвет ссылки будет десинхронизирован. Если вы думаете об использовании переменной, вы делаете вещи излишне сложными. Кроме того, если ссылка заканчивается серым абзацем (например, внутри цитаты), она не будет соответствовать цвету!
У CSS есть встроенный способ справиться с этим со значением inherit .
a { color: inherit; /* Yay! */ }
Это так просто. Благодаря этому ссылки всегда будут наследовать цвет своего родителя. Который также может наследовать цвет своих предков и так далее.
Кроме того, при повторной инициализации свойства значением по умолчанию плохая идея жестко кодировать указанное значение. CSS имеет initial магическую ценность именно для такого сценария. Хотя обычно это не имеет значения, в некоторых случаях это действительно имеет значение, например, для свойств на основе направления, таких как text-align . При сбросе text-align установка left может повредить языки RTL; initial будет путь (или даже лучше, start , но это значение не поддерживается в IE9).
И последнее, но не менее важное: число разработчиков CSS, не знающих currentcolor , слишком чертовски велико. Если вы не знаете об этом, не расстраивайтесь, но спросите себя: как получается, что, если не указать цвет границы, он автоматически соответствует цвету элемента? Что ж, это происходит потому, что значением по умолчанию для border-color является currentcolor ( проверьте спецификацию ). Вполне очевидное имя, вы уступите.
Я хочу currentcolor , что если вы хотите, чтобы что-то разделяло цвет со шрифтом элемента, используйте currentcolor а не жестко запрограммированное значение или переменную Sass.
.element { color: deeppink; border: 1px solid; /* Color is implicit with `currentcolor` */ } .element svg { fill: currentcolor; /* Fill color will be same as text */ }
Все эти вещи являются основными функциями CSS. Это то, что делает CSS тем, чем он является. Тем не менее, они невероятно мало используются. Так что, если вам нужно улучшить код компонента, вы захотите внести следующие улучшения.
Получи свой Git Good
Рефакторинг кодовой базы CSS — большая работа. Вы можете обновить десятки и десятки файлов. Вы также можете сломать вещи по пути. Давайте будем честными, мы все совершаем ошибки, и когда имеешь дело с такими огромными изменениями, было бы очень впечатляющим, если бы вам удалось очистить все без малейших ошибок.
В связи с этим я настоятельно рекомендую вам очень усердно работать с системой контроля версий (я думаю, будет справедливо предположить, что Git здесь). Это означает, что мы совершаем одно и только одно, чтобы можно было вернуться к шагу, содержащему ошибку, без всякой адской борьбы с конфликтами.
Я знаю, что для многих людей Git сложен и непонятен, и изучение того, как сделать его простым, выходит за рамки этой статьи. Вы должны верить мне в этом: сделайте свою историю Git стихотворением, если вы не хотите злиться.
Завершение
Давайте подведем итоги и поговорим немного о ленивых читателях:
Очистить проект CSS / Sass сложно, потому что сложно оценить влияние обновления или удаления строки CSS. Это в основном потому, что CSS вряд ли можно тестировать. Из-за этого вы должны быть осторожны.
Начните с написания кода, чтобы он получился красивым. Начните с этого, чтобы облегчить вашу жизнь позже. Это также хороший способ получить ценный обзор состояния кодовой базы без большого риска (исправление синтаксической грязи вряд ли вызовет какие-либо проблемы).
Затем убедитесь, что ваш проект включает структурную методологию. Неважно, какой именно, если это сделано правильно. Если ваш проект на самом деле не разбит на компоненты, это будет хорошей возможностью начать этот путь. Найдите многократно используемые фрагменты интерфейса и извлеките их стили в собственные части. Не стесняйтесь документировать их, чтобы вам стало легче и вы почувствовали прогресс.
Как только вы очистили проект и расставили все по местам, пришло время улучшить сам CSS. Проверьте, можете ли вы сначала удалить вещи; мы часто пишем слишком много кода. Затем попробуйте оптимизировать код, чтобы он был менее повторяющимся. Остерегайтесь не перегружать хотя! Вы должны удалить сложность, а не добавить ее. Также не стесняйтесь комментировать все, что вы делаете, что может показаться неочевидным на первый взгляд.
Наконец, регулярно и логично делайте свою работу. Объединяйте свои изменения в небольшие коммиты, выполняя по одной вещи, чтобы было проще вернуться в историю, если что-то пойдет не так.
И последнее, но не менее важное, не забывайте праздновать, когда вы закончите. Удачи!