Programeri bi trebali koristiti koncept nazvan shame.css da bi izdvojili bilo koji CSS s brzim popravkom u projektima, prema Harryju Robertsu, višem programeru korisničkog sučelja u BSkyB-u.
Roberts je u objavi na blogu objasnio da bi to potencijalno moglo zaustaviti programere da vide hakere koji se provlače kroz CSS, a time i pomisliti da su takve stvari standardno prihvatljive.
Pored toga, u članku se napominje da bi takav pristup, ako je pravilno dokumentiran i popraćen sredstvima za ponavljanje, mogao omogućiti brži napredak prema čišćem CSS-u u projektima u kojima su korišteni hakovi (iz bilo kojeg razloga).
.net razgovarao je s Robertsom (HB) o hakiranju CSS-a i potencijalnim prednostima koje bi sramota.css mogla donijeti ako se pravilno koristi.
.net: Mislite li da neki ljudi u industriji imaju tendenciju biti nerealni u vezi s potrebom (nadam se) kratkoročnih hakova da bi web mjesto moglo raditi?
HR: Veliko vrijeme. Ako radite na web mjestu ili proizvodu koji zarađuje milijune funti godišnje, sve pogreške, kvarove ili hirove trebate popraviti što je prije moguće. Vlasnika vašeg proizvoda nije briga je li vaš CSS savršen - njima je stalo da web stranica radi i funkcionira te da otkucava taj prihod. Dobar kod je važno i hakovi su daleko od idealnog, ali misliti da uvijek možete spriječiti hakiranje i kratkoročne / brze popravke je naporno.
.net: Pa rekli biste da su samo nužno zlo u poslu?
HR: Kada vam klijent diše za vratom - ili ako je neka značajka slomljena na web mjestu uživo - morate biti sigurni da ćete usrećiti prave dionike. Ako potrošite sat vremena pišući savršeni popravak za nešto što ste mogli površno popraviti u dvije minute, rekao bih da usrećujete pogrešnu osobu - tj. Sebe!
U svom vlastitom radu otkrio sam da se 'potreba' za hakovima prilično proporcionalno povećava s veličinom projekta, ali dobra stvar u tome je što ćete vjerojatno kasnije imati i više projektnog vremena posvećenog popravljanju tih hakova.
.net: Tu dolazi sram.css. S tim konceptom, što konkretno smatrate hakiranjem CSS-a?
HR: Nešto što se moglo učiniti bolje ako se dade više vremena. Teško je razmišljati o primjerima izvan konteksta, ali mislim da ćete često znati kada je nešto hakiranje. Napisao nešto što bi vas bilo sram objasniti kolegi? To je vjerojatno hak!
Stoga je sramota.css o stvaranju datoteke stvari koje ste mogli učiniti bolje i da to možete učiniti bolje kad ih budete trebali posjetiti. To je zapravo spisak zadataka koji se sami napišu - datoteka hakova koju stavite na stranu da biste razmislili kad imate više vremena.
.net: U svom članku spominjete dokumentiranje hakova, ali zar ne postoji argument da bi programeri ionako trebali više dokumentirati CSS, a ne samo za hakiranje?
HR: Da! Ako postoji jedna stvar koju bi svi programeri trebali učiniti više, to je pisanje komentara. Trebali biste komentirati sve što iz koda nije odmah očito. Dokumentirajte svoj kod tako da, ako vas autobus udari na putu kući, vaš kolega to može preuzeti sljedeći dan.
.net: Što se tiče integracije shame.css, što predlažete?
HR: Ako koristite pretprocesor, @uvoz the sramota. [scss | manje | itd.] dosje na kraju, idealno. (To uvijek može dovesti do specifičnosti i problema s narudžbom izvora, tako da vaša kilometraža može varirati.)
Ako ne upotrebljavate pretprocesor, ali imate pristojan postupak izrade, sav vaš CSS trebao bi se spojiti i umanjiti prije postavljanja, tako da se opet, sram.css može pričvrstiti na kraj toga.
Ako ne koristite pretprocesor i nemate postupak izrade, onda jedan, vjerojatno biste to trebali popraviti, a dva, odjeljak o hakovanjima na kraju vašeg lista stilova vjerojatno je vaš najbolji ulog. Shame.css nije namijenjen za javno gledanje, pa zato nikada nemojte imati zasebnu tablicu stilova pozvanu elementom veze u vašem označavanju. Trebali biste poslužiti samo jedan ujedinjeni i umanjeni tabelu stilova.
.net: Ako sram.css kao koncept stvarno krene, kako mislite da bi mogao promijeniti postupak dizajna i web stranice općenito?
HR: Shame.css je koristan samo onoliko koliko su to programeri koji ga implementiraju. Sve je u redu s izolacijom i dokumentiranjem hakova, ali ako ih nikada ne popravite ili ponovno posjetite, jednostavno ste u istom čamcu kao i prije.
Za mene sram.css signalizira širi pomak u razvoju; ne treba biti ograničen na CSS. Koncept je samo 'realiziranje, dokumentiranje i naglašavanje vaših hakova'. To razmišljanje možete primijeniti na sve.
Pravi posao koji uključuje sramotu.css je uključivanje vašeg neposrednog tima (programera), a zatim osvještavanje poduzeća / PM-ova / scrum-majstora / BA-a / vlasnika proizvoda (i tako dalje) o činjenici da će proizvod ponekad sadržavati manje -od idealnog koda, ali da ovaj kôd postoji kako bi udovoljio poslovnim zahtjevima.
Recite im da izolirate i dokumentirate hakove i neka vam se odvoji neko vrijeme za razvoj stvari. Lakše je stvoriti poslovni slučaj za sređivanje baze koda ako je možete kvantificirati. Jednostavno recite svom voditelju projekta: "Moram neke stvari urediti prije nego što prijeđem na značajku X", to neće uvijek smanjiti! Odnesite popis stvari svom premijeru i pokušajte dobiti pola dana sprinta za čišćenje.
Ideja iza shame.css je jednostavno učiniti svoje hakove transparentnijima, kvantificiranima i izoliranima. Na vama je što ćete učiniti s tim informacijama!
