Also available in Inglés
El problema
Abre una base de código lo suficientemente antigua como para que nadie en el equipo actual la haya escrito. El código sigue ejecutándose. Nadie puede decirte por qué se tomó cada decisión.
¿Fue intencional esa solución temporal de especificidad o un accidente parcheado? ¿Fue deliberada la elección del reset o simplemente lo que incluía la plantilla inicial? El código no lo dice. Nunca lo hizo. Lo que falta no es funcionalidad. Es la capacidad de reconstruir el motivo.
Por qué existe el problema
Los equipos optimizan para lo que funciona hoy. Esa es la presión que tienen justo enfrente. Un horizonte de diez años no es el plazo de entrega de ningún sprint. Las decisiones se toman de forma correcta, bajo restricciones reales, por personas que entendían exactamente por qué las tomaban y luego el razonamiento se evapora en el momento en que esas personas se marchan, incluso cuando la decisión en sí era completamente sólida.
El código sobrevive. El contexto no. Ese vacío es lo que esta serie ha estado rodeando, artículo tras artículo, bajo un nombre diferente cada vez.
El primer principio
La longevidad no es una propiedad tecnológica. Es una propiedad de legibilidad.
Un sistema sigue teniendo sentido en diez años si un extraño alguien que nunca conoció a quien lo construyó puede reconstruir por qué está diseñado así, a partir del propio artefacto, sin acceso a las personas que tomaron las decisiones originales. Cada mecanismo que ha cubierto esta serie resulta ser el mismo requisito, aplicado a una escala diferente: declarado en lugar de implícito, y verificable por cualquiera que lo lea en lugar de estar memorizado por quienquiera que estuviera en la sala cuando se decidió.
Demostración del principio
/* límite: la base nunca establece valores de color directamente; los tokens son los dueños de eso. */
:where(h1, h2, h3) { margin-block: 0; }
Frente a la misma regla, sin comentario, por lo demás idéntica. Mismo comportamiento hoy. Dentro de diez años, una de ellas todavía le explica a un extraño por qué está construida así. La otra solo le dice lo que hace.
quell-base.css y quell-light.js como caso de estudio
Nada de esto es material nuevo. Es la misma evidencia que esta serie ya ha mostrado, leída ahora como una decisión continua en lugar de once decisiones separadas.
El reset que declaró una opinión visual cero, para que nadie tenga que preguntar más tarde si "reset" significaba en secreto "el gusto de alguien". Las capas que resolvieron previamente las disputas antes de que tuvieran la oportunidad de ocurrir, para que un extraño que lea @layer ghost_tokens, reset, baseline, forms, utilities; ya conozca la precedencia sin preguntar a nadie. Las superficies de sobrescritura (override surfaces) que reemplazaron la negociación por tres rutas explícitas y ordenadas, declaradas una vez, válidas para cualquiera que toque el archivo después. El vocabulario de estado en quell-light.js que no puede desviarse para significar otra cosa, porque nunca fue elegible para significar otra cosa.
Nada de esto requirió que el autor original siguiera allí para continuar el trabajo. Ese era el objetivo de cada una de esas decisiones, no un accidente de buena suerte.
La lección más amplia
Doce artículos, una sola cosa debajo de todos ellos: reemplazar el acuerdo implícito y no documentado con algo declarado, verificable y duradero más allá de las personas que lo construyeron. Resets, especificidad, entropía, límites (boundaries), capas, orden de resolución, exclusiones, especificidad cero, frameworks, librerías, estado: mecanismos diferentes, el mismo requisito, una y otra vez.
El objetivo nunca fue construir otro framework. Fue ayudar a los desarrolladores a redescubrir la plataforma que ya tienen, y dejar atrás decisiones que un extraño aún pueda comprender, mucho tiempo después de que todos los que las tomaron hayan pasado a otra cosa.
Top comments (0)