Els desenvolupadors haurien d’utilitzar un concepte anomenat shame.css per tancar qualsevol CSS de “solució ràpida” en projectes, segons Harry Roberts, desenvolupador principal d’interfície d’usuari de BSkyB.
Roberts va explicar en una publicació al bloc que això podria evitar que els desenvolupadors vegessin pirates a tot CSS i, per tant, pensessin que aquestes coses són acceptables per defecte.
A més, l'article assenyala que aquest enfocament, si es documenta adequadament i s'acompanya dels mitjans per iterar-lo, podria permetre una progressió més ràpida cap a un CSS més net en els projectes on s'utilitzaven pirates informàtics (per qualsevol motiu).
.net va parlar amb Roberts (HB) sobre la pirateria CSS i els avantatges potencials que shame.css podria aportar si s’utilitza correctament.
.net: Creieu que hi ha una tendència d'algunes persones de la indústria a ser poc realista sobre la necessitat (amb sort) de pirates informàtics a curt termini perquè un lloc funcioni?
RRHH: Gran estona. Si treballeu en un lloc o producte que guanya milions de lliures a l’any, cal corregir qualsevol error, trencament o peculiaritat el més aviat possible. Al propietari del producte no li importa si el vostre CSS és perfecte: els importa que el lloc estigui funcionant i funcional i que superi els ingressos. Bon codi és és important, i els pirates informàtics estan lluny de ser ideals, però pensar que sempre es pot prevenir pirates informàtics i solucions ràpides a curt termini és una nau.
.net: Llavors diríeu que només són un mal necessari dins dels negocis?
RRHH: Quan un client us respira pel coll (o es trenca una funció en un lloc en directe), heu d'assegurar-vos de mantenir feliços els interessats adequats. Si dediqueu una hora a escriure la solució perfecta per a alguna cosa que podríeu haver solucionat superficialment en dos minuts, diria que manteniu feliç a la persona equivocada, és a dir, a vosaltres mateixos.
En el meu propi treball, he trobat que la "necessitat" de pirates informàtics augmenta bastant proporcionalment a la mida del projecte, però el bo és que, més endavant, també tindreu més temps dedicat a solucionar aquests pirates informàtics.
.net: Què és on entra shame.css. Amb aquest concepte, què considereu específicament un pirateig CSS?
RRHH: Una cosa que s’hauria pogut fer millor donant més temps. És difícil pensar en exemples fora de context, però crec que sovint sabreu quan hi ha alguna cosa com un pirateig. Heu escrit alguna cosa que us faria vergonya explicar a un company? Probablement això és un truc.
Per tant, shame.css consisteix a crear un fitxer de coses que podríeu haver fet millor i que podeu fer-ho millor quan tingueu temps de tornar-les a visitar. Realment, és una llista de tasques que s’escriuen a si mateixes: un fitxer de pirates informàtiques que heu de deixar de banda per pensar quan tingueu més temps.
.net: al vostre article, esmenteu la documentació de pirates informàtics, però no hi ha cap argument que els desenvolupadors generalment haurien de documentar CSS més de totes maneres, que no només per pirates informàtiques?
RRHH: Sí! Si hi ha alguna cosa que tots els desenvolupadors haurien de fer més, és escriure comentaris. Heu de comentar qualsevol cosa que no sigui evident de manera immediata només pel codi. Documenta el teu codi perquè, si et toca un autobús en tornar cap a casa, el teu company pugui agafar el control l’endemà.
.net: pel que fa a la integració de shame.css, què suggeriu?
RRHH: Si utilitzeu un preprocessador, @import el vergonya. [scss | menys | etc] arxiu al final, idealment. (Això sempre pot provocar problemes d'especificitat i d'ordre de font, de manera que el vostre quilometratge pot variar.)
Si no utilitzeu un preprocessador, però teniu un procés de compilació decent, tots els vostres CSS haurien de ser concatenats i reduïts abans del desplegament, de manera que, de nou, shame.css es pot fixar fins al final.
Si no utilitzeu un preprocessador i no teniu cap procés de compilació, després un, probablement hauríeu de solucionar-ho i, dos, una secció de pirateries al final del full d'estil és probablement la vostra millor aposta. Shame.css no està pensat per a la visualització pública, de manera que mai no tingueu un full d'estil separat anomenat per un element d'enllaç al vostre marcatge. Heu de publicar només un full d'estil concatenat i reduït.
.net: Si shame.css com a concepte realment s’enlaira, com creieu que podria canviar el procés de disseny i els llocs web en general?
RRHH: Shame.css només és tan útil com els desenvolupadors que l’implementen. Tot està bé aïllant i documentant els hacks, però si mai no els arregleu ni els torneu a visitar, esteu al mateix vaixell que abans.
Per a mi, shame.css assenyala un canvi més ampli en el desenvolupament; no cal que estigui limitat a CSS. El concepte és simplement "adonar-se, documentar i assenyalar els seus hacks". Podeu aplicar aquest pensament a tot.
El veritable treball que suposa shame.css consisteix a incorporar el vostre equip immediat (desenvolupadors) i, a continuació, conscienciar els empresaris / PMs / scrum masters / BAs / propietaris de productes (etc.) del fet que de vegades un producte inclourà menys -Codi ideal, però que existeix per satisfer els requisits empresarials.
Digueu-los que esteu aïllant i documentant els pirates informàtics i que assigneu una mica de temps de desenvolupament per endreçar les coses. Si podeu quantificar-lo, és més fàcil plantejar un cas empresarial per ordenar una base de codi. Simplement dir al vostre gestor de projectes: "Tinc algunes coses a endreçar abans de poder passar a la funció X" no sempre es reduirà. Porta una llista de coses al teu primer ministre i intenta obtenir mig dia de sprint per passar la neteja.
La idea darrere de shame.css és simplement fer que els vostres hacks siguin més transparents, quantificables i aïllats. Depèn de vosaltres què feu amb aquesta informació.
