Разработчиците трябва да използват концепция, наречена shame.css, за да силозират всеки хакс за бързо отстраняване на CSS в проекти, според Хари Робъртс, старши разработчик на потребителски интерфейс в BSkyB.
Робъртс обясни в публикация в блог, че това потенциално би спряло разработчиците да виждат хакове в CSS и по този начин да мислят, че такива неща са приемливи по подразбиране.
Освен това в статията се отбелязва, че такъв подход, ако е правилно документиран и придружен от средствата за итерация, може да позволи по-бърза прогресия към по-чист CSS в проекти, където са използвани хакове (по каквато и да е причина).
.net говори с Робъртс (НВ) за хакване на CSS и потенциалните предимства, които срамът. css може да донесе, ако се използва правилно.
.net: Смятате ли, че има тенденция от някои хора в бранша да бъдат нереалистични относно необходимостта от (надявам се) краткосрочни хакове, за да заработи сайт?
HR: Много. Ако работите на сайт или продукт, който печели милиони лири годишно, всички грешки, счупвания или странности се нуждаят от отстраняване възможно най-скоро. Собственикът на вашия продукт не се интересува дали вашият CSS е перфектен - те се грижат сайтът да работи и да функционира и да отчита тези приходи. Добър код е важно е и хаковете далеч не са идеални, но да мислите, че винаги можете да предотвратите хакове и краткосрочни / бързи поправки е много.
.net: Значи бихте казали, че те са просто необходимо зло в бизнеса?
HR: Когато клиентът ви диша по врата - или дадена функция е нарушена в сайт на живо - трябва да сте сигурни, че поддържате правилните заинтересовани страни щастливи. Ако прекарате един час в писане на идеалното решение за нещо, което бихте могли да поправите повърхностно за две минути, бих казал, че поддържате грешния човек щастлив - т.е. себе си!
В моята собствена работа открих, че „нуждата“ от хакове се увеличава доста пропорционално на размера на проекта, но хубавото в това е, че по-късно вероятно ще имате и повече време за проекти, посветено на поправянето на тези хакове.
.net: Кое е мястото, където идва срама. css. С тази концепция какво конкретно смятате за хакване на CSS?
HR: Нещо, което би могло да се направи по-добре, като се даде повече време. Трудно е да се измислят примери извън контекста, но мисля, че често ще знаете кога нещо е хак. Написахте нещо, което ще ви е срам да обясните на колега? Това вероятно е хак!
Следователно, shame.css е да създадете файл с неща, които бихте могли да направите по-добре, и че можете да направите по-добре, когато имате време да ги прегледате. Всъщност това е списък със задачи за самонаписване - файл от хакове, който поставяте настрани, за да помислите, когато имате повече време.
.net: В статията си споменавате документиране на хакове, но няма ли аргумент, че разработчиците по принцип трябва да документират CSS повече, а не само за хакове?
HR: Да! Ако има нещо, което всички разработчици трябва да направят повече, това е писане на коментари. Трябва да коментирате всичко, което не се вижда веднага само от кода. Документирайте кода си, така че, ако бъдете ударени от автобус на път за вкъщи, вашият колега може да го поеме на следващия ден.
.net: Що се отнася до интегрирането на shame.css, какво предлагате?
HR: Ако използвате препроцесор, @import на срам. [scss | по-малко | и т.н.] файл в края, в идеалния случай. (Това винаги може да доведе до специфичност и проблеми с поръчката на източника, така че пробегът ви може да варира.)
Ако не използвате препроцесор, но имате приличен процес на изграждане, целият ви CSS трябва да бъде конкатениран и минимизиран преди разгръщането, така че отново, shame.css може да се закрепи към края на това.
Ако не използвате препроцесор и нямате процес на компилация, тогава един, вероятно трябва да го поправите, и две, секцията за хакове в края на вашата таблица със стилове е може би най-добрият ви залог. Shame.css не е предназначен за публично гледане, така че никога не разполагайте с отделна таблица със стилове, извикана от елемент на връзката във вашата надценка. Трябва да обслужвате само един обединен и умален стилов лист.
.net: Ако срам.css като концепция наистина се издигне, как мислите, че може да промени процеса на проектиране и уебсайтовете като цяло?
HR: Shame.css е толкова полезен, колкото и разработчиците, които го прилагат. Всичко е добре и добре да изолирате и документирате хакове, но ако никога не ги поправите или прегледате, вие сте просто в същата лодка, както преди.
За мен срам.css сигнализира за по-широка промяна в развитието; не е необходимо да се ограничава до CSS. Концепцията е просто „реализиране, документиране и обосноваване на вашите хакове“. Можете да приложите това мислене към всичко.
Истинската работа, свързана със срам.css, е привличането на вашия непосредствен екип (разработчици) и след това информирането на бизнеса / PM / scrum master / BAs / собственици на продукти (и т.н.) за факта, че продуктът понякога ще включва по-малко -от идеалния код, но този код съществува, за да отговаря на бизнес изискванията.
Кажете им, че изолирате и документирате хакове и отделете малко време за разработка, за да подредите нещата. По-лесно е да се направи бизнес аргумент за подреждане на кодова база, ако можете да я определите количествено. Просто казвайки на вашия мениджър на проекта, „Имам някои неща, които трябва да подредя, преди да мога да премина към Feature X“, не винаги ще го отрежете! Вземете списък с неща на вашия премиер и се опитайте да получите половин ден спринт, за да прекарате почистване.
Идеята на shame.css е просто да направите вашите хакове по-прозрачни, количествено измерими и изолирани. От вас зависи какво ще правите с тази информация!
