Hace un par de días vi un post de queja en un grupo técnico. La persona que lo publicó decía que antes de lanzar el proyecto usó una herramienta para comprimir el CSS, y al día siguiente, cuando un colega abrió el archivo de estilos, vio una pantalla llena de caracteres amontonados y explotó: “¿Quién escribió esto? ¿Esto es legible para un humano?”. El que publicó dijo, con tono de víctima, que la compresión era parte del proceso de build y que no podía hacer nada.
Este caso es bastante típico, casi todos los equipos de frontend han discutido por esto. Hoy vamos a analizar: después de comprimir el CSS, los colegas no lo entienden, ¿a quién le toca cargar con la culpa?
Primero, hablemos de para qué sirve comprimir el CSS. En pocas palabras, elimina espacios, saltos de línea y comentarios del código, acorta los nombres de variables tanto como sea posible, con el objetivo de reducir el tamaño del archivo y hacer que la página cargue más rápido. Esto no tiene nada de malo; en el entorno de producción se busca rendimiento, y la compresión es una operación estándar. Pero el problema está en que mucha gente sube directamente los archivos comprimidos al repositorio de código, incluso sobrescribiendo los archivos originales. Cuando un colega hace pull del código, ve cosas como “a{b:c;d:e}”, que parecen escritura en clave. ¿Cómo no va a estar confundido?
Entonces, ¿a quién le echamos la culpa? Algunos dicen que es culpa de la herramienta de compresión, por ser demasiado “agresiva”. Pero la herramienta es inocente; es solo un programa que ejecuta comandos. Si le pides que comprima, ¿no va a comprimir al máximo? Si te cortas la mano con un cuchillo de cocina, no puedes culpar al cuchillo por ser demasiado afilado.
Otros dicen que es culpa del colega, que si un ingeniero de frontend no entiende código comprimido, es que no tiene los fundamentos básicos. Esto es fácil decirlo desde la barrera. El código comprimido está hecho para que lo lea el navegador, no para humanos. Es como si tradujeras una novela a código Morse y se la enviaras a un amigo; si no la entiende, ¿puedes culparlo por no haber estudiado bien el idioma? El hábito de lectura normal de una persona es ver código con sangrías, comentarios y saltos de línea; el código comprimido es completamente antihumano. Exigir que los colegas se esfuercen en leer código comprimido no es entrenar habilidades, es torturarlos.
Creo que la verdadera culpa recae en los procesos y las normas. En resumen, el equipo no ha acordado “qué se debe subir y qué no”. La práctica correcta es que el código fuente (el CSS escrito para humanos) esté en el repositorio, y la compresión sea algo que se hace automáticamente en la fase de build. Los archivos comprimidos deben salir al directorio dist o empaquetarse directamente en el producto final, sin necesidad de subirlos al control de versiones. Pero muchos equipos, por comodidad o porque no lo pensaron bien al principio, suben también los archivos comprimidos, y ahí es donde surge el problema.
Alguien podría decir: ¿y si la empresa exige subir los archivos comprimidos? Por ejemplo, en algunas plataformas de hosting estático, o si el backend referencia directamente los archivos del repositorio. Esta situación existe, pero no es irresoluble. Puedes hacer de la compresión un paso separado del build, que se ejecute antes del lanzamiento, en lugar de comprimir y subir directamente después de modificar el código. O usar herramientas como hooks de pre-commit para procesar automáticamente antes de subir, garantizando que siempre haya una versión sin comprimir en el repositorio para que la gente la lea. Siempre hay más soluciones que problemas; lo clave es que alguien en el equipo lidere y establezca esta norma.
Otro punto que a menudo se pasa por alto son los comentarios en el código. Muchas herramientas de compresión de CSS eliminan los comentarios por defecto, lo que hace que, incluso si quieres dejar alguna pista en el archivo comprimido, no puedas. Por lo tanto, la lógica importante que necesite entender quien venga después debe escribirse en el archivo fuente, y no esperes verla después de comprimir. Esta es otra razón por la que es tan importante conservar el archivo fuente: es el “verdadero cuerpo” de la colaboración en equipo.
En resumen, comprimir el CSS no es malo en sí; lo malo es no tener hábitos de gestión complementarios. Que un colega no lo entienda no es porque sea malo, ni porque la herramienta sea tonta, sino porque falta un eslabón en el flujo de trabajo. Es como cocinar: el cuchillo es bueno, pero si insistes en cortar la verdura en puré y servirla en la mesa, y los invitados dicen que no se ve bien, ¿puedes culpar al cuchillo?
Así que, deja de pelear por esto. La próxima vez que pase, reconoce abiertamente que el proceso no estaba bien definido y ponte a arreglar la norma: el archivo fuente va al repositorio, la compresión la hace el build, y nadie debe subir el producto comprimido directamente. Si hubieras hecho esto desde el principio, ¿no habría nada de qué culparse? En el fondo, detrás de los problemas técnicos suele haber problemas de gestión. ¿No crees?