El veredicto pragmático y la migración gradual

Después de cuatro lecciones de genealogía, análisis y tablas, lo que un equipo se lleva a la reunión del lunes no puede ser una postura: tiene que ser un procedimiento. Y el procedimiento útil aquí es más modesto de lo que las discusiones de arquitectura sugieren. No hay que decidir el patrón de la app, porque las apps no tienen un patrón: tienen pantallas, y las pantallas de una misma app difieren en complejidad y en criticidad más de lo que difieren dos apps entre sí. La pantalla de ajustes con cuatro interruptores y el flujo de pago en tres pasos con reintentos y confirmación no merecen la misma disciplina, y forzarles la misma es cometer uno de dos errores simétricos: ceremonia inútil en la primera o libertad peligrosa en la segunda. Esta lección entrega tres preguntas que sitúan cada pantalla donde le toca, defiende sin disculpas los casos en que MVVM es la respuesta correcta, y describe cómo moverse hacia MVI en pasos que valen la pena por separado, porque una migración que solo rinde al final es una migración que se abandonará a la mitad.

Tres preguntas que deciden

El criterio no necesita ser sofisticado, necesita ser aplicable en cinco minutos por cualquier miembro del equipo y dar la misma respuesta en manos distintas. Estas tres preguntas cumplen.

La primera es de complejidad: cuántas piezas independientes tiene el estado de la pantalla y cuántas fuentes asíncronas pueden escribirlas a la vez. Con tres piezas y una corrutina, el riesgo de incoherencia es teórico. Con siete piezas y tres fuentes concurrentes, es estadístico.

La segunda es de criticidad: qué pasa si el usuario ve durante un segundo un estado que nadie diseñó. En un buscador es un parpadeo que nadie reporta. En una pantalla de transferencia es un incidente, y posiblemente un cargo duplicado.

La tercera es de longevidad: cuántas veces se va a tocar esta pantalla en los próximos dos años y por cuántas personas distintas. La ceremonia se paga una vez; las decisiones repetidas que la ceremonia elimina se pagan cada vez, multiplicadas por el número de personas que las toman con criterios distintos.

Las tres preguntas tienen la propiedad que hace útil a cualquier criterio de equipo: se contestan con datos que ya existen. El número de piezas del estado se cuenta leyendo el ViewModel. La criticidad la contesta quien lleva el producto en una frase. Y la longevidad se estima mirando el historial del control de versiones, que dice cuántas veces se tocó esa pantalla el año pasado y cuántos autores distintos aparecen. Ninguna de las tres exige una reunión de arquitectura ni una opinión sobre patrones, que es exactamente lo que las hace aplicables.

Cuándo MVVM es suficiente, sin disculpas

Conviene decir esto sin el tono de concesión que suele acompañarlo, porque el tono importa: hay pantallas donde MVVM no es lo aceptable mientras llega algo mejor, sino lo correcto.

Hay un cuarto caso menos obvio y bastante frecuente: las pantallas cuyo estado no es realmente suyo. Una lista que refleja directamente una consulta a base de datos observable, sin filtros ni modos locales, tiene su fuente de verdad fuera del ViewModel, y envolverla en un reductor añade una capa que no decide nada. El reductor rinde cuando hay decisiones que tomar sobre el estado; si el estado solo se transporta, MVI es tubería con ceremonia.

La migración en cuatro pasos

La migración que funciona no reescribe: aprieta. Y su propiedad esencial es que cada paso deja la base de código mejor aunque los siguientes no lleguen nunca, porque la mayoría de las migraciones que se anuncian no se terminan.

// Paso 1: reunir los observables en un solo tipo. La entrada no se toca.
data class BusquedaState(
    val consulta: String = "",
    val contenido: Contenido = Contenido.Vacio,
)

class BusquedaViewModel : ViewModel() {
    private val _state = MutableStateFlow(BusquedaState())
    val state: StateFlow<BusquedaState> = _state.asStateFlow()

    // Los metodos publicos siguen siendo los de siempre
    fun onConsultaCambiada(t: String) = _state.update { it.copy(consulta = t) }
    fun onBuscar() { /* escribe el estado entero, de una pieza */ }
}

El paso uno unifica el estado y no toca la entrada. Es el que más rinde por lo que cuesta: elimina la ventana de incoherencia, hace la pantalla comprobable por valor y permite empezar a apretar tipos. Y es completamente reversible.

El paso dos aprieta ese tipo. Los campos que se excluyen mutuamente pasan a ser un tipo suma, los que no pueden faltar dejan de ser anulables, y las combinaciones imposibles dejan de compilar. No cambia ninguna interfaz pública; cambia qué se puede representar.

// Paso 2: el compilador empieza a rechazar lo que el dominio no admite.
sealed interface Contenido {
    data object Cargando : Contenido
    data object Vacio : Contenido
    data class Exito(val items: List<Item>) : Contenido
    data class Error(val mensaje: String) : Contenido
}

Este paso es el que más equipos se saltan y el que más rinde por línea escrita, porque sin él el paso uno solo ha cambiado la forma del contenedor sin reducir lo que cabe dentro. La señal de que se ha hecho bien es concreta y se puede comprobar en una revisión: después del paso dos no debe quedar en el estado ningún par de campos cuya combinación no corresponda a una pantalla que alguien dibujó.

// Paso 3: extraer un reductor puro. La vista sigue llamando a metodos.
fun reduce(estado: BusquedaState, intent: BusquedaIntent): BusquedaState = when (intent) {
    is BusquedaIntent.ConsultaCambiada -> estado.copy(consulta = intent.texto)
    BusquedaIntent.Buscar -> estado.copy(contenido = Contenido.Cargando)
    BusquedaIntent.Reintentar -> estado.copy(contenido = Contenido.Cargando)
}

El paso tres extrae las transiciones a una función pura, aunque los métodos públicos sigan existiendo y se limiten a delegar en ella. Aquí llega la comprobabilidad completa sin haber cambiado todavía nada del lado de la vista. El paso cuatro, y solo si las tres preguntas lo justifican, colapsa los métodos públicos en un único onIntent, con lo que aparecen la trazabilidad, la reproducibilidad y las políticas transversales.

// Paso 4: los metodos publicos se conservan un tiempo y delegan en la unica entrada.
fun onIntent(intent: BusquedaIntent) = _state.update { reduce(it, intent) }

@Deprecated("Usa onIntent", ReplaceWith("onIntent(BusquedaIntent.Buscar)"))
fun onBuscar() = onIntent(BusquedaIntent.Buscar)

Ese periodo de convivencia es lo que hace la migración soportable en una app viva. Las pantallas que ya llaman a los métodos antiguos siguen funcionando, las nuevas usan la entrada única, y el aviso de obsolescencia convierte la migración pendiente en una lista que el compilador mantiene sola. Cuando la lista llega a cero, los métodos se borran; si nunca llega, la base de código sigue siendo coherente y nadie ha quedado a medias.

flowchart LR
P0[MVVM disperso] --> P1[Paso 1 estado unico]
P1 --> P2[Paso 2 tipos apretados]
P2 --> P3[Paso 3 reductor puro]
P3 --> P4[Paso 4 entrada unica]
style P1 fill:#f9e2af,color:#11111b
style P3 fill:#89b4fa,color:#11111b
style P4 fill:#a6e3a1,color:#11111b

Los cuatro errores que se repiten

Las migraciones fracasan casi siempre por los mismos motivos, y ninguno es técnico.

El primero es la reescritura total: congelar funcionalidades para migrar la app entera. Termina mal por aritmética elemental, no por falta de voluntad: el valor llega solo al final, el negocio pierde la paciencia antes, y lo que queda es media app en cada estilo con la peor propiedad de ambos.

El segundo es la adopción por decreto. Imponer MVI en todas las pantallas nuevas sin criterio produce ajustes con reductor de tres líneas y un tipo sellado de dos intents, que es exactamente el ejemplo que los escépticos usarán —con razón— para argumentar que el patrón es burocracia.

Hay una variante de este error que se disfraza de rigor: aplicar MVI en las pantallas nuevas y dejar las viejas como estaban, sin plan. El resultado no es una migración gradual sino una app con dos dialectos permanentes, donde cada persona tiene que saber en cuál está antes de leer nada. La diferencia entre migración gradual y bilingüismo crónico es que la primera tiene un orden justificado y un criterio para detenerse; la segunda solo tiene la fecha en que se escribió cada archivo.

El tercero es el estado unificado que nadie aprieta. Reunir ocho observables en una data class de ocho campos anulables y booleanos deja el mismo espacio combinatorio de antes, ahora con una fachada de orden. El paso uno sin el paso dos entrega la mitad del beneficio y toda la ilusión de haber terminado.