Cómo evitar que nuestro CSS sea un Frankenstein: trucos y buenas prácticas.

Mucho se habla del código legacy, pero en esas charlas nunca (o casi nunca) se tiene en cuenta el legacy en CSS que, al igual que los vampiros, “existe”.

Cualquiera que haya trabajado en un proyecto de largo recorrido en años, ya sea desde sus inicios o aterrizando en algún punto de su etapa de desarrollo, va a sentir un escalofrío pensando en ese CSS por el que han pasado tantas manos. No quiero ser demasiado hater, pero (por experiencia) puedo decir que normalmente muy pocas manos tratan bien al CSS y tienen en cuenta que será heredado por alguien que vendrá detrás. Y como esto lo he sufrido en mis carnes muchas veces, quiero hablar sobre cómo creo que se puede prevenir y hacernos la vida mucho más sencilla a todes.

Como todo en la vida, en el desarrollo de software está la teoría y luego la práctica. Muchas veces hacemos las cosas mal por desconocimiento, por falta de tiempo o por dejadez. Contra el desconocimiento y la falta de tiempo, puedo ayudaros con este post y, con un poco de suerte, también con la dejadez al ponéroslo fácil para implementar algunos truquis sencillos.

La teoría

En un mundo ideal, cuando comenzamos a desarrollar un producto contamos con un sistema de diseño que nos permite sentarnos a pensar una buena arquitectura de todo nuestro front y, por supuesto, también de nuestro CSS.

Pero los mundos ideales raramente suelen existir y tenemos que tirar de donde podemos. Nuestro siguiente recurso es apelar a las buenas prácticas de CSS, pero ¿Qué son las buenas prácticas? Dices mientras clavas tu pupila #0000FF en… Las buenas prácticas se supone que son reglas no escritas que, por convención, todos cumplimos basándonos en nuestra interpretación de las mismas. Y ya está. No están escritas en piedra ni certificadas ante notario.

Las buenas prácticas son un poco como la elegancia del código: un concepto abstracto que utilizamos para hacernos los interesantes, pero que en muchas ocasiones es un ser mitológico que desafía a todas las leyes de la ciencia conocida.

¡Ojo! Quiero hacer una diferenciación entre los estándares establecidos en función del conocimiento de CSS y la aplicación de los principios SOLID en el desarrollo de software con las buenas prácticas que inundan miles de posts en internet.

Como la mejor manera de hacerme entender es con un ejemplo, aquí va uno sobre un estándar establecido:

• No hay que dar estilos a las etiquetas html: esto puede generar mucha controversia, pero hay que pensar en que estamos hablando de un proyecto grande y con mucho recorrido en el tiempo. No puedes basar tus estilos en un selector con tan poca especificidad, agnóstico y que va a repetirse casi de manera infinita en tu proyecto. “Pero es que si tengo hojas de estilo que solo aplican a cada vista/componente…” Estupendo, pero NO. Hoy tienes tu componente X y ese componente comparte estilos mañana con el Z y con el W, así que sacas esos estilos y los enchufas en una hoja general para así no tener que repetir código y ¡BAM! Ya la has liado.
• Supongo que darle estilos a una etiqueta en su día era lógico porque teníamos webs (que no aplicaciones) muy sencillas y manejables, no teníamos tantos estilos ni tantas tags y la complejidad de las maquetaciones era muy baja. Aquí tenéis un post en el que os explican mucho más en detalle por qué no se debe hacer y por qué es un estándar bastante estandarizado (valga la redundancia).
• Intenta dar estilos a clases y no a ids: quizá ya tengas un id en esa etiqueta form porque por definición lo necesitas pero, por favor y por la Santa Especificidad de CSS, añádele una clase para poder estilarlo. No solo por la especificidad, además una etiqueta form va a ser ampliamente repetida y probablemente vaya a tener los mismos estilos, reutiliza esa clase.

Y aquí va uno sobre una “buena práctica mitológica”:

• Hay que ordenar las propiedades CSS alfabéticamente/función a la hora de estilar: ¿Y por qué no en orden alfabético inverso? ¿Y por qué no primero el box-model, color, fuente…?
  Sufrí un tiempo en un proyecto en el que no me aprobaban las PRs si las propiedades no estaban ordenadas alfabéticamente y quizá a esta mandanga le tenga algo más de tirria que a otras, pero lo siento, esto no es un estándar basado en cómo funciona CSS o como aplicamos X principio de programación, es un estándar basado en gustos personales de cada uno.

Si os soy sincera creo que hay muy pocas buenas prácticas como tal y todas van a apelar al correcto conocimiento de la cascada de CSS y a cuestiones de accesibilidad (como que no se quitan jamás de los jamases los estilos globales de los :focus). Todo, absolutamente todo lo demás que me he encontrado en la vida han sido, precisamente, preferencias personales.

La práctica

Está feo que hable de preferencias personales cuando este post puede interpretarse como una defensa de las mías, así que voy a intentar argumentar bien a qué me refiero, porque es muy probable que tengamos costumbres muy asentadas a la hora de hacer CSS que ni siquiera respondan a nuestros gustos, sino a que simplemente nos enseñaron a hacerlo así, o siempre lo hemos visto de esa manera y no se nos ha ocurrido que pudiera ser de otra.

En mi opinión, la única manera sana de generar unas “buenas prácticas” que se mantengan y sean escalables es que estas sean “de equipo”. He trabajado en equipos en el que dentro de un marco Scrum había una política explícita sobre cómo escribir los commits y qué código se seguía a la hora de nombrar ramas… Si eso nos parece importante, creo que el CSS también lo es.

Por eso, para mí los dos puntos fundamentales para generar unas “buenas prácticas de equipo” son:

• Que se llegue a ellas por consenso.
• Que se documenten.

Con el primer punto, nadie impone a nadie su parecer aka su manía (o eso espero), y con el segundo hacemos que quienes vengan después que nosotros tengan una source of truth en la que basarse y de la que aprender.

A veces, tengo la sensación de que hablar de esto para un no lenguaje de programación tan fácil (ironía off) es darle demasiadas vueltas a algo que no lo merece. Luego pienso en todas las veces en las que he tenido que ir probando en varias declaraciones de clases a ver cuál era la que verdaderamente aplicaba por no cascar un !important… y se me pasa.

Ese refactor del que usted me habla

¿Cuántas veces habéis tenido un refactor de CSS como tarea de deuda técnica? Es mi reto personal, tener al menos uno en cada proyecto que toco.

Hilando con lo que comentaba en el anterior apartado, dejar algo que “meh, lo podría hacer mejor, ya lo refactorizaré cuando tenga un huequito” en tu JS te da un poco de vergüenza y, probablemente, lo refactorices más pronto que tarde. Pero el “pongo esto aquí y ya volveré a por ello para abstraerlo en un mixin cuando esto crezca” es un clásico. Al final crearás el mixin, lo utilizarás en otros sitios, pero ese primer punto del que ni siquiera harás copy-paste, se quedará tal cual hasta el fin de los días.

No es que lo hagas tú, es que lo hacemos todos. Casi dos años y medio en un proyecto histórico me han hecho ser esa persona que deja cosas para después y 7 meses más tarde se da cuenta de que no lo hizo, le toca hacer ingeniería inversa, memoria y ponerlo todo correctamente. Y no pasa nada, todos somos humanos.

Personalmente, suelo buscarme huecos cuando ya estamos para entregar una funcionalidad, especialmente si ha sido largo su desarrollo. Reviso que no esté duplicando estilos que están aplicados en otros lugares y que se pueden reutilizar, que no me he dejado pruebas comentadas, apaños temporales que siempre se quedan al final de alguna hoja…

Hay algunas herramientas y librerías que permiten hacer este mantenimiento de una manera más sencilla. Soy muy old school y no las he probado, pero os listo algunas por si queréis probar: Project Wallace, PurifyCSS, unCSS y por supuesto el validador de CSS de la W3C.

Otro truco, en proyectos en los que tenemos componentes (en Vue.js ha sido mi experiencia) y que están desarrollando distintas personas a la vez, es hacer una revisión de los estilos que se han dado a esos componentes para ver cuáles están repetidos y sacarlos a una hoja de estilos común en los estilos generales. Creo que este es uno de los errores más comunes que se producen en este tipo de apps y, por eso, si llega el día en el que tienes que eliminar todos los border-radius de la aplicación te das cuenta de tu error… por las malas.

Por eso hay que poner en valor que, de vez en cuando (cada 5 sprints, una vez por Q, cuando vamos a sacar la feature esa que llevamos desarrollando 6 meses), alguien se líe la manta a la cabeza y refactorice el CSS que llevamos hecho. Especialmente, si somos muchos desarrollando en paralelo.

Sé que es difícil defender este tipo de tareas, la deuda técnica en general (y de CSS en particular), porque en cuestiones de rendimiento es probable que no afecte especialmente. Pero la mantenibilidad y escalabilidad son dos principios fundamentales a la hora de asegurar la calidad de los productos que desarrollamos.

CSS “elegante” 👔

Quizá muchos de los que me estéis leyendo tengáis un largo recorrido como maquetadores y sepáis ver lo malo en todos esos listados de buenas prácticas que cada uno escribe basándose en sus gustos. Pero si no es el caso, os dejo algunas cosas que he aprendido a lo largo de mi trayectoria profesional sobre los eternos debates relacionados con esas “buenas prácticas mitológicas”:

• Usar un .reset.css o un normalize es obligatorio: hasta hace muy poco era algo que ni me planteaba. Probablemente, el .reset.css de Meyerweb sea el trozo de CSS más repetido en todas las hojas de estilo del planeta. Ese reset ha evolucionado hacia otros más sencillos, actualizados e, importantísimo, accesibles; o a librerías como normalice, pero ¿realmente es necesario? Hablando con un compañero que no lo usa, me explicó sus motivos para no hacerlo y me parecieron igual de válidos y coherentes que los míos. ¿Lo vas a usar en tu proyecto? Ponte primero de acuerdo con tu equipo y no sentencies a la primera de cambio.
• No a las utility clases: los maquetadores pre-bootstrap tenemos algo de odio argumentado a llenar el HTML de clases para generar estilos. Este no es el lugar para debatir sobre lo correcto o incorrecto de esto, o si Tailwind Css es el demonio o no. Lo que sí sé, por experiencia, es que es algo complejo huir al 100 % porque, aunque sea, vas a utilizarlo para montar tu sistema de columnas o, al menos, para nuestra clase comodín para accesibilidad sr-only/visibility-hidden . De nuevo, lo mejor es establecer un consenso entre todos y dejar claras y documentadas las “reglas” para generar nuevas clases. Porque más de una y dos veces me he encontrado dos clases que hacían exactamente lo mismo 🤦‍♀️.
• La estructura de archivos tiene que ser la recogida en [inserte aquí blog de moda]: pues depende. En este caso sí que es cierto que estamos muy acostumbrados (por influencia de librerías/frameworks CSS) a tener una estructura de carpetas y archivos “estándar”. Yo misma tengo un repo con el que empiezo todo proyecto, pero eso jamás estará escrito en piedra. Me repito: tiene que ser un consenso de equipo y, en el caso de que seas tú solo el que empieza el proyecto, ¡documenta!
• El CSS no necesita ser revisado en PRs: porque no es un lenguaje de programación… Esto no es discutible, se trata de un lenguaje tan complejo y especializado que debe ser revisado en las PRs. Si bien es cierto que en programación nunca hay una sola solución a un problema, estas revisiones nos pueden ayudar a no salirnos por la tangente de las “políticas de calidad” que hayamos establecido para nuestro CSS. Sé que me estoy repitiendo, pero tirar estilos es lo primero que se hace rápido y mal porque es “fácil” y esa creencia inconsciente es el primer miembro de nuestro monstruo Frankenstein.
• Las propiedades se escriben en una sola línea/propiedades en orden alfabético/ordenadas por lo que estilan: debatir y concretar como queremos escribir el código en nuestro proyecto es gratis y saludable. Una vez eliminados los debates vacíos sobre “tabs vs. espacios” gracias a las configuraciones de los IDEs (editorconfig gracias por tanto) podemos dar el paso de eliminar estas luchas también. Si bien es cierto que a mí lo de escribir cada declaración de CSS en una sola línea me da un poquito de ardor de estómago, si es la decisión conjunta, pues con ello. Existen plugins muy majos que pueden hacerte la vida más sencilla: te pueden ordenar las propiedades alfabéticamente, pueden ponerte el responsive al final de cada hoja, te escupen todo en una sola línea (que al final el minificado va a ir así y es más legible en varias líneas, pero para gustos…). Así que se puede hacer una configuración de equipo para que el código en el repo esté de la manera acordada, pero tú puedas trabajar como más cómodo te sientas.
• No se usan estilos/librerías de terceros: en mi opinión, siempre que puedas hacerlo tú, lo mejor es evitar dependencias de código que no es tuyo, porque la no continuidad de esas dependencias será una sombra que tendrás planeando sobre tu cabeza siempre. También porque es probable que no se adapte al 100 % a tus necesidades y tengas que hacer override de algunas cosas y, quizá, cuando actualices esa dependencia, hayan cambiado y tengas que volver a empezar. Decidir usarlo no es bueno per se, de la misma manera que no usarlo tampoco lo es, pero de nuevo (y es la última vez que lo digo) lo mejor es llegar a un acuerdo con tu equipo.

My two cents…

Seguro que os lo estáis viendo venir, pero lo mejor que puede hacerse para evitar que tu CSS sea un decorado de Halloween perenne es:

• Hablar con tu equipo. Sí, los diseñadores también son tu equipo.
• Piensa en el mañana y no solo en el ahora.
• Utiliza todas las herramientas disponibles a tu alcance para facilitar un trabajo conjunto orgánico y cómodo (linters, plugins, configuraciones de IDEs).
• Sírvete de las PRs para mantener unos estándares de calidad, ya que, de momento, las reglas de CSS para herramientas de CI como Sonar no aportan mucho más allá de un linter bien configurado.
• Refactoriza. Especialmente si un día dejas de dar soporte a un navegador del pleistoceno.
• Documenta. Grábate a fuego que el CSS es igual de importante y merece su propio espacio en la documentación.
• Y lo más importante de todo: haz el código que te gustaría encontrarte cuando aterrices en un proyecto rodado.

Soy consciente de que todos estos consejos dependen de una variable fundamental que es el tiempo y que muchas veces es escaso, por no decir que está en valores negativos. Es horrible, lo sé. En los casos en los que tengamos que tirar para delante sin mirar el reguero de cadáveres que estamos dejando atrás, os ruego que una vez las aguas se calmen, limpiéis el estropicio en la medida de lo posible. Así, cuando hagáis competiciones con otros fronts con archive.org de vuestros trabajos pasados, no tendréis un lugar destacado en el wall of shame.

Luchad por poner en valor este trabajo que cada vez se denuesta más y que muy pocas personas fuera de los niveles “profundos” del desarrollo conocen y entienden su importancia.

La mejor manera de luchar contra un CSS Frankenstein es darle al CSS la importancia que se merece.