Pasak BSkyB vyresniojo vartotojo sąsajos kūrėjo Harry Robertso, kūrėjai turėtų naudoti sąvoką, vadinamą „shame.css“, norėdami nutildyti bet kokį greitai pataisomą „nulaužti“ CSS.
Robertsas savo tinklaraščio įraše paaiškino, kad tai potencialiai neleis kūrėjams matyti visoje CSS užklijuotų įsilaužimų ir taip manys, kad tokie dalykai yra priimtini pagal nutylėjimą.
Be to, straipsnyje pažymėta, kad toks požiūris, jei jis yra tinkamai dokumentuotas ir pateikiamas kartojimo priemonės, gali padėti greičiau pereiti prie švaresnio CSS projektuose, kuriuose buvo naudojami nulaužimai (dėl kokių nors priežasčių).
.net kalbėjo su Robertsu (HB) apie CSS įsilaužimą ir galimus „shame.css“ privalumus, jei jie bus tinkamai naudojami.
.net: Ar manote, kad kai kurie pramonės žmonės linkę nerealiai vertinti (tikiuosi) trumpalaikių įsilaužimų poreikį norint, kad svetainė veiktų?
HR: Didelis laikas. Jei dirbate svetainėje ar produktuose, kurie uždirba milijonus svarų per metus, visas klaidas, lūžimus ar keistenybes reikia kuo greičiau pašalinti. Jūsų produkto savininkui nerūpi, ar jūsų CSS yra tobulas - jiems rūpi, kad svetainė veiktų ir veiktų bei pažymėtų šias pajamas. Geras kodas yra svarbu, o įsilaužimai toli gražu nėra idealūs, tačiau manyti, kad visada galima išvengti įsilaužimų ir trumpalaikių / greitų pataisymų, nėra naudinga.
.net: Taigi, jūs sakytumėte, kad tai tik būtinas blogis versle?
HR: Kai klientas kvėpuoja jums kaklu - arba funkcija sugadinta tiesioginėje svetainėje - turite įsitikinti, kad esate patenkinti tinkamais suinteresuotaisiais subjektais. Jei praleisite valandą, rašydami tobulą dalyką, kurį per dvi minutes galėjote paviršutiniškai ištaisyti, sakyčiau, kad išlaikote ne tą žmogų, ty save patį!
Savo darbe pastebėjau, kad įsilaužimų „poreikis“ gana proporcingai didėja atsižvelgiant į projekto dydį, tačiau geras dalykas yra tas, kad vėliau taip pat turėsite daugiau laiko skirti šiems įsilaužimams pašalinti.
.net: Kur atsiranda „shame.css“. Su šia koncepcija, ką konkrečiai laikote įsilaužimu į CSS?
HR: Kažkas, ką buvo galima padaryti geriau, suteikė daugiau laiko. Sunku sugalvoti pavyzdžių, kurie nėra kontekste, bet manau, kad jūs dažnai sužinosite, kai kažkas yra nulaužtas. Parašėte ką nors, ko gėdėtumėtės paaiškinti kolegai? Tai tikriausiai nulaužė!
Todėl shame.css yra failo sudarymas iš dalykų, kuriuos galėjote padaryti geriau, ir kad galite padaryti geriau, kai atėjo laikas juos peržiūrėti. Tai iš tikrųjų savarankiškai rašomų darbų sąrašas - įsilaužimų failas, kurį įdėjote į vieną pusę, kad pagalvotumėte, kai turėsite daugiau laiko.
.net: Savo straipsnyje jūs paminėjate įsilaužimų dokumentavimą, bet ar nėra argumentų, kad kūrėjai vis tiek turėtų labiau dokumentuoti CSS, o ne tik dėl įsilaužimų?
HR: Taip! Jei yra vienas dalykas, kurį visi kūrėjai turėtų padaryti daugiau, tai rašo komentarus. Turėtumėte pakomentuoti viską, kas nėra akivaizdu vien iš kodo. Dokumentuokite savo kodą, kad, jei grįžtant namo jus užkluptų autobusas, jūsų kolega galėtų jį perimti kitą dieną.
.net: Ką jūs siūlote integruoti „shame.css“?
HR: Jei naudojate išankstinį procesorių, @import gėda. [scss | mažiau | tt] failą iškart pabaigoje, idealiu atveju. (Tai visada gali sukelti specifiškumo ir šaltinių užsakymo problemų, todėl jūsų rida gali skirtis.)
Jei nenaudojate išankstinio procesoriaus, bet turite deramą kūrimo procesą, visas jūsų CSS turėtų būti sujungtas ir susumuotas prieš diegiant, taigi vėlgi „shame.css“ gali prisukti prie to pabaigos.
Jei nenaudojate išankstinio procesoriaus ir Jūs neturite kūrimo proceso, tada vieną, tikriausiai turėtumėte tai išspręsti, ir du, tikriausiai, geriausias pasirinkimas yra įsilaužimų skyrius jūsų stiliaus lapo pabaigoje. „Shame.css“ nėra skirtas viešam žiūrėjimui, todėl ant žymėjimo niekada neturėkite atskiro stiliaus lapo, kurį iškviečia nuorodos elementas. Turėtumėte pateikti tik vieną sujungtą ir susiaurintą stiliaus lapą.
.net: Jei „shame.css“ kaip sąvoka iš tikrųjų pasiseka, kaip, jūsų manymu, tai galėtų pakeisti dizaino procesą ir apskritai svetaines?
HR: „Shame.css“ yra toks pat naudingas, kaip ir jį įgyvendinantys kūrėjai. Viskas gerai ir gerai atskirti ir užfiksuoti įsilaužimus, tačiau jei niekada jų nepašalinsite ir neperžiūrėsite, esate tiesiog tame pačiame laive kaip ir anksčiau.
Man gėda.css reiškia platesnį poslinkį vystymesi; nereikia apsiriboti CSS. Koncepcija tėra „įsisąmoninimas, dokumentavimas ir taškas“. Tokį mąstymą galite pritaikyti viskam.
Tikrasis darbas, susijęs su „shame.css“, yra jūsų tiesioginės komandos (kūrėjų) įtraukimas, o tada verslo / PM / scrum meistrų / BA / produktų savininkų (ir pan.) Informavimas apie tai, kad produktas kartais apima mažiau - nei idealus kodas, bet kad šis kodas egzistuoja siekiant patenkinti verslo reikalavimus.
Pasakykite jiems, kad izoliuojate ir dokumentuojate įsilaužimus, ir skirkite šiek tiek laiko kūrimui, kad sutvarkytumėte reikalus. Lengviau sukurti verslo pagrindą, kaip sutvarkyti kodų bazę, jei galite ją įvertinti kiekybiškai. Paprasčiausiai pasakius savo projekto vadovui: „Aš turiu kai ką sutvarkyti, kad galėčiau pereiti prie X funkcijos“, tai ne visada sumažins! Pasiimkite dalykų sąrašą į savo premjerą ir pabandykite gauti pusę dienos sprinto laiko, kurį galite praleisti valydami.
„Shame.css“ idėja yra tiesiog padaryti jūsų įsilaužimus skaidresnius, kiekybiškai įvertinamus ir izoliuotus. Tik nuo jūsų priklauso, ką darysite su ta informacija!
