Очищення кодової бази CSS
Ви тільки що приєдналися до існуючого проекту для заміни розробника, що йде. А може, просто зайнялися своїм старим проектом через кілька років. Ви відчуваєте жах та огиду при погляді на код. Ви можете зробити тільки одне: розчистити весь цей бардак. Ви вже стикалися з чимось подібним? Майже напевно рано чи пізно з цим стикаються всі.
Ви знаєте, що очищення коду CSS - це об'ємне завдання. Потрібно багато зробити за обмежений час — особливо, коли клієнти/начальники/колеги наполегливо радять не чіпати те, що працює. Ви навіть не знаєте, з чого почати.
Але сьогодні удача на вашому боці — я готовий поділитися з вами своїми рішеннями щодо очищення коду та дати вам поради щодо їх використання. Насправді все зводиться до найпростіших речей.
Лінтінг це наше все
Перше, що я звик робити, коли мені треба розібратися з кодовою базою, це лінтинг. Лінтинг це процес виконання програми, яка здійснює пошук потенційних помилок та поганих практик. Я вірю, що роблячи код чистим, ми робимо перший крок до хорошого коду. З етимологією слова лінтинг можна ознайомитись у цьому треді в StackOverflow.
У Sass є написаний на Ruby лінтер, званий SCSS-lint. Ви можете налаштувати його самостійно або завантажити конфігурацію, рекомендовану Sass-Guidelines, щоб почати зараз. Також у Node.js є sass-lint, вони не на 100% сумісні та можуть працювати по-різному.
Спробуйте запустити SCSS-Lint у своєму каталозі із файлами Sass для виявлення помилок. Дуже високі шанси на те, що на вас вивалиться тонна помилок. Зазвичай після цього хочеться припинити експерименти щодо очищення коду. Наберіться терпіння. Зараз ви можете спробувати зробити конфігурацію менш суворою щодо правил, не дуже важливих для вас (типу форматузавдання кольору) або взяти бика за роги і використовувати всю міць лінтингу.
Виправлення знайдених помилок
Настав час виправити те, що потрібно виправити. Це можна зробити двома способами. Перший - це перевірити по черзі всі файли і виправити всі помилки та недоліки типу невдалого іменування змінних, зайвої вкладеності селекторів та погано відформатованого коду. Другий (належний мною) — це використання пошуку та заміни. Не знаю, як ви, але я обожнюю регулярні вирази і мені завжди подобається використовувати їх у роботі.
Я нещодавно створив на GitHub репозиторій scss-lint-regex, щоб зібрати всі регулярні вирази для лінтингу в одному місці. Обов'язково погляньте на нього, якщо у вас є проблеми з лінтингом у великому проекті. І будьте обережні з пошуком/заміною, часом він призводить до несподіваних побічних ефектів. Після кожної заміни виконуйте git diff, щоб виявити, що змінилося, це гарантує, що ви не додасте багів у свій код.
Після того, як ви закінчите з редагуванням пошуком/заміною, вам не вдасться уникнути ручного редагування, в тих місцях, які треба ушляхетнити (неправильні відступи, відсутність або надлишок порожніх рядків, пропущені прогалини тощо). Це займає багато часу, але це чудово допоможе вам на наступному етапі, тому важливо зробити це до переходу до нього.
Примітка перекладача
Перегляд структури проекту
Ось що мене дійсно часто турбує, коли я приєднуюсь до існуючого проекту, то це відсутність належної архітектури проекту. Можливо, на початку роботи і був якийсь проект, але згодом речі виходять з-під контролю і початковий задум губиться. Але це все одно надзвичайно важливо.
Не настільки значущий вибір методології проекту, головне, щобвона у вас була і не викликала дискомфорту. Це може бути SMACSS, 7-1 або ITCSS - вибір за вами. Спробуйте реструктурувати свій код відповідно до обраної методики. Я, як правило, використовую патерн 7-1, який ми розробили в Sass Guidelines, тому я дам вам кілька порад, які допоможуть, якщо ви обрали цей шлях.
Почніть із створення каталогу vendor, цей крок зазвичай не викликає питань. Перенесіть у нього всі додаткові бібліотеки від сторонніх розробників (бібліотеки, які не є залежними від npm або Bundler).
Потім перейдемо до каталогу abstracts. Усі змінні, міксини, функції та плейсхолдери повинні бути тут. Ви вільні впорядковувати їх як забажаєте, поки ви не розберетеся з усіма змінними та міксинами у вашій кодовій базі. Я на цій стадії також виявляю необов'язкові змінні (і міксини), адже часто доводиться стикатися зі змінними, які використовуються один чи два рази.
Після того як ви розібралися з цим, вам доведеться ухвалити рішення, який із двох наступних кроків зробити раніше. Ви можете спробувати забезпечити, щоб весь вміст каталогу base складали справді основні стилі, а не стилі компонентів. Або перевірити, що в каталозі layout знаходиться все, що стосується розкладки сторінок і що цей код правильно документований.
І, нарешті, на завершення вам треба зайнятися компонуванням каталогу components і зазвичай це колосальне завдання. Я раджу робити компоненти якомога меншого розміру та орієнтуватися на їх багаторазове використання. Не має значення, якщо ви збільшите їхню кількість — головне, щоб вони не залежали від контексту і були простими для читання, розуміння та оновлення.
Як приклад правильного та невеликого компонента можу навести наступний:
Намагайтеся мислити модулями. Менше. Простіше. Незалежніше.
Видалення зайвого
Я вважаю, що найбільша різниця між поганим і хорошим CSS - це кількість коду. CSS легко розростається. Хтось може робити майже кожну розкладку методом спроб та помилок. Здатність робити що-небудь, використовуючи мінімум CSS вимагає роботи, а збереження мінімалістичного підходу є справжнім викликом.
Минуло вже 3 роки, але цей твіт Ніколаса Галахера залишається моїм улюбленим питанням про CSS:
Старіння це справжня чума CSS. При написанні стилів ми часто ходимо туди й назад, пробуючи нові правила — в результаті ми зазвичай залишаємо кілька зовсім непотрібних декларацій. Наприклад, overflow: hidden , що втратив необхідність або font-size , не змінює розмір шрифту. Залишаючи їх, ми збільшуємо технічний обов'язок. У цьому нічого хорошого.
При написанні CSS я звик відкривати інструменти розробника у браузері і по черзі відключати кожну декларацію CSS перед відправкою готового коду, щоб перевірити, на що вони впливають. Якщо вони ні на що не впливають, то я насамперед запитую себе: “Навіщо вони тут?”. Якщо вони виявляються марними, я видаляю їх. З такою простою методикою, як ця, я гарантую відправку в репозиторій тільки корисного коду без сміття.
Очищення кодової бази CSS це та сама техніка. Визначте компонент, який ви хочете очистити, відкрийте інструменти розробника та спробуйте знайти непотрібні декларації. Іноді для видалення коду CSS нам треба пересунути ці стилі вгору по дереву, щоб скористатися можливостями каскаду. Розглянемо це на наступному лаконічному прикладі:
Очевидним способом оптимізації є переміщення декларації color: red до батьківського селектора, після чогокаскадування зробить за нас інше. Звичайно, реальні приклади зазвичай складніші, але і цей приклад свідчить про те, що не варто забувати можливості „C“ в абревіатурі CSS.
CSS розумний і ви повинні бути не гірше
Також дуже часто зустрічається брак розуміння значень inherit, initial і currentcolor. Припустимо, ви хочете, щоб посилання були того ж кольору, що і основний текст (вони вже виділені підкресленням). Ось як не треба це робити:
У CSS є вбудований спосіб вирішення цієї проблеми, це значення inherit :
Так просто. Завдяки цьому посилання успадкуватимуть колір батьківського елемента. Який у свою чергу також може успадковувати колір своїх предків і таке інше.
Так само при поверненні властивості дефолтного значення буде поганою ідеєю завдання фіксованого значення. У CSS для таких випадків є значення initial. Зазвичай воно немає відмінностей від завдання фіксованих значень, але є випадки, коли справді грає свою роль, наприклад, щодо напряму тексту у властивості text-align . При скиданні text-align, значення left може зіпсувати текст на RTL-мовах (спрямованих праворуч наліво), виходом буде саме initial (ще краще start, але це значення не підтримується в IE9)/.
Останнє в списку, але не останнє за важливістю значення це currentcolor, дуже багато розробників про нього не знають. Якщо ви ставитеся до їх числа, не переживайте, просто запитайте у себе: "Якщо ви не задавали колір кордону елементи, то чому він автоматично збігається з кольором шрифту елемента?". Так, це тому, що за умовчанням властивості border-color задано значення currentcolor (специфікація). Погодьтеся, все очевидно із назви.
На мою думку, якщо ви хочете використовувати колір шрифтуелемента, треба використовувати currentcolor замість фіксованого значення або змінної Sass.
Це базові можливості CSS. Вони роблять CSS таким, як є. І ці можливості використовуються напрочуд рідко. Тому, якщо ви вирішили покращити код компонента, не варто нехтувати ними.
Ваш Git має бути в порядку
Рефакторинг кодової бази CSS – це велика за обсягом робота. Вам доведеться оновлювати десятки файлів. І цілком імовірно, що ви щось зламаєте у процесі. Давайте будемо чесні - всі роблять помилки і було б неможливо круто, якщо вам вдасться завершити таку роботу без якої-небудь невеликої помилки.
Тому я наполегливо рекомендую вам старанно працювати із системою контролю версій (логічно припустити, що в цій ролі виступає Git). Це означає, що всі комміти роблять одну єдину річ — забезпечувати повернення на крок назад від коду з багом без мук із конфліктами.
Я знаю, що багатьом людям Git здається складним і важким для сприйняття, а способи легко освоїти його за межами цієї статті. Повірте мені: історія вашого Git має бути схожою на поему, якщо ви не хочете, щоб у вас википів мозок.
Висновок
Очищення проекту CSS/Sass складне тому, що важко відразу оцінити всі наслідки зміни чи видалення рядка CSS. Це все в основному через погану тестованість CSS. Тож вам треба бути уважними.
Почніть з лінтингу і ваш код стане симпатичнішим. Зробіть це тому, що це полегшить ваше життя у майбутньому. Це також хороший спосіб огляду стану вашого коду без особливого ризику (виправлення синтаксичного бруду не повинно стати причиною проблем).
Потім структуруйте свій проект відповідно до обраної вами методології. Не важливо, яку ви виберете, важливо,щоб ви їй слідували. Якщо у вашому проекті не надто багато компонентів, то структурування буде добрим початком. Знайдіть фрагменти інтерфейсу, які багаторазово використовуються, і перенесіть їх стилі в окремі файли. Не соромтеся писати документацію, таким чином процес піде простіше і ви відчуєте, як рухаєтеся вперед.
І, нарешті, ваші комміти мають бути регулярними та логічними. Об'єднуйте зміни у невеликі комміти, кожен з яких робить одну просту річ — тож вам буде простіше відкотити зміни, якщо ви щось зробите не так.
Останнє, але не менш важливе – не забудьте відсвяткувати, коли все закінчиться. Успіхів!