También disponible en English.
El problema
Cada equipo hereda una hoja de estilos así, tarde o temprano.
No está mal escrita. Nadie en el equipo original fue descuidado. Los selectores son razonables. El nombramiento es lo suficientemente consistente. Y aun así, nadie la toca sin miedo, porque nadie está seguro de cuáles de sus cuatro mil líneas son estructurales.
Así que el instinto es siempre el mismo. Añadir una regla nueva. No eliminar la vieja — por si acaso. Un componente nuevo recibe su propio selector en lugar de reutilizar algo en lo que, de alguna manera, se podría estar confiando en otro lugar de formas que nadie documentó. El archivo crece. Nunca se reduce. No porque alguien decidiera que solo debería crecer — sino porque crecer se sentía seguro y reducirse nunca lo fue.
Por qué existe el problema
Eliminar una regla requiere confianza. Añadir una no requiere ninguna.
Esa asimetría es todo el mecanismo. El CSS es aditivo y permisivo por naturaleza — escribes una regla nueva y simplemente funciona, superpuesta a todo lo que vino antes, sin romper nada más en el proceso. Esa es una fortaleza genuina. También es exactamente por lo que nadie se siente seguro restando. Borrar una regla significa demostrar que nada depende de ella, en cada página, cada componente, cada ancho de navegador, cada estado — y el CSS no ofrece una forma fácil de demostrar eso.
Así que se escriben selectores defensivos no porque se necesiten hoy, sino porque un desarrollador no está seguro de qué se rompe si simplemente confía en lo que ya está ahí. Las reglas muertas sobreviven indefinidamente, porque nada en el sistema le dice a nadie que están muertas.
El intercambio tiene la misma forma que los dos últimos problemas de esta serie, con una cara diferente: la misma cualidad que hace al CSS accesible —siempre puedes simplemente añadir más— es la cualidad que hace que las hojas de estilos grandes sean ingobernables con el tiempo.
El primer principio
Nómbralo claramente: el CSS no tiene un bucle de retroalimentación para la irrelevancia.
Un lenguaje compilado marca una variable no utilizada. Una importación no utilizada recibe una advertencia, a veces un error. Las herramientas le dicen al autor, directamente: "esto no está haciendo nada — elimínalo". El CSS no tiene nada equivalente integrado en el propio lenguaje. Una regla que deja de importar no se anuncia. Simplemente se queda ahí, permanentemente ambigua — tal vez estructural, tal vez vestigial, indistinguible desde fuera, para siempre.
Los equipos no crean este tipo de entropía por descuido. La crean porque el sistema nunca les dice cuándo es realmente seguro eliminar algo. Con suficiente tiempo y suficientes colaboradores, ese silencio se acumula. No por la negligencia de nadie — sino por la simple y repetida ausencia de una señal que nunca existió.
Demostración del principio
Un solo ejemplo silencioso lleva esto más lejos que un catálogo.
En algún lugar de una hoja de estilos real: una regla apuntando a .legacy-card-footer. La plantilla que usaba esa clase fue reconstruida hace ocho meses. Nadie eliminó la regla, porque nadie pudo demostrar, rápidamente, que nada más la referenciaba. Así que se sigue enviando. A cada visitante. En cada carga de página. Sin hacer nada, indefinidamente, porque borrarla se sentía más arriesgado que dejarla - y la propia hoja de estilos no ofrecía forma de notar la diferencia.
quell como estudio de caso
Los límites de capa explícitos no hacen que el código muerto sea imposible. Lo hacen localizable. Una regla obsoleta dentro de componentes es un problema mucho más pequeño y fácil de buscar que una regla obsoleta enterrada en algún lugar de un archivo global indiferenciado, sin límites que digan siquiera por dónde empezar a buscar.
La lección general
La entropía no es un fallo de disciplina. Ni en el CSS, ni en ningún otro lugar.
Es lo que sucede, de forma fiable, siempre que un sistema recompensa la suma y no ofrece nada a cambio de la resta. El arreglo nunca fue "esforzarse más por eliminar cosas" - ese es el mismo instinto de disciplina-como-solución que esta serie ya ha dejado de lado dos veces. El arreglo es construir un sistema donde eliminar sea exactamente tan seguro, y exactamente tan visible, como siempre lo fue añadir.
Ese es el hilo que recorre los tres artículos hasta ahora. No es una serie de quejas de CSS no relacionadas - es una forma recurrente, que se presenta de manera distinta cada vez: un sistema sin arquitectura eventualmente pedirá a la disciplina que haga un trabajo para el que la disciplina nunca fue construida.
Top comments (0)