Розробники повинні використовувати концепцію, що називається shame.css, для вибору будь-якого швидкого виправлення CSS у проектах, за словами Гаррі Робертса, старшого розробника інтерфейсу в BSkyB.
Робертс пояснив у дописі в блозі, що це потенційно може зупинити розробників, які бачать хаки, що з'являються в CSS, і тим самим вважати, що такі речі є прийнятними за замовчуванням.
Крім того, у статті зазначалося, що такий підхід, якщо він буде належним чином задокументований та супроводжується засобами для ітерації, може забезпечити більш швидкий прогрес до більш чистого CSS у проектах, де використовувались хаки (з якоїсь причини).
.net поговорив з Робертсом (HB) щодо злому CSS та потенційних переваг, які може принести срам. css, якщо його правильно використовувати.
.net: Як ви вважаєте, чи існує тенденція з боку деяких людей у галузі нереалістично ставитись до необхідності (сподіваємось) короткострокових хакерів, щоб змусити сайт працювати?
HR: Великий час. Якщо ви працюєте на сайті чи продукті, який заробляє мільйони фунтів на рік, будь-які помилки, поломки чи химерності потребують якомога швидшого виправлення. Власникові вашого товару байдуже, наскільки ваш CSS ідеальний - їм важливо, щоб сайт працював і функціонував, і вистачало цього доходу. Хороший код є важливо, і хаки далеко не ідеальні, але думати, що ви завжди можете запобігти хакам і короткостроковим / швидким виправленням, це навряд чи.
.net: То ви б сказали, що вони просто необхідне зло в бізнесі?
HR: Коли клієнт дихає вам на шию - або функція порушена на веб-сайті, що працює, - вам потрібно переконатися, що ви підтримуєте правильних зацікавлених сторін. Якщо ви витрачаєте годину на написання ідеального виправлення того, що можна було б повернути за дві хвилини, я б сказав, що ви підтримуєте не ту людину щасливою - тобто себе!
У своїй власній роботі я виявив, що "потреба" у хакерів зростає пропорційно до розміру проекту, але хороша річ у тому, що у вас також, швидше за все, пізніше буде більше часу для проекту, присвяченого виправленню цих хаків.
.net: Звідки з’являється shame.css. З цією концепцією, що конкретно ви вважаєте злом CSS?
HR: Щось, що можна було б зробити краще, давши більше часу. Важко придумати приклади поза контекстом, але, я думаю, ви часто будете знати, коли щось є хакерством. Написав щось, що вам було б соромно пояснити колезі? Це, мабуть, хак!
Отже, shame.css - це створення файлу речей, які ви могли б зробити краще, і що ви можете зробити краще, коли встигнете переглянути їх. Це справді самозаписний список справ - файл хаків, який ви відкладаєте вбік, щоб подумати, коли у вас буде більше часу.
.net: У вашій статті ви згадуєте документування хаків, але чи немає аргументів, що розробники, як правило, повинні документувати CSS все-таки більше, а не просто для хак?
HR: Так! Якщо є одне, що всі розробники повинні робити більше, це написання коментарів. Ви повинні коментувати все, що не одразу видно з коду. Документуйте свій код так, щоб, якщо вас збив автобус по дорозі додому, ваш колега міг взяти на себе наступного дня.
.net: Щодо інтеграції shame.css, що ви пропонуєте?
HR: Якщо використовується препроцесор, @import сором. [scss | менше | тощо] файл в кінці, в ідеалі. (Це завжди може призвести до конкретності та проблем із замовленням джерел, тому ваш пробіг може відрізнятися.)
Якщо ви не використовуєте препроцесор, але маєте гідний процес збірки, перед розгортанням весь ваш CSS повинен бути об'єднаний та зведений до мінімуму, так що, знову ж таки, shame.css може закріпитися на цьому.
Якщо ви не використовуєте препроцесор і у вас немає процесу збірки, тоді один, ви, мабуть, повинні це виправити, і два, розділ про хаки в кінці таблиці стилів - це, мабуть, найкращий вибір. Shame.css не призначений для загального перегляду, тому ніколи не майте окремої таблиці стилів, що викликається елементом посилання у вашій націнці. Ви повинні подавати лише одну об’єднану та зменшену таблицю стилів.
.net: Якщо срам.css як концепція справді виживає, як, на вашу думку, це може змінити процес дизайну та веб-сайтів загалом?
HR: Shame.css настільки ж корисний, як і розробники, які його впроваджують. Це все добре, добре, ізолюючи та документуючи хакі, але якщо ви ніколи не виправляєте та не переглядаєте їх, ви знаходитесь у тому самому судні, що і раніше.
Для мене shame.css сигналізує про більш широкі зрушення у розвитку; не потрібно обмежуватися CSS. Концепція - це просто "реалізація, документування та розкриття ваших хаків". Ви можете застосувати це мислення до всього.
Справжня робота, пов’язана зі стиком. Css, полягає у залученні вашої безпосередньої команди (розробників), а потім поінформованості бізнесу / прем’єр-менеджерів / майстрів скраму / BA / власників продуктів (і так далі) про те, що продукт іноді включатиме менше -ніж ідеальний код, але цей код існує для задоволення бізнес-вимог.
Скажіть їм, що ви ізолюєте та документуєте хаки, і виділіть трохи часу на розробку, щоб прибрати речі. Простіше скласти бізнес-аргумент для впорядкування кодової бази, якщо ви можете кількісно її визначити. Просто кажучи своєму керівнику проекту: "У мене є кілька речей, які слід привести в порядок, перш ніж я зможу перейти до функції X", це не завжди вирішить! Візьміть список речей своєму прем’єр-міністру і спробуйте отримати південного спринтерського часу, щоб провести прибирання.
Ідея posti.css полягає просто у тому, щоб зробити ваші хаки більш прозорими, кількісно виміряними та ізольованими. Що робити з цією інформацією, залежить від вас!
