Volgens Harry Roberts, senior UI-ontwikkelaar bij BSkyB, zouden ontwikkelaars een concept genaamd shame.css moeten gebruiken om elke quick-fix ’hack’ CSS in projecten te stoppen.
Roberts legde in een blogpost uit dat dit mogelijk zou voorkomen dat ontwikkelaars hacks door CSS zouden zien en daardoor denken dat dergelijke dingen standaard acceptabel zijn.
Bovendien merkte het artikel op dat een dergelijke aanpak, mits goed gedocumenteerd en vergezeld van de middelen om te itereren, een snellere voortgang naar schonere CSS mogelijk zou maken in projecten waar hacks werden gebruikt (om welke reden dan ook).
.net sprak met Roberts (HB) over het hacken van CSS en de mogelijke voordelen die shame.css zou kunnen opleveren bij correct gebruik.
.net: Denk je dat sommige mensen in de branche de neiging hebben om onrealistisch te zijn over de noodzaak van (hopelijk) korte-termijn-hacks om een site werkend te krijgen?
HR: Grote tijd. Als u aan een site of product werkt dat miljoenen euro's per jaar verdient, moeten eventuele bugs, breuken of eigenaardigheden zo snel mogelijk worden verholpen. Het maakt je producteigenaar niet uit of je CSS perfect is - ze geven er om dat de site up-to-date en functioneel is en die inkomsten tikt. Goede code is belangrijk, en hacks zijn verre van ideaal, maar te bedenken dat je hacks en snelle / korte-termijnoplossingen altijd kunt voorkomen, is een probleem.
.net: Dus je zou zeggen dat ze gewoon een noodzakelijk kwaad in het bedrijfsleven zijn?
HR: Wanneer een klant in je nek ademt - of een functie wordt verbroken op een live site - moet je ervoor zorgen dat je de juiste belanghebbenden tevreden houdt. Als je een uur besteedt aan het schrijven van de perfecte oplossing voor iets dat je oppervlakkig in twee minuten had kunnen repareren, zou ik zeggen dat je de verkeerde persoon tevreden houdt - dat wil zeggen jezelf!
In mijn eigen werk heb ik gemerkt dat de ‘behoefte 'aan hacks redelijk evenredig toeneemt met de grootte van het project, maar het goede daaraan is dat je later waarschijnlijk ook meer projecttijd zult hebben om die hacks te repareren.
.net: Dat is waar shame.css om de hoek komt kijken. Met dat concept, wat beschouw je specifiek als een CSS-hack?
HR: Iets dat beter had kunnen worden gedaan als we meer tijd hadden gekregen. Het is moeilijk om voorbeelden uit hun verband te bedenken, maar ik denk dat je het vaak zult weten wanneer iets een hack is. Iets geschreven waarvan je je zou schamen om het uit te leggen aan een collega? Dat is waarschijnlijk een hack!
Daarom gaat shame.css over het maken van een bestand met dingen die je beter had kunnen doen, en dat je beter kunt doen als je tijd hebt om ze opnieuw te bekijken. Het is eigenlijk een zelfgeschreven takenlijst - een bestand met hacks die je aan de kant legt om over na te denken als je meer tijd hebt.
.net: In je artikel noem je het documenteren van hacks, maar is er geen argument dat ontwikkelaars over het algemeen CSS toch meer zouden moeten documenteren, in plaats van alleen voor hacks?
HR: Ja! Als er iets is dat alle ontwikkelaars meer zouden moeten doen, is het commentaar schrijven. U moet commentaar geven op alles wat niet meteen duidelijk is uit de code alleen. Leg uw code vast zodat, als u op weg naar huis door een bus wordt aangereden, uw collega het de volgende dag kan overnemen.
.net: Wat stel je voor wat betreft het integreren van shame.css?
HR: Als u een preprocessor gebruikt, @importeren de jammer. [scss | minder | etc] bestand aan het einde, idealiter. (Dit kan altijd leiden tot specificiteit en problemen met de bestelling van de bron, dus uw aantal kilometers kan variëren.)
Als je geen preprocessor gebruikt, maar een fatsoenlijk bouwproces hebt, moet al je CSS worden samengevoegd en verkleind voordat ze worden geïmplementeerd, dus nogmaals, shame.css kan aan het einde daarvan doorgaan.
Als u geen preprocessor gebruikt en je hebt geen bouwproces, dan één, je zou dat waarschijnlijk moeten repareren, en twee, een hacks-sectie aan het einde van je stylesheet is waarschijnlijk de beste keuze. Shame.css is niet bedoeld voor openbare weergave, dus laat nooit een aparte stylesheet aanroepen door een link-element in je opmaak. U mag slechts één aaneengeschakeld en verkleind stylesheet serveren.
.net: Als shame.css als concept echt van de grond komt, hoe denk je dat het het ontwerpproces en websites in het algemeen zou kunnen veranderen?
HR: Shame.css is slechts zo nuttig als de ontwikkelaars die het implementeren. Het is allemaal goed en wel om hacks te isoleren en te documenteren, maar als je ze nooit repareert of opnieuw bezoekt, zit je gewoon in hetzelfde schuitje als voorheen.
Voor mij duidt shame.css op een bredere verschuiving in ontwikkeling; het hoeft niet beperkt te zijn tot CSS. Het concept is slechts ‘je hacks realiseren, documenteren en er een punt van maken '. Je kunt dat denken op alles toepassen.
Het echte werk van shame.css is om je directe team (ontwikkelaars) aan boord te krijgen en vervolgens het bedrijf / PM's / scrum-masters / BA's / producteigenaren (enzovoort) bewust te maken van het feit dat een product soms minder -than-ideal-code, maar dat deze code bestaat om aan zakelijke vereisten te voldoen.
Vertel hen dat je hacks isoleert en documenteert en krijg wat ontwikkeltijd om dingen op te ruimen. Het is gemakkelijker om een businesscase te maken voor het opruimen van een codebasis als u deze kunt kwantificeren. Gewoon tegen je projectmanager zeggen: "Ik moet een paar dingen opruimen voordat ik naar Feature X kan gaan", zal niet altijd voldoende zijn! Neem een lijst met dingen mee naar je PM en probeer een halve dag sprinttijd te besteden aan opruimen.
Het idee achter shame.css is simpelweg om je hacks transparanter, meetbaarder en geïsoleerder te maken. Het is aan jou wat je met die informatie doet!
