Utvecklare bör använda ett koncept som heter shame.css för att silo alla quick-fix 'hack' CSS i projekt, enligt Harry Roberts, senior UI-utvecklare på BSkyB.
Roberts förklarade i ett blogginlägg att detta potentiellt skulle kunna hindra utvecklare att se hackade hackade i hela CSS och därmed tycker att sådana saker är acceptabla som standard.
Dessutom noterade artikeln att ett sådant tillvägagångssätt, om det är korrekt dokumenterat och åtföljs av sätten att iterera, skulle möjliggöra snabbare utveckling mot renare CSS i projekt där hack användes (av vilken anledning som helst).
.net pratade med Roberts (HB) om hacking av CSS och de potentiella fördelarna som shame.css kan medföra om de används korrekt.
.net: Tror du att det finns en tendens från vissa människor i branschen att vara orealistiska om behovet av (förhoppningsvis) kortvariga hack för att få en webbplats att fungera?
HR: Stort. Om du arbetar på en webbplats eller produkt som tjänar miljontals pund per år måste eventuella buggar, brott eller besvär fixas så snart som möjligt. Din produktägare bryr sig inte om din CSS är perfekt - de bryr sig om att webbplatsen är uppe och fungerar och kryssar för intäkterna. Bra kod är viktigt, och hack är långt ifrån perfekta, men att tro att du alltid kan förhindra hack och korta / snabba lösningar är skepp.
.net: Så du skulle säga att de bara är en nödvändig ondska inom affärer?
HR: När en klient andas ner i nacken - eller om en funktion är trasig på en levande webbplats - måste du se till att du håller rätt intressenter nöjda. Om du spenderar en timme på att skriva den perfekta lösningen för något som du har kunnat fixa på ytan på två minuter, skulle jag säga att du håller fel person lycklig - dvs dig själv!
I mitt eget arbete har jag funnit att ”behovet” av hackar ökar ganska proportionellt med storleken på projektet, men det bra med det är att du också troligtvis senare kommer att ha mer projekttid ägnad åt att fixa dessa hack.
.net: Vilket är där shame.css kommer in. Med det konceptet, vad anser du specifikt som ett CSS-hack?
HR: Något som kunde ha gjorts bättre med mer tid. Det är svårt att tänka på exempel utanför kontext, men jag tror att du ofta vet när något är ett hack. Har du skrivit något som du skulle skämmas för att förklara för en kollega? Det är nog ett hack!
Därför handlar shame.css om att skapa en fil med saker som du kunde ha gjort bättre och att du kan göra bättre när du har tid att besöka dem igen. Det är en självskrivande att göra-lista, verkligen - en fil med hack som du lägger åt sidan för att tänka på när du har mer tid.
.net: I din artikel nämner du att dokumentera hack, men finns det inget argument som utvecklare i allmänhet borde dokumentera CSS mer ändå, snarare än bara för hack?
HR: ja! Om det finns en sak som alla utvecklare borde göra mer, är det att skriva kommentarer. Du bör kommentera allt som inte är direkt uppenbart från koden ensam. Dokumentera din kod så att din kollega kan ta över nästa dag om du blir träffad av en buss på väg hem.
.net: När det gäller att integrera shame.css, vad föreslår du?
HR: Om du använder en förprocessor, @importera de skam. [scss | mindre | etc] fil rätt i slutet, helst. (Detta kan alltid leda till specificitet och källordersproblem, så din körsträcka kan variera.)
Om du inte använder en förprocessor, men har en anständig byggprocess, bör all din CSS sammanfogas och minifieras före distributionen, så igen, shame.css kan bulta till slutet av det.
Om du inte använder en förprocessor och du har ingen byggprocess, sedan en, du borde nog fixa det, och två, en hack-sektion i slutet av ditt formatmall är förmodligen din bästa insats. Shame.css är inte avsedd för allmän visning, så ha aldrig ett separat formatblad som anropas av ett länkelement i din markering. Du bör endast visa ett sammanfogat och förminskat formatmall.
.net: Om shame.css som koncept verkligen tar fart, hur tror du att det kan förändra designprocessen och webbplatser i allmänhet?
HR: Shame.css är bara lika användbart som utvecklarna som implementerar det. Det är bra och bra att isolera och dokumentera hack, men om du aldrig fixar eller återbesöker dem är du bara i samma båt som tidigare.
För mig signalerar shame.css en bredare förändring av utvecklingen; det behöver inte begränsas till CSS. Konceptet är bara ”att förverkliga, dokumentera och göra en poäng för dina hackar”. Du kan tillämpa det tänkandet på allt.
Det verkliga arbetet med skam.css är att få ditt närmaste team (utvecklare) ombord och sedan göra företaget / PM / scrummasters / BA / produktägare (och så vidare) medvetna om att en produkt ibland kommer att innehålla mindre än den ideala koden, men att den här koden finns för att uppfylla företagets krav.
Berätta för dem att du isolerar och dokumenterar hack och få lite utvecklingstid för att städa upp saker. Det är lättare att göra ett affärsfall för att städa upp en kodbas om du kan kvantifiera den. Att bara säga till din projektledare, "Jag har några saker att städa innan jag kan gå vidare till Feature X" kommer inte alltid att klippa det! Ta en lista med saker till din premiärminister och försök få en halv dags sprinttid att spendera på att städa upp.
Tanken bakom shame.css är helt enkelt att göra dina hack mer transparenta, kvantifierbara och isolerade. Det är upp till dig vad du gör med den informationen!
