Распрацоўшчыкі павінны выкарыстоўваць канцэпцыю, якая называецца 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: Што тычыцца інтэграцыі стыму стыму.css, што вы прапануеце?
HR: Калі вы выкарыстоўваеце прэпрацэсар, @import ганьба. [scss | менш | і г.д.] файл у самым канцы, у ідэале. (Гэта заўсёды можа прывесці да спецыфікі і праблем з замовай крыніцы, таму ваш прабег можа адрознівацца.)
Калі вы не карыстаецеся прэпрацэсарам, але маеце годны працэс зборкі, перад разгортваннем увесь ваш CSS павінен быць аб'яднаны і зведзены да мінімуму, таму, зноў жа, shame.css можа прыкруціць яго да канца.
Калі вы не выкарыстоўваеце прэпрацэсар і у вас няма працэсу зборкі, то адзін, вы, верагодна, павінны гэта выправіць, і два, раздзел хакаў у канцы вашай табліцы стыляў, напэўна, лепшы выбар. Shame.css не прызначаны для публічнага прагляду, таму ніколі не выкарыстоўвайце асобную табліцу стыляў, якую выклікае элемент спасылкі. Вы павінны падаваць толькі адзін аб'яднаны і мінімізаваны табліца стыляў.
.net: Калі shame.css як паняцце сапраўды ўзмацняецца, як вы лічыце, як гэта можа змяніць працэс дызайну і сайты ў цэлым?
HR: Shame.css настолькі ж карысны, як і распрацоўшчыкі, якія яго ўкараняюць. Гэта ўсё добра ізалявана і дакументавана ўзламана, але калі вы ніколі не выправіце іх і не пераглядзіце, вы проста ў той самай лодцы, што і раней.
Для мяне shame.css сігналізуе пра больш шырокі зрух у развіцці; гэта не трэба абмяжоўваць CSS. Канцэпцыя проста "ўсведамленне, дакументаванне і выкладванне вашых узломаў". Вы можаце прымяніць гэта мысленне да ўсяго.
Сапраўдная праца, звязаная з shame.css, заключаецца ў тым, каб узяць на ўзбраенне вашу непасрэдную каманду (распрацоўшчыкаў), а потым зрабіць так, каб бізнес / PM / майстры scrum / BA / уладальнікі прадуктаў (і гэтак далей) ведалі пра тое, што прадукт часам уключае менш -затым ідэальны код, але гэты код існуе для задавальнення бізнес-патрабаванняў.
Скажыце ім, што вы ізалюеце і дакументуеце хакі, і пакіньце час на распрацоўку, прысвечаны прыборцы. Прасцей зрабіць бізнес-наводку для прывядзення ў парадак кодавай базы, калі вы можаце ацаніць яе колькасна. Проста кажучы свайму кіраўніку праекта: "У мяне ёсць рэчы, якія трэба прывесці ў парадак, перш чым я магу перайсці да функцыі X", не заўсёды гэта будзе скарочана! Аднясіце спіс рэчаў да свайго прэм'ер-міністра і паспрабуйце атрымаць паўдзённы спрынтарскі час на ўборку.
Ідэя postim.css проста зрабіць вашыя хакі больш празрыстымі, вымераемымі і ізаляванымі. Што рабіць з гэтай інфармацыяй, залежыць ад вас!
