Gobernar el crecimiento: medir el estado, revisarlo y podar lo muerto

Ninguna base de código adelgaza por sí sola. El estado crece porque cada adición resuelve un problema visible hoy y su coste se difiere a un futuro sin responsable, mientras que cada retirada exige demostrar que nada depende de lo que se elimina, y demostrar una ausencia es epistemológicamente caro incluso cuando el sistema es pequeño. La consecuencia es una acumulación monótona que nadie decidió y que solo se percibe cuando ya duele: campos que ningún código lee, ámbitos compartidos que sobrevivieron a la feature que los justificaba, cachés persistidas con formas de hace tres versiones. Gobernar ese crecimiento no consiste en tener más disciplina, sino en instituir un procedimiento que haga la poda tan barata y tan rutinaria como la adición.

Medir antes de opinar

Una conversación sobre si el estado se ha vuelto inmanejable sin números es una conversación sobre sensaciones, y termina siempre en el mismo empate entre quien percibe complejidad y quien recuerda por qué cada pieza está ahí. Las métricas útiles son pocas y todas se obtienen del repositorio sin instrumentar nada, lo que importa porque una medición que exige montar infraestructura no se repite y una métrica que no se repite no sirve para detectar tendencias, que es exactamente lo único que aquí interesa.

Una precisión sobre qué se está midiendo exactamente, porque la ambigüedad aquí arruina la serie. El tamaño relevante no es el número de bytes que el estado ocupa en memoria, que es casi siempre irrelevante y además fácil de confundir con un problema de rendimiento, sino el número de posiciones independientes que el sistema puede ocupar y que alguien tendría que considerar para razonar sobre él. Diez campos booleanos independientes producen mil veinticuatro configuraciones posibles; un único campo con cuatro valores excluyentes produce cuatro. La métrica útil, por tanto, penaliza la independencia entre campos y premia las representaciones que la eliminan.

De las cuatro, la relación entre escritores y lectores es la que mejor predice defectos futuros. Un dato con muchos lectores y un solo escritor es un caso sano: la forma puede cambiar detrás de una lectura derivada y la coherencia está garantizada por construcción. Un dato con varios escritores repartidos por módulos distintos es una condición de carrera latente y una fuente de estados imposibles, porque ninguna de las escrituras conoce las invariantes que las otras suponen. Cuando esa cifra aparece en una revisión, el remedio no es documentar sino cerrar la escritura tras una operación única del dominio propietario.

// tres senales extraibles del propio repositorio
// 1. superficie: exportaciones por dominio
//    rg "^export (const|function|type)" src/dominios/*/index.ts | contar por carpeta
// 2. alcance: modulos que importan cada dominio
//    rg "from \"@app/dominios/carrito\"" -l | contar
// 3. escritores: llamadas a operaciones de escritura por dominio
//    rg "carrito\\.(set|anadir|quitar|vaciar)" -l | contar

Las métricas de estado comparten con todas las demás una patología conocida, y conviene anticiparla: en cuanto se convierten en objetivo dejan de medir lo que medían. Un equipo evaluado por el número de exportaciones de sus dominios reducirá ese número agrupando cosas en objetos más anchos, que es exactamente el movimiento contrario al que se pretendía inducir. La protección es usarlas siempre como disparador de conversación y nunca como criterio de evaluación: la métrica señala dónde mirar, y quien mira decide, con contexto, si lo que encuentra es un problema o una consecuencia razonable del dominio.

La revisión periódica

Una revisión de estado es una reunión corta y regular con un guion fijo, y su valor no está en las decisiones que toma sino en que crea el único momento del calendario en el que retirar algo es una acción esperada en vez de una interrupción. Sin ese momento, la poda compite con el trabajo de producto y pierde siempre, porque su beneficio es difuso y su riesgo concreto, que es la asimetría que hace que ninguna base de código adelgace por iniciativa espontánea.

flowchart LR
M[recoger metricas del repositorio] --> S[senalar los tres peores casos]
S --> D[decidir podar migrar o mantener]
D --> P[marcar como obsoleto y observar uso real]
P --> R[retirar cuando no haya lecturas]
R --> M

El guion que funciona tiene cuatro pasos y cabe en cuarenta y cinco minutos. Se leen las métricas y su variación desde la revisión anterior. Se señalan los tres peores casos por alcance, por número de escritores o por edad sin lectura, y solo tres, porque una lista larga garantiza que no se hará nada. Se decide para cada uno entre podar, migrar o mantener con justificación registrada. Y se asigna responsable y fecha, porque una decisión sin ambas cosas es una opinión con acta.

// registro de decisiones junto al codigo, no en una herramienta aparte
// estado/REVISIONES.md
// 2026-Q2  bannerCerrado        -> podar     (sin lecturas desde 2025-11)  ana
// 2026-Q2  ultimoPedidoVisto    -> migrar    (pasa a parametro de ruta)    luis
// 2026-Q2  preferenciasUsuario  -> mantener  (alcance alto pero estable)   equipo

Dos detalles del procedimiento deciden si la revisión sobrevive más de tres trimestres. El primero es que las métricas se recojan de forma automática antes de la reunión y no durante ella, porque una sesión que empieza recopilando datos consume su energía en la parte mecánica y llega exhausta a la parte que exige juicio. El segundo es que la reunión tenga poder de decisión y no solo de recomendación: si la conclusión debe pasar por otra instancia para convertirse en trabajo planificado, el equipo aprenderá en dos iteraciones que la revisión no cambia nada y dejará de prepararla, con toda la razón.

// la recogida es automatica y se ejecuta antes de la revision
// package.json  ->  "estado:metricas": "node scripts/metricas-estado.mjs"
// salida: una fila por dominio con superficie, alcance, escritores y edad
// se compara contra la fila del trimestre anterior y se ordena por deterioro

La decisión de mantener merece tanta atención como la de podar, porque es la que más veces se toma y la que menos se justifica. Registrar el motivo cuesta una línea y produce un efecto acumulativo notable: en la revisión siguiente, quien lea que un ámbito se mantuvo por su estabilidad podrá comprobar si esa estabilidad se ha confirmado, y si no, la decisión anterior queda automáticamente refutada. Sin ese registro, cada revisión empieza de cero y el equipo discute cuatro veces al año exactamente lo mismo.

Podar con evidencia, no con inspección

Conviene además ordenar la poda por riesgo antes que por tamaño, porque el instinto de empezar por lo más grande es el que más incidentes produce. Lo primero que se retira es aquello cuya desaparición no puede romper ninguna invariante: campos de presentación, marcas de banners, restos de experimentos concluidos. Lo último, aquello de lo que dependen reglas de negocio, aunque parezca muerto. Ese orden tiene un beneficio adicional y decisivo: las primeras podas construyen la confianza del equipo en el procedimiento, y sin esa confianza nadie autorizará jamás las que de verdad importan.

Retirar estado por inspección del código es inseguro en cualquier lenguaje con acceso dinámico, con serialización o con datos persistidos en dispositivos ajenos, que es el caso de prácticamente toda aplicación real. El procedimiento seguro sustituye la inspección por observación: se marca la porción como obsoleta, se instrumenta su lectura, se espera un periodo que cubra los ciclos de uso reales, y se retira cuando el contador siga en cero. Es más lento que borrar y es la única forma de borrar sin generar un incidente.

// paso 1: marcar y observar en vez de borrar a ciegas
export const bannerCerrado = observar(estado.bannerCerrado, {
  alLeer: () => registrar("estado-obsoleto", { campo: "bannerCerrado" }),
})

// paso 2: tras un periodo sin lecturas, retirar el campo y su migracion
// paso 3: dejar una migracion que lo elimine del estado persistido antiguo

La poda tiene además una forma que casi nunca se reconoce como tal y que produce la mayor reducción por unidad de esfuerzo: sustituir varios campos independientes por una unión discriminada que solo admita las combinaciones válidas. No se elimina información, se elimina la posibilidad de representarla mal, y con ella desaparecen las ramas defensivas, las comprobaciones redundantes y los casos imposibles que alguien escribió por si acaso. Medido en posiciones alcanzables del estado, este cambio poda más que cualquier borrado de campos muertos, y a diferencia de aquel no requiere periodo de observación.

// cuatro campos independientes: dieciseis combinaciones, doce sin sentido
type Carga = { cargando: boolean; error?: Error; datos?: Pedido; vacio: boolean }

// una union discriminada: cuatro posiciones y ninguna invalida
type Carga =
  | { fase: "inicial" }
  | { fase: "cargando" }
  | { fase: "listo"; datos: Pedido }
  | { fase: "fallo"; error: Error }

El estado persistido añade una dificultad que se olvida con frecuencia: aunque el código nuevo ya no lo lea, sigue existiendo en los dispositivos de los usuarios y reaparecerá en cuanto alguien rehidrate una versión antigua. Por eso la poda no termina al borrar el campo del tipo, sino al añadir la migración que lo elimina del almacenamiento y al comprobar que la versión del esquema se incrementa. Omitir ese paso produce el fenómeno más desconcertante de todos, que es un dato que vuelve por sí solo semanas después de haberlo eliminado.

La instrumentación de lectura tiene un coste que conviene acotar desde el principio para que no se convierta en un problema propio. Registrar cada acceso a un campo caliente puede generar un volumen de telemetría desproporcionado, así que la práctica correcta es muestrear y quedarse solo con el primer registro por sesión, que es toda la información que la decisión necesita: no interesa cuántas veces se leyó, sino si alguien lo leyó. Y conviene poner fecha de retirada a la propia instrumentación, porque los observadores olvidados son también una forma de estado muerto.

// muestreo por sesion: la decision solo necesita saber si alguien leyo
let registrado = false
export const bannerCerrado = observar(estado.bannerCerrado, {
  alLeer: () => { if (!registrado) { registrado = true; registrar("obsoleto") } },
})
// retirar esta instrumentacion antes de 2026-12 aunque no se haya decidido nada