Чому лажають?

Джерело фото: https://www.ionos.ca/digitalguide/fileadmin/_processed_/a/3/csm_was-ist-css-t_2cf0e8295e.jpg

Підніміть руку , якщо ви front-end розробник і в якийсь момент у вашій кар'єрі виникло таке відчуття, що ви робите дуже прості речі, що внесок, який ви робите в команду, мінімальний і те, що робите ви, може зробити будь-хто. Якщо це так, то ви є частиною більшості.

Я маю на увазі, що будь-хто може зробити наступне в CSS:

p { color: red; }

Отже, що дає мені право скаржитися? Для CSS взагалі не потрібно вміння кодити. І це абсолютно очевидно, стилізування одного елемента на глобальному рівні ніяк не потребує CSS і є значно легким завданням.

Так що, коли стає тяжко?

> back-end розробник: Я реалізував нову функцію, але зламав front-end, я виправив більшість помилок, залишилось тільки кілька простих налаштувань, дороби це, там має бути не більше 30 хвилин роботи...

> Я: - Відкрив HTML. Таблиці всюди, застарілі теги HTML, нульове свідчення адаптивного дизайну. Вдихаю глибше. Звичайно CSS вони написали краще. Відкриваю файл CSS. Фіксовані позиції, чисті left та right і найприємніше, всюди !important. Після побаченого, я повільно дістаю мишу та огортаю дротом навколо шиї.

Добре, таке може траплятися, але я все-таки нечасто зустрічав back-end розробників, які пишуть придатний до вживання front-end код. Нічого страшного, це ж не їхня задача, але, будь ласка, не лажайте з надією, що front-end розробники потім після вас будуть все виправляти.

Що є такого гарного в CSS?

Структура, структура проекту дуже важлива, особливо у роботі з великими проектами.

Специфічність - ймовірно найбільша проблема, з якою я стикаюсь щодня. На жаль, більшість розробників мають розмите розуміння специфіки CSS і це призводить до поганого CSS... !important всюди. Тож, як нам виправити цю ситуацію? Є багато іменувань, які спрямовані на зведення до мінімуму потреб в специфічних CSS селекторах, однак, якщо це не ваша справа, я б рекомендував уникати селекторів з більш ніж трьома елементами/класами.

Конвенція імен дуже важлива для будь-яких великих CSS проектів. Без них CSS стає не ремонтопридатним і не заслуговує на довіру, конвенції імен дозволяють повторно використовувати CSS в рамках проекту і видаляти невикористані ділянки CSS, якщо це необхідно. Деякі популярні конвенцій імен: BEM, OOCSS, SMACSS.

Тестування, це річ на яку більшість розробників не звертають уваги. Знаєте, що є дійсно крутим в back-end розробці? Те, що ви розробляєте для одного середовища (сервер, на якому буде встановлений ваш сайт). А що є поганим в front-end розробці? Це 5+ браузерів і тисячі різних мобільних пристроїв... Якісне front-end тестування є завданням, яке займає багато часу. Але я помітив, що все ж таки проекти, на які не відводиться час на тестування, загалом виконуються довше, ніж проекти з ним.

Як виправити такі ситуації, працюючи з CSS?

Досить їм це пробачати. Ми, як front-end розробники, не пишемо кривий неадаптивний код, використовуючи CSS для back-end колег. То чому вони надають нечітку абияку розмітку і намагаються втулити туди наш CSS, де він не працює? Я не кажу змушувати їх власне писати на CSS, нехай краще цього не роблять взагалі. Просто не давайте думати іншим розробникам про те, що ваша робота легка, бо це не так. Ви працюєте так само важко, як і всі інші, і не дозволяйте їм вважати, що ви відрізняєтесь.

Джерело: http://surl.li/gvkno
Переклад українською мовою: Аліна Берестень
Адміністратор: Дмитро Берестень