Dapat gumamit ang mga developer ng isang konsepto na tinawag na hiya.css upang maloko ang anumang mabilis na pag-aayos ng 'hack' CSS sa mga proyekto, ayon kay Harry Roberts, nakatatandang developer ng UI sa BSkyB.
Ipinaliwanag ni Roberts sa isang post sa blog na potensyal nitong ihihinto ang mga developer na makakita ng mga pag-hack na may paminta sa buong CSS at sa gayo'y sa tingin nila ang mga ganitong bagay ay katanggap-tanggap bilang default.
Bilang karagdagan, nabanggit ng artikulo na ang gayong diskarte, kung maayos na naidokumento at sinamahan ng mga paraan upang umulit, ay maaaring paganahin ang mas mabilis na pag-unlad patungo sa mas malinis na CSS sa mga proyekto kung saan ginamit ang mga pag-hack (para sa anumang kadahilanan).
Nagsalita si net kay Roberts (HB) tungkol sa pag-hack ng CSS at ang mga potensyal na bentahe na kahihiyan. maaaring dalhin ng mga CSS kung ginamit nang wasto.
.net: Sa palagay mo ba may pagkahilig mula sa ilang mga tao sa industriya na maging hindi makatotohanang tungkol sa pangangailangan para sa (sana) mga panandaliang pag-hack upang gumana ang isang site?
HR: Malaking oras. Kung nagtatrabaho ka sa isang site o produkto na kumikita ng milyun-milyong pounds bawat taon, ang anumang mga bug, breakage o quirks ay nangangailangan ng pag-aayos sa lalong madaling panahon. Walang pakialam ang may-ari ng iyong produkto kung ang iyong CSS ay perpekto - nagmamalasakit sila na ang site ay buo at gumagana at na-tick sa kita na iyon. Magandang code ay mahalaga, at ang mga pag-hack ay malayo sa perpekto, ngunit upang isiping palagi mong maiiwasan ang mga pag-hack at panandaliang / mabilis na pag-aayos ay wala na.
.net: Kaya sasabihin mo na sila ay isang kinakailangang kasamaan lamang sa loob ng negosyo?
HR: Kapag hinihinga ng isang kliyente ang iyong leeg - o ang isang tampok ay nasira sa isang live na site - kailangan mong tiyakin na pinapanatili mong masaya ang tamang mga stakeholder. Kung gumugol ka ng isang oras sa pagsusulat ng perpektong pag-aayos para sa isang bagay na maaari mong mabawasan sa loob ng dalawang minuto, sasabihin kong pinapanatili mong masaya ang maling tao - ibig sabihin, ang iyong sarili!
Sa sarili kong trabaho, nahanap ko ang 'pangangailangan' para sa mga pag-hack na medyo tumataas nang proporsyonal sa laki ng proyekto, ngunit ang magandang bagay tungkol dito ay malamang na mayroon ka ring mas maraming oras sa proyekto na nakatuon sa pag-aayos ng mga pag-hack na iyon.
.net: Alin kung saan nagmumula ang mga hiya.css. Sa konseptong iyon, anong partikular na isinasaalang-alang mo ang isang CSS hack?
HR: Isang bagay na maaaring magawa nang mas mahusay na bigyan ng mas maraming oras. Mahirap mag-isip ng mga halimbawa na wala sa konteksto, ngunit sa palagay ko madalas mong malalaman kung ang isang bagay ay isang pag-hack. Sumulat ng isang bagay na ikahiya mong ipaliwanag sa isang kasamahan? Malamang na iyon ay isang hack!
Samakatuwid, ang kahiya-hiya.css ay tungkol sa paggawa ng isang file ng mga bagay na maaaring nagawa mong mas mahusay, at na maaari mong gawin nang mas mahusay kapag may oras ka na upang muling bisitahin ang mga ito. Ito ay isang listahan ng dapat gawin na pagsulat ng sarili, talaga - isang file ng mga pag-hack na inilagay mo sa isang panig upang pag-isipan kung mayroon kang mas maraming oras.
.net: Sa iyong artikulo, binanggit mo ang pagdodokumento ng mga pag-hack, ngunit hindi ba mayroong isang tagabuo ng argumento na dapat sa pangkalahatan ay nagdodokumento ng CSS pa, sa halip na para lamang sa mga pag-hack?
HR: Oo! Kung mayroong isang bagay na dapat gawin ng lahat ng mga developer, nagsusulat ito ng mga komento. Dapat kang magkomento ng anumang hindi kaagad halata mula sa code lamang. Idokumento ang iyong code upang, kung ikaw ay mabangga ng isang bus pauwi, maaaring sakupin ng iyong kasamahan sa susunod na araw.
.net: Sa mga tuntunin ng pagsasama ng hiya.css, ano ang iminumungkahi mo?
HR: Kung gumagamit ng isang preprocessor, @angkat ang nakakahiya. [scss | mas kaunti | atbp] mag-file ng tama sa dulo, perpekto. (Maaaring palaging humantong ito sa pagiging tiyak at mga problema sa pagkakasunud-sunod ng pagkakasunud-sunod, kaya't maaaring mag-iba ang iyong agwat ng mga milya.)
Kung hindi ka gumagamit ng isang preprocessor, ngunit magkaroon ng disenteng proseso ng pagbuo, ang lahat ng iyong CSS ay dapat na magkakasama at maliitin bago ang pag-deploy, sa gayon, muli, kahihiyan. Ang mga cs ay maaaring i-bolt sa katapusan nito.
Kung hindi ka gumagamit ng isang preprocessor at wala kang isang proseso ng pagbuo, kung gayon ang isa, marahil ay dapat mong ayusin iyon, at dalawa, isang seksyon ng mga pag-hack sa dulo ng iyong styleheet marahil ang iyong pinakamahusay na mapagpipilian. Ang shame.css ay hindi inilaan para sa pagtingin sa publiko, kaya't hindi kailanman magkakaroon ng isang hiwalay na styleheet na tinawag ng isang elemento ng link sa iyong mark-up. Dapat kang maghatid ng isang concatenated at minified na styleheet lamang.
.net: Kung ang kahihiyan.css bilang isang konsepto ay talagang aalis, paano sa palagay mo maaaring mabago nito ang proseso ng disenyo at mga website sa pangkalahatan?
HR: Ang Shame.css ay kapaki-pakinabang lamang bilang mga developer na nagpapatupad nito. Mabuti at mahusay ang paghihiwalay at pagdodokumento ng mga pag-hack, ngunit kung hindi mo kailanman ayusin o muling bisitahin ang mga ito, nasa parehong bangka ka lang dati.
Para sa akin, ang kahihiyan.css ay nagpapahiwatig ng isang mas malawak na paglilipat sa pag-unlad; hindi ito kailangang limitado sa CSS. Ang konsepto ay simpleng 'pagkakatanto, pagdodokumento at paggawa ng isang punto ng iyong mga pag-hack'. Maaari mong ilapat ang pag-iisip na iyon sa lahat.
Ang tunay na gawain na kasangkot sa kahihiyan. Ang Cs ay nakukuha ang iyong agarang koponan (mga developer) sa board, at pagkatapos ay ginagawa ang mga negosyo / PM / scrum masters / BAs / mga may-ari ng produkto (at iba pa) na may kamalayan sa katotohanan na ang isang produkto ay minsan ay masasama ang mas kaunti -than-ideal code, ngunit mayroon ang code na ito upang matugunan ang mga kinakailangan sa negosyo.
Sabihin sa kanila na pinaghiwalay at idodokumento mo ang mga pag-hack at kumuha ng ilang oras sa pag-unlad na inilalaan upang maayos ang mga bagay. Mas madaling gumawa ng isang kaso sa negosyo para sa pag-aayos ng isang code-base kung maaari mo itong bilangin. Ang simpleng pagsasabi sa iyong manager ng proyekto, "Mayroon akong ilang mga bagay na aayusin bago ako lumipat sa Tampok X" ay hindi palaging puputulin! Kumuha ng isang listahan ng mga bagay sa iyong PM at subukan at makakuha ng kalahating araw na oras ng sprint upang gugulin ang paglilinis.
Ang ideya sa likod ng hiya.css ay simpleng gawing mas transparent, nabibilang at nakahiwalay ang iyong mga pag-hack. Nasa sa iyo ang gagawin mo sa impormasyong iyon!
