Udviklere bør bruge et koncept kaldet shame.css til at silo enhver quick-fix 'hack' CSS i projekter, ifølge Harry Roberts, senior UI-udvikler hos BSkyB.
Roberts forklarede i et blogindlæg, at dette potentielt ville forhindre udviklere i at se hacks pebret i hele CSS og derved synes, at sådanne ting er acceptabelt som standard.
Derudover bemærkede artiklen, at en sådan tilgang, hvis den var korrekt dokumenteret og ledsaget af midlerne til iterering, kunne muliggøre hurtigere progression mod renere CSS i projekter, hvor der blev brugt hacks (uanset årsag).
.net talte til Roberts (HB) om hacking af CSS og de potentielle fordele, som shame.css kunne medføre, hvis de blev brugt korrekt.
.net: Tror du, at der er en tendens fra nogle mennesker i branchen til at være urealistiske med hensyn til behovet for (forhåbentlig) kortsigtede hacks for at få et websted til at fungere?
HR: Stor tid. Hvis du arbejder på et websted eller et produkt, der tjener millioner af pund om året, skal eventuelle fejl, brud eller besynderheder rettes så hurtigt som muligt. Din produktejer er ligeglad med, om din CSS er perfekt - de bryr sig om, at webstedet er op og funktionelt og tikker over denne indtægt. God kode er vigtigt, og hacks er langt fra ideelle, men at tænke, at du altid kan forhindre hacks og kortsigtede / hurtige rettelser er skib.
.net: Så du vil sige, at de bare er et nødvendigt onde inden for forretningen?
HR: Når en klient trækker vejret i nakken - eller hvis en funktion er brudt på et live site - skal du sørge for at holde de rigtige interessenter glade. Hvis du bruger en time på at skrive den perfekte løsning til noget, du kunne have overfladisk rettet på to minutter, vil jeg sige, at du holder den forkerte person lykkelig - dvs. dig selv!
I mit eget arbejde har jeg fundet, at 'behovet' for hacks stiger ret forholdsmæssigt med størrelsen på projektet, men det gode ved det er, at du sandsynligvis også senere vil have mere projekttid dedikeret til at rette disse hacks.
.net: Hvilket er hvor shame.css kommer ind. Hvad med dette koncept betragter du specifikt som et CSS-hack?
HR: Noget, der kunne have været gjort bedre, givet mere tid. Det er svært at tænke på eksempler uden for sammenhængen, men jeg tror, du ofte ved, hvornår noget er et hack. Skrevet noget, som du ville skamme dig over at forklare til en kollega? Det er sandsynligvis et hack!
Derfor handler shame.css om at oprette en fil med ting, du kunne have gjort bedre, og at du kan gøre det bedre, når du har tid til at besøge dem igen. Det er virkelig en selvskrivende opgaveliste - en fil med hacks, som du lægger til side for at tænke på, når du har mere tid.
.net: I din artikel nævner du at dokumentere hacks, men er der ikke et argument, som udviklere generelt skal dokumentere CSS mere alligevel, snarere end bare for hacks?
HR: Ja! Hvis der er en ting, som alle udviklere skal gøre mere, skriver det kommentarer. Du bør kommentere alt, hvad der ikke umiddelbart er tydeligt fra koden alene. Dokumenter din kode, så din kollega kan overtage den næste dag, hvis du bliver ramt af en bus på vej hjem.
.net: Hvad angår integrering af shame.css, hvad foreslår du?
HR: Hvis du bruger en forprocessor, @importere det skam. [scss | mindre | etc] fil lige i slutningen, ideelt set. (Dette kan altid føre til specificitet og kildeordreproblemer, så din kilometertal kan variere.)
Hvis du ikke bruger en forprocessor, men har en anstændig byggeproces, skal al din CSS sammenkædes og minificeres inden implementering, så skam.css kan igen boltes til slutningen af det.
Hvis du ikke bruger en forprocessor og du har ikke en byggeproces, så en, du skal nok rette det, og to, en hacksektion i slutningen af dit stilark er sandsynligvis din bedste chance. Shame.css er ikke beregnet til offentlig visning, så har aldrig et separat stilark kaldet af et linkelement i din markering. Du skal kun vise et sammenkædet og formindsket typografiark.
.net: Hvis shame.css som et koncept virkelig starter, hvordan tror du det kan ændre designprocessen og websteder generelt?
HR: Shame.css er kun lige så nyttigt som de udviklere, der implementerer det. Det er godt og godt at isolere og dokumentere hacks, men hvis du aldrig retter eller besøger dem igen, er du bare i samme båd som før.
For mig signalerer shame.css et bredere skift i udvikling; det behøver ikke at være begrænset til CSS. Konceptet er kun 'at realisere, dokumentere og gøre et punkt i dine hacks'. Du kan anvende denne tænkning på alt.
Det virkelige arbejde involveret med shame.css er at få dit nærmeste team (udviklere) om bord og derefter gøre virksomheden / PM'er / scrum-mestre / BA'er / produkt ejere (og så videre) opmærksomme på, at et produkt undertiden vil omfatte mindre -en ideel kode, men at denne kode findes for at opfylde forretningskrav.
Fortæl dem, at du isolerer og dokumenterer hacks, og få noget tid til udvikling til at rydde op. Det er lettere at lave en forretningssag til at rydde op i en kodebase, hvis du kan kvantificere den. Du skal bare fortælle din projektleder, "Jeg har nogle ting at rydde op, inden jeg kan gå videre til Feature X", klipper ikke altid det! Tag en liste over ting til din premierminister, og prøv at få en halv dags sprinttid til at bruge oprydning.
Ideen bag shame.css er simpelthen at gøre dine hacks mere gennemsigtige, kvantificerbare og isolerede. Det er op til dig, hvad du gør med disse oplysninger!
