Як переробити CSS - керівництво
Рефакторинг CSS повинен бути невід'ємною частиною робочого процесу розробки, якщо ми хочемо мати керовану та оптимізовану базу кодів. Коли ми рефактор CSS, ми очистити і реорганізувати існуючий код без додавання нових функцій або виправлення помилок.
Рефакторинг допомагає запобігання вибуху CSS, поліпшення читаності коду та повторного використання, і робить CSS більш гнучким і швидшим для виконання.
Рефакторинг, як правило, необхідний через деякий час, оскільки навіть проекти, які почали з лаконічною і організованою кодовою базою, рано чи пізно починають втрачати свою ясність; з'являються послідовність, застарілі правила та дублюючі частини коду; і ми також починаємо замінювати стилі і використовувати більше і більше хаків і обхідних шляхів.
Найкращим способом зберегти нашу базу даних CSS-коду є підтримка “Рефактор рано, рефактор часто” практичне правило. У цій публікації ми розглянемо деякі поради про те, як можна провести ефективний процес рефакторингу CSS.
1. Провести початковий аудит
Щоб мати кращу картину про те, що нам потрібно рефакторувати, це найкраще почати з всебічного аудиту, щоб побачити те, що ми зараз маємо.
Є багато великих онлайн-інструментів, які можуть допомогти нам у цьому. CSSDig - це потужне розширення Chrome, яке аналізує CSS веб-сайту та досліджує його слабкі місця, такі як занадто специфічні селектори або повторювані властивості.
Невикористаний CSS досліджує невикористані правила CSS, тоді як інструменти для листування, такі як CSS Lint, дозволяють швидко знаходити можливості для сумісності, ремонтопридатності та інших проблем.
Також важливо вручну перевіряти код під час первинного аудиту, оскільки багато проблем на архітектурному рівні можна ловити тільки таким чином.
2. Створити керований план
Рефакторинг робочого коду завжди є складним завданням, але ми можемо полегшити біль, якщо ми створимо план про те, що нам потрібно зробити, поділіть процес рефакторингу на керовані шматки та зробіть можливий графік.
У рефакторингу CSS є важлива річ, яку ми завжди повинні враховувати: деякі речі, які ми рефакторуємо, наприклад, змінюючи імена селектора, це зробить необхідно коригувати код відповідних файлів HTML і JavaScript так само.
Тому хороша ідея простежити вперед ці додаткові модифікації, які нам потрібно виконати, і побудуйте їх у нашому графіку рефакторингу поряд з основними завданнями, пов'язаними з CSS.
3. Відстеження прогресу
Перш ніж приступити до рефакторингу, це важливий крок створіть резервні копії початкових файлів. Запровадження системи контролю версій, наприклад Git або Subversion, у наш робочий процес також може значно поліпшити процес рефакторингу, оскільки ми матимемо реєстр про послідовні кроки, які ми зробили, і зможе повернутися до попереднього етапу, якщо ми хочемо переробити речі.
4. Дотримуйтеся Керівництва по стилю кодування
Когерентне керівництво по стилю кодування може значно поліпшити читаність коду і можливість його ремонту, тому перед тим, як ми почнемо рефактори, це необхідно встановити керівництво стилю кодування CSS.
Важливо вирішити:
- умов імен
- правила форматування
- порядок декларування
- одиниць і значень, які ми хочемо використовувати
- правила коментування
Якщо ми не хочемо створювати власне керівництво для стилю кодування, ми можемо також використовувати чужі, такі як ThinkUp, які можна знайти на Github.
Це не достатньо, хоча просто ввести керівництво стилю кодування, ми також повинні дотримуйтеся його, коли ми перепишемо код під час рефакторингу, і очікувати ж від усіх інших який працює над нашим проектом.
5. Налаштуйте структуру когерентних файлів
Після того, як ми будемо готові до підготовки, перше, що нам потрібно зробити, це створити відповідну структуру файлів CSS, яка звертає увагу на каскадний характер CSS.
В основному це залежить від того, як найкраще організувати наші файли, але є деякі універсальні правила, наприклад, використання окремого normalize.css
файл для стилів CSS, окремий global.css
для глобальних стилів, які використовуються в усьому проекті, і для зберігання бібліотек третьої сторони в окремій папці.
Якщо ми хочемо грати безпечно з нашою структурою файлів CSS, є також готові архітектури, такі як SMACSS або ITCSS, які пропонують ефективні методи як організувати CSS-файли масштабованим способом.
6. Отримати невикористані та повторювані правила
Через деякий час файли CSS зазвичай починають рясніти невикористаними правилами, які нам потрібно ідентифікувати та очистити під час рефакторингу. Є багато онлайн-інструментів, які дозволяють нам досліджувати ці застарілі правила, а іноді також дозволяють нам швидко кидати їх.
Найбільш відомим інструментом для цієї мети є, мабуть, UnCSS, модуль Node.js, який дозволяє швидко позбутися невикористаних правил CSS, а також надає складні параметри конфігурації, які дозволяють легко налаштувати процес очищення.
Важливо враховувати, що ми не обов'язково видаляти невикористані правила з все файли CSS, які ми маємо, наприклад, з таблиць стилів глобального, скидання чи третьої сторони, тому нам потрібно виключити їх під час чищення.
Поряд з застарілими правилами, дублюючі правила також призводять до надмірного розмивання коду та втрати продуктивності. Ми можемо їх видалити за допомогою модуля CSS Purge Node.js, але ми також можемо працювати CSS linters для пошуку дублікатів правил в наших файлах CSS.
7. Знизити специфіку
Специфікація селектора CSS обчислюється з числа і типів внутрішніх селекторів, які він містить. Специфіка CSS виражається у вигляді 4-значного числа, що є найпростішим для розуміння, якщо ми перевіримо цей візуальний калькулятор специфікації CSS:
Найнижча специфіка (0001
) належить до селекторів, які націлюють лише один загальний HTML елемент, наприклад або
. Чим більше внутрішніх селекторів містить селектор з'єднання, тим вища його специфічність.
Деякі селектори, наприклад id
або селектори, що надходять з вбудованих стилів, мають більш високі пріоритети, оскільки вони замінюють стилі, що належать до більш загальних селекторів. Наприклад специфічність # id1
селектор 0100
.
У рефакторингу мета полягає в тому, щоб зменшити специфіку селекторів (утримати їх короткими), наскільки це можливо, як Селектори з більш високою специфічністю значно знижують селекторну багаторазову можливість, і ведуть до роздутою кодової бази.
Три основних типи селекторів високої специфічності:
- Кваліфіковані селектори, як от
p.class1
(визначеннястор
тут не потрібно, оскільки неможливо використовувати один і той же клас з іншими елементами HTML) - Глибоко вкладені селектори, як от
.class1 .class2 .class3 .class4…
- Ідентифікатори, як от
# id1
Інтернет-інструменти, такі як CSSDig, згадані в кроці 1, можуть бути використані для швидкого пошуку цих високоспецифічних селекторів. Також може бути корисно налаштувати правило в керівництві стилю кодування про такі речі, як максимальний рівень вкладеності або обмеження на використання id
селекторів.
8. Видобуток !важливо
Правила
Правила CSS супроводжуються !важливо
оператор перекриває звичайні правила стилю. Використання !важливо
рано чи пізно призводять до некогерентного коду. Це не випадковість, що більшість інструментів для маркування позначають їх як помилку.
Коли нам потрібно швидко написати CSS, ми можемо покластися на них, хоча через їх простоту.
Основна проблема з !важливо
Декларації полягають у тому, що якщо ми хочемо перевизначити їх у майбутньому, нам потрібно поставити ще більше !важливо
використовуються декларації, тому краще їх усунути, де це можливо, під час процесу рефакторингу.
9. Очистіть магічні цифри та жорсткі значення
Під час нашого повсякденного робочого процесу CSS іноді ми натрапляємо на проблеми, які ми не можемо вирішити, і починаємо використовувати так звані магічні числа, значення, які працюють з деяких причин, але ми не розуміємо, чому. Наприклад, використовуйте наступний приклад:
.class1 позиція: абсолютна; зверху: 28px; зліва: 15,5%;
Основна проблема з магічними числами полягає в тому, що вони є непрямі, і вони втілюють “програмування шляхом перестановки” антипаттерн. Під час рефакторингу ми повинні видалити ці довільні правила з нашого коду і замінити їх більш обґрунтованими рішеннями, де це можливо.
Те ж саме правило застосовується для жорстко закодовані значення так само. Можливо, найчастіше зустрічаються жорстко закодовані значення в правилах висоти рядка:
/ * погано, нам потрібно додати додаткові правила фіксованої висоти в дочірні елементи .class1 * / .class1 font-size: 20px; висота рядка: 24px; / * добре, гнучке правило лінійної висоти можна безпечно використовувати також дочірніми елементами * / .class1 font-size: 20px; висота лінії: 1.2;
Важко закодовані значення роблять наш код менш доказовим для майбутнього і більш жорстким, тому в рамках рефакторингу нам потрібно викопати їх, і замінити їх гнучкими значеннями.
10. Реакторні одиниці та значення
Щоб полегшити технічне обслуговування та налагодження в майбутньому, а також уникнути помилок, які можуть виникнути в результаті використання різних пристроїв, таких як em
і px
, водночас нам потрібно дотримуватися узгоджених правил про те, як ми використовуємо відносні і абсолютні значення.
Якщо ми використовували їх непослідовно в минулому, ми повинні перетворити їх так, щоб вони могли представляти собою лаконічну систему
Якщо ми використовуємо дуже багато подібних кольорів на нашому сайті, це також може бути розумною річчю раціоналізувати колірну схему за рахунок зменшення кількості кольорів, які ми використовуємо. (Ось повідомлення про те, як вибрати колірну схему веб-сайту практично.)