Los desarrolladores deberían usar un concepto llamado shame.css para aislar cualquier CSS de corrección rápida "hack" en los proyectos, según Harry Roberts, desarrollador senior de UI en BSkyB.
Roberts explicó en una publicación de blog que esto podría evitar que los desarrolladores vean hacks salpicados en CSS y, por lo tanto, pensarían que tales cosas son aceptables de forma predeterminada.
Además, el artículo señaló que dicho enfoque, si se documenta adecuadamente y se acompaña de los medios para iterar, podría permitir una progresión más rápida hacia CSS más limpio en proyectos donde se usaron hacks (por cualquier motivo).
.net habló con Roberts (HB) sobre la piratería CSS y las posibles ventajas que shame.css podría traer si se usa correctamente.
.net: ¿Crees que hay una tendencia de algunas personas en la industria a ser poco realistas sobre la necesidad de (con suerte) hacks a corto plazo para que un sitio funcione?
HORA: Gran momento. Si trabaja en un sitio o producto que gana millones de libras por año, cualquier error, rotura o peculiaridad debe solucionarse lo antes posible. A su propietario de producto no le importa si su CSS es perfecto; le importa que el sitio esté activo y funcional y que supere esos ingresos. Buen codigo es importante, y los hacks están lejos de ser ideales, pero pensar que siempre se pueden prevenir los hacks y las soluciones rápidas / a corto plazo es ingenuo.
.net: ¿Entonces diría que son solo un mal necesario dentro de los negocios?
HORA: Cuando un cliente está respirando en su cuello, o una función se rompe en un sitio en vivo, debe asegurarse de mantener contentos a las partes interesadas adecuadas. Si pasas una hora escribiendo la solución perfecta para algo que podrías haber arreglado superficialmente en dos minutos, diría que estás manteniendo feliz a la persona equivocada, ¡es decir, a ti mismo!
En mi propio trabajo, he descubierto que la "necesidad" de hacks aumenta de manera bastante proporcional con el tamaño del proyecto, pero lo bueno de eso es que es probable que más adelante tengas más tiempo de proyecto dedicado a corregir esos hacks.
.net: Aquí es donde entra shame.css. Con ese concepto, ¿qué consideras específicamente un truco de CSS?
HORA: Algo que podría haberse hecho mejor con más tiempo. Es difícil pensar en ejemplos fuera de contexto, pero creo que a menudo sabrás cuando algo es un truco. ¿Escribió algo que le daría vergüenza explicarle a un colega? ¡Probablemente sea un truco!
Por lo tanto, shame.css se trata de crear un archivo de cosas que podría haber hecho mejor y que puede hacer mejor cuando tenga tiempo de volver a visitarlas. En realidad, es una lista de tareas de autoescritura: un archivo de trucos que dejas a un lado para pensar en ellos cuando tengas más tiempo.
.net: En tu artículo, mencionas documentar hacks, pero ¿no hay un argumento que los desarrolladores deberían documentar más CSS de todos modos, en lugar de solo para hacks?
HORA: ¡Sí! Si hay algo que todos los desarrolladores deberían hacer más, es escribir comentarios. Debe comentar cualquier cosa que no sea obvia de inmediato a partir del código solo. Documente su código para que, si lo atropella un autobús en su camino a casa, su colega pueda hacerse cargo al día siguiente.
.net: En cuanto a la integración de shame.css, ¿qué sugieres?
HORA: Si usa un preprocesador, @importar la vergüenza. [scss | menos | etc] archivo justo al final, idealmente. (Esto siempre puede dar lugar a problemas de especificidad y orden de origen, por lo que su kilometraje puede variar).
Si no está utilizando un preprocesador, pero tiene un proceso de compilación decente, todo su CSS debe concatenarse y minimizarse antes de la implementación, por lo que, nuevamente, shame.css puede agregarse al final de eso.
Si no está utilizando un preprocesador y no tiene un proceso de compilación, entonces uno, probablemente debería arreglarlo, y dos, una sección de trucos al final de su hoja de estilo es probablemente su mejor opción. Shame.css no está diseñado para ser visto por el público, así que nunca tenga una hoja de estilo separada llamada por un elemento de enlace en su marcado. Solo debe servir una hoja de estilo concatenada y minimizada.
.net: Si shame.css como concepto realmente despega, ¿cómo crees que podría cambiar el proceso de diseño y los sitios web en general?
HORA: Shame.css es tan útil como los desarrolladores que lo implementan. Está muy bien aislar y documentar los trucos, pero si nunca los arreglas o los revisas, estás en el mismo barco que antes.
Para mí, shame.css indica un cambio más amplio en el desarrollo; no necesita limitarse a CSS. El concepto es simplemente "darse cuenta, documentar y hacer hincapié en sus trucos". Puedes aplicar ese pensamiento a todo.
El trabajo real involucrado con shame.css es hacer que su equipo inmediato (desarrolladores) se incorpore y luego hacer que los negocios / PM / scrum masters / BA / propietarios de productos (y así sucesivamente) sean conscientes del hecho de que un producto a veces incluirá menos -que no es el código ideal, pero que este código existe para cumplir con los requisitos comerciales.
Dígales que está aislando y documentando hacks y asigne algo de tiempo de desarrollo para ordenar las cosas. Es más fácil hacer un caso comercial para ordenar una base de código si puede cuantificarlo. Simplemente decirle a su gerente de proyecto, "Tengo algunas cosas que arreglar antes de poder pasar a la Característica X", ¡no siempre será suficiente! Lleve una lista de cosas a su PM y trate de tener medio día de tiempo de sprint para dedicarlo a limpiar.
La idea detrás de shame.css es simplemente hacer que sus hacks sean más transparentes, cuantificables y aislados. ¡Depende de usted lo que haga con esa información!
