Razvijalci bi morali uporabiti koncept, imenovan shame.css, da v projektih poiščejo kakršen koli hiter CSS v projektih, meni Harry Roberts, starejši razvijalec uporabniškega vmesnika pri BSkyB.
Roberts je v objavi v blogu pojasnil, da bi to razvijalcem potencialno preprečilo, da bi v celotnem CSS-ju prihajalo do vdorov in s tem mislili, da so take stvari privzeto sprejemljive.
Poleg tega je članek opozoril, da lahko tak pristop, če je ustrezno dokumentiran in ga spremljajo sredstva za ponovitev, omogoči hitrejši napredek k čistejšemu CSS v projektih, kjer so bili uporabljeni vdori (iz kakršnega koli razloga).
.net se je z Robertsom (HB) pogovarjal o vdoru CSS-ja in potencialnih prednostih, ki bi jih lahko sramota.css prinesla ob pravilni uporabi.
.net: Ali menite, da nekateri ljudje v panogi težijo k nerealnosti glede potrebe po (upam) kratkoročnih vdorih, da bi spletno mesto delovalo?
HR: Velik čas. Če delate na spletnem mestu ali izdelku, ki zasluži milijone funtov na leto, je treba kakršne koli napake, okvare ali domislice popraviti čim prej. Vašega lastnika izdelka ne zanima, ali je vaš CSS popoln - skrbi jih, da je spletno mesto delujoče in funkcionalno ter odšteva ta prihodek. Dobra koda je pomembno in vdori še zdaleč niso idealni, toda če mislite, da vedno lahko preprečite vdore in kratkoročne / hitre popravke, je preprosto.
.net: Torej bi rekli, da so samo nujno zlo znotraj podjetja?
HR: Ko vam stranka diha za vrat - ali je funkcija na spletnem mestu v živo pokvarjena - morate poskrbeti, da boste zadovoljni s pravimi deležniki. Če eno uro pišete popoln popravek za nekaj, kar bi lahko površno popravili v dveh minutah, bi rekel, da osrečujete napačno osebo - torej sebe!
V svojem delu sem ugotovil, da se "potreba" po vdorih dokaj sorazmerno povečuje z velikostjo projekta, toda dobro pri tem je, da boste kasneje verjetno imeli več projektnega časa, namenjenega odpravljanju teh vdorov.
.net: Kam pride sramota.css. S tem konceptom, kaj konkretno menite za vdor v CSS?
HR: Nekaj, kar bi bilo mogoče narediti bolje, če bi imeli več časa. Težko si je zamisliti primere izven konteksta, vendar mislim, da boste pogosto vedeli, kdaj je kaj kramp. Napisali nekaj, česar bi se sramovali razložiti kolegu? To je verjetno kramp!
Zato je sram.css namenjen ustvarjanju datoteke stvari, ki bi jih lahko naredili bolje, in da lahko to storite bolje, ko jih imate čas, da jih ponovno obiščete. V resnici gre za samostojni seznam opravil - spis kramp, ki ga postavite na stran, da razmislite, kdaj imate več časa.
.net: V svojem članku omenjate dokumentiranje vdorov, toda ali ni nobenega argumenta, da bi morali razvijalci na splošno vseeno bolj dokumentirati CSS in ne samo za vdore?
HR: Ja! Če bi morali vsi razvijalci narediti nekaj več, pišejo komentarje. Komentirajte vse, kar iz kode ni takoj razvidno. Dokumentirajte svojo kodo, tako da vas bo kolega naslednji dan lahko prevzel, če vas na poti domov zadene avtobus.
.net: Kaj predlagate v smislu vključevanja sram.css?
HR: Če uporabljate predprocesor, @import sramota. [scss | manj | itd.] datoteko na koncu, v idealnem primeru. (To lahko vedno privede do specifičnosti in težav z naročilom vira, zato se lahko vaša kilometrina razlikuje.)
Če ne uporabljate predprocesorja, vendar imate dostojen postopek izdelave, je treba pred uvedbo vse vaše CSS združiti in pomanjšati, tako da se lahko sramota.css spet prilepi na konec.
Če ne uporabljate predprocesorja in če nimate postopka gradnje, potem enega, bi to verjetno morali popraviti, in dva, odsek o kraji na koncu vašega sloga je verjetno vaša najboljša stava. Shame.css ni namenjen javnemu ogledu, zato pri označevanju nikoli ne imejte ločenega slogovnega lista, ki ga pokliče element povezave. Postrezite lahko samo en združen in pomanjšan slog.
.net: Če se sramota.css kot koncept resnično uveljavi, kako mislite, da bi lahko spremenil postopek oblikovanja in spletne strani na splošno?
HR: Shame.css je uporaben le toliko kot razvijalci, ki ga izvajajo. Vse je dobro in dobro izolirati in dokumentirati vdore, toda če jih nikoli ne popravite ali znova obiščete, ste v istem čolnu kot prej.
Zame sram.css signalizira širši razvojni premik; ni treba omejiti na CSS. Koncept je zgolj "uresničitev, dokumentiranje in poudarjanje svojih vdorov". To razmišljanje lahko uporabite za vse.
Dejansko delo, ki ga vključuje sramota.css, je vključitev vaše neposredne ekipe (razvijalcev) in nato ozaveščanje podjetij / PM-jev / mojstrov scrumov / BA-jev / lastnikov izdelkov (in tako naprej) o tem, da bo izdelek včasih vseboval manj -ko kot idealna koda, vendar ta koda obstaja, da ustreza poslovnim zahtevam.
Povejte jim, da izolirate in dokumentirate vdore, in si zagotovite nekaj časa za pospravljanje stvari. Lažje je poslovno utemeljiti pospravljanje kode, če jo lahko kvantificirate. Preprosto povejte svojemu vodji projekta: "Nekaj stvari moram pospraviti, preden se lahko premaknem na Feature X", tega ne bo vedno rezalo! Vzemite seznam stvari svojemu premierju in poskusite dobiti pol dneva šprinta za čiščenje.
Ideja, ki stoji za sram.css, je preprosto narediti svoje vdore bolj pregledne, merljive in izolirane. Od vas je odvisno, kaj boste storili s temi informacijami!
