I følge Harry Roberts, senior UI-utvikler ved BSkyB, bør utviklere bruke et konsept som heter shame.css for å silo eventuelle quick-fix 'hack' CSS i prosjekter.
Roberts forklarte i et blogginnlegg at dette potensielt ville stoppe utviklere å se hack som er krydret i hele CSS og dermed tro at slike ting er akseptable som standard.
I tillegg bemerket artikkelen at en slik tilnærming, hvis den er riktig dokumentert og ledsaget av virkemidlene til å gjenta, kan muliggjøre raskere progresjon mot renere CSS i prosjekter der hack ble brukt (av en eller annen grunn).
.net snakket med Roberts (HB) om hacking av CSS og de potensielle fordelene som shame.css kan medføre hvis det brukes riktig.
.net: Tror du det er en tendens fra noen mennesker i bransjen til å være urealistiske med hensyn til behovet for (forhåpentligvis) kortsiktige hack for å få et nettsted til å fungere?
HR: Stor tid. Hvis du jobber på et nettsted eller et produkt som tjener millioner av pounds per år, må eventuelle feil, ødeleggelser eller særegenheter rettes opp så snart som mulig. Produkteieren din bryr seg ikke om CSS-en din er perfekt - de bryr seg om at nettstedet er oppe og fungerer og tikker over inntektene. God kode er viktig, og hacks er langt fra ideelle, men å tro at du alltid kan forhindre hacks og kortsiktige / raske løsninger er skip.
.net: Så du vil si at de bare er et nødvendig onde i virksomheten?
HR: Når en klient puster nakken din - eller en funksjon er ødelagt på et live nettsted - må du sørge for at du holder de rette interessentene fornøyde. Hvis du bruker en time på å skrive den perfekte løsningen for noe du kan ha overfladisk løst på to minutter, vil jeg si at du holder feil person lykkelig - dvs. deg selv!
I mitt eget arbeid har jeg funnet at 'behovet' for hack øker ganske proporsjonalt med størrelsen på prosjektet, men det som er bra med det er at du også sannsynligvis senere vil ha mer tid til å fikse disse hackene.
.net: Hvor kommer shame.css inn. Med dette konseptet, hva ser du spesifikt på som et CSS-hack?
HR: Noe som kunne vært gjort bedre gitt mer tid. Det er vanskelig å tenke på eksempler utenfor konteksten, men jeg tror du ofte vet når noe er et hack. Skrevet noe du vil skamme deg over å forklare for en kollega? Det er sannsynligvis et hack!
Derfor handler shame.css om å lage en fil med ting du kunne ha gjort bedre, og at du kan gjøre det bedre når du har tid til å se dem på nytt. Det er egentlig en selvskrevende oppgaveliste - en fil med hack som du legger til den ene siden for å tenke på når du har mer tid.
.net: I artikkelen din nevner du å dokumentere hack, men er det ikke noe argument som utviklere generelt bør dokumentere CSS mer uansett, i stedet for bare for hack?
HR: Ja! Hvis det er en ting alle utviklere bør gjøre mer, er det å skrive kommentarer. Du bør kommentere alt som ikke er umiddelbart åpenbart fra koden alene. Dokumenter koden din slik at hvis du blir truffet av en buss på vei hjem, kan kollegaen overta dagen etter.
.net: Når det gjelder å integrere shame.css, hva foreslår du?
HR: Hvis du bruker en forprosessor, @import de skam. [scss | mindre | etc] filen rett på slutten, ideelt sett. (Dette kan alltid føre til spesifisitet og problemer med kildeordren, så kjørelengden din kan variere.)
Hvis du ikke bruker en forprosessor, men har en anstendig byggeprosess, bør all CSS sammenkobles og minifiseres før distribusjon, så igjen, shame.css kan skrues fast til slutten av det.
Hvis du ikke bruker en forprosessor og du ikke har en byggeprosess, så en, bør du sannsynligvis fikse det, og to, en hackseksjon på slutten av stilarket ditt, er sannsynligvis det beste alternativet. Shame.css er ikke ment for offentlig visning, så ha aldri et eget stilark kalt av et lenkeelement i oppgraderingen din. Du bør bare vise ett sammenkoblet og forminsket stilark.
.net: Hvis shame.css som konsept virkelig tar av, hvordan tror du det kan endre designprosessen og nettsteder generelt?
HR: Shame.css er bare like nyttig som utviklerne som implementerer den. Det er vel og bra å isolere og dokumentere hack, men hvis du aldri fikser eller besøker dem, er du bare i samme båt som før.
For meg signaliserer shame.css et bredere skifte i utvikling; det trenger ikke å være begrenset til CSS. Konseptet er bare 'å realisere, dokumentere og gjøre et poeng med hackene dine'. Du kan bruke den tankegangen på alt.
Det virkelige arbeidet involvert med shame.css er å få ditt nærmeste team (utviklere) om bord, og deretter gjøre virksomheten / PM / scrum-mestere / BA / produkt eiere (og så videre) oppmerksom på det faktum at et produkt noen ganger vil inneholde mindre -en ideell kode, men at denne koden eksisterer for å oppfylle forretningskravene.
Fortell dem at du isolerer og dokumenterer hacks, og få litt utviklingstid tildelt for å rydde opp. Det er lettere å lage en business case for å rydde i en kodebase hvis du kan tallfeste den. Bare å si til prosjektlederen din: "Jeg har noen ting å rydde før jeg kan gå videre til Feature X" vil ikke alltid kutte det! Ta en liste over ting til statsministeren din, og prøv å få en halv dag med sprint til å rydde opp.
Ideen bak shame.css er rett og slett å gjøre hackene dine mer gjennomsiktige, kvantifiserbare og isolerte. Det er opp til deg hva du gjør med den informasjonen!
