También disponible en Inglés
El problema
Un sistema de tokens de diseño comienza limpio. Colores, espaciado, escala tipográfica; todos valores, todos legítimos. Luego, alguien necesita una forma rápida de rastrear si un modal está abierto, y una propiedad personalizada está justo ahí, sintácticamente idéntica a cada token a su alrededor. Se usa. Nadie se detiene a preguntar si debería haberse usado.
Una hoja de estilo comienza siendo solo para presentación. Luego aparece un selector que solo se aplica si el usuario ha iniciado sesión; una decisión que CSS no tiene por qué tomar, codificada en CSS de todos modos, porque en ese momento era el camino de menor resistencia.
Ninguna de las dos opciones parece incorrecta cuando se toma. El patrón en ambas es el mismo: nada en el sistema tenía argumentos para decir no.
Por qué existe el problema
Las conversaciones sobre arquitectura casi siempre comienzan con la misma pregunta: qué debe hacer este sistema. Es una pregunta natural y generativa, pero no tiene un punto de parada natural. Cada capacidad que alguien pueda imaginar es candidata para ser incluida, y rara vez hay un momento obvio para decir no, categóricamente, independientemente de lo conveniente que sea esto en este momento.
El resultado son sistemas que acumulan permisos por defecto. La restricción solo aparece de manera reactiva, después de que algo ya ha salido mal y alguien tiene que escribir la autopsia explicando cómo un booleano terminó viviendo dentro de un token de diseño.
El primer principio
Un sistema sin exclusiones declaradas eventualmente será requerido para hacerlo todo, porque nada dentro de él tiene argumentos para negarse.
Vale la pena decirlo claramente, porque invierte la forma en que la mayoría de la gente piensa sobre el diseño: las exclusiones no son la ausencia de arquitectura. Son su parte más resistente. Este es el mismo principio mencionado anteriormente en esta serie: un límite es una garantía, no una limitación, llevado un nivel más profundo. No solo dónde termina CSS y comienza JavaScript, sino lo que CSS se niega a convertirse mientras permanece por completo dentro de su propio dominio.
Demostración del principio
Sintaxis idéntica. Validez idéntica, en lo que respecta al navegador. Uno es un valor. El otro es estado de la aplicación, vestido de token, porque nada en la plataforma los distingue y nada en el diseño del sistema decidió hacerlo. El navegador nunca rechazará esto. El rechazo tiene que provenir de una decisión tomada de antemano; no de una limitación que la plataforma entregue gratis a nadie.
quell como caso de estudio
La capa de tokens de quell contiene valores, y solo valores. No porque la plataforma lo imponga, sino porque el sistema decidió, de antemano, no permitir que nada que se asemeje a estado o lógica viva allí.
La lección más amplia
Los sistemas más fuertes, tanto en el desarrollo de software como fuera de él, suelen definirse tanto por lo que han declarado que no harán como por lo que pueden hacer. Qué no debería hacer esto nunca es una pregunta más difícil que qué debería hacer esto, precisamente porque exige una decisión tomada de antemano, una que la conveniencia seguirá tentando silenciosamente a romper más tarde.
Esa es la diferencia entre un sistema que simplemente funciona hoy y uno construido para seguir teniendo sentido después de que la persona que lo escribió ya no sea quien responda las preguntas al respecto.
Top comments (0)