Señales de que TCA no es para tu equipo

Una guía que solo sabe decir que sí no es una guía, es publicidad. Llevas veintinueve niveles viendo por qué el flujo unidireccional, el estado como valor y las dependencias explícitas resuelven problemas reales, y todo eso sigue siendo verdad; lo que no se sigue de ahí es que TCA sea la decisión correcta para tu equipo, tu app y tu año. Una arquitectura no se evalúa por su elegancia interna sino por el ajuste entre lo que exige y lo que la organización puede sostener, y ese ajuste depende de variables que no aparecen en ningún repositorio: cuánta gente hay, cuánto tiempo se queda, cuántos años va a vivir el producto y quién enseñará esto cuando el que lo trajo se marche. Esta lección trata de esas variables y de cómo decir que no sin haber perdido el tiempo.

Lo que cuesta de verdad la curva

La curva de TCA no está donde la gente cree. La sintaxis se aprende en una tarde: un State, una Action, un Reducer, un Store. Lo que cuesta semanas es la inversión del control, es decir, interiorizar que no puedes hacer las cosas aquí. Quien viene de escribir un método que llama a la red, actualiza una propiedad y navega a la siguiente pantalla se encuentra con que ninguna de esas tres cosas se hace en el sitio donde se le ocurren: la llamada se devuelve como valor, la propiedad se cambia en el reducer al recibir una acción y la navegación es un dato. El momento en que alguien dice que quiere hacer una cosa sencilla y no le dejan es el momento crítico de la adopción, y es donde se decide si esa persona aprenderá la arquitectura o la saboteará escribiendo efectos con mutaciones dentro.

El aprendizaje ocurre en tres tramos con perfiles muy distintos, y confundirlos lleva a estimar mal. El primero, de unos días, es mecánico: reconocer las piezas y copiar la forma de una feature existente. El segundo, de dos a cuatro semanas, es el de la inversión del control, y es el único que puede fallar del todo. El tercero, de meses, es el de las decisiones de diseño: cuándo dividir un reducer, qué acciones son delegate, dónde poner una dependencia. Ese tercero no bloquea la productividad y se adquiere revisando código ajeno, pero es el que separa una app en TCA de una app que solo lo parece.

Con acompañamiento y revisiones de código serias, la cifra realista para una persona con experiencia media es de dos a cuatro semanas hasta ser productiva y de tres a seis meses hasta escribir TCA sin fricción. Sin acompañamiento la cifra no converge: se produce una capa de código que tiene la forma de TCA y la semántica de MVVM, con reducers que llaman a servicios directamente y estados que se mutan desde efectos, que es peor que no haber migrado porque paga todo el coste y no compra ninguna garantía.

Tamaño y vida del proyecto

El cálculo es sencillo de plantear y muy revelador. TCA impone un coste aproximadamente fijo por feature: modelar el estado, enumerar las acciones, escribir el reducer, declarar las dependencias, componer y testear. Ese coste no baja mucho con la experiencia porque no es tiempo perdido, es trabajo de diseño. El beneficio, en cambio, no es fijo: crece con el número de estados que interactúan entre sí, con el número de personas que tocan el mismo código y, sobre todo, con los años que el producto seguirá vivo, porque casi todo lo que TCA compra —reproducibilidad, verificación, composición— se cobra al volver a tocar algo.

Hay un caso que engaña y conviene nombrarlo: la app mediana con muy poca lógica de estado, esencialmente una lista, un detalle y un formulario sobre una interfaz de red. Es grande en pantallas y minúscula en dominio, y ahí TCA cobra el coste por pantalla y no encuentra apenas complejidad que dominar. El indicador que separa a esta de una app que sí lo necesita no es el número de pantallas sino cuántos estados pueden ser simultáneamente verdaderos y contradecirse.

Hay una variante del cálculo que merece hacerse aparte, porque es la que decide en la mayoría de los casos intermedios: la fracción de la app que es concurrente. Una aplicación cuyos problemas son de disposición y de red sencilla se beneficia poco; una donde conviven descargas que se pisan, temporizadores, reconexiones, sincronización en segundo plano y cancelaciones al navegar se beneficia enormemente, porque casi todo lo que TCA impone —efectos como valores, cancelación por identificador, relojes inyectados— existe precisamente para domar eso. Si al listar tus defectos abiertos encuentras muchos con las palabras a veces, en ocasiones o solo si vas rápido, el dominio es concurrente aunque el producto no lo parezca.

La rotación y quién custodia el conocimiento

La lectura habitual dice que con mucha rotación no conviene una arquitectura exigente, y es una verdad a medias que conduce a decisiones malas. La uniformidad de TCA ayuda al incorporarse: todas las features tienen la misma forma, el sitio donde ocurre cada cosa es predecible y no hay que aprender la interpretación particular de MVVM que cada equipo inventó. El problema no es la rotación en sí, es el factor de autobús del conocimiento arquitectónico.

Si hay una sola persona capaz de explicar por qué ese Scope está ahí, por qué el efecto se cancela con ese identificador o por qué la acción es delegate y no interna, la arquitectura no es del equipo sino de esa persona, y el día que se vaya el resto seguirá copiando formas sin entenderlas. La degradación es rápida y tiene un aspecto reconocible: reducers que crecen sin dividirse, acciones que replican los métodos de un servicio, tests desactivados. Antes de adoptar conviene responder a una pregunta concreta: si la persona que más sabe de esto se fuese en tres meses, quién revisaría los cambios. Si no hay respuesta, el trabajo previo no es migrar sino formar a la segunda persona.

Existe además una asimetría que juega a favor de TCA y que conviene tener presente para no exagerar el riesgo. En una base de código MVVM sin convenciones, incorporarse cuesta porque hay que aprender la interpretación local de la arquitectura, que nadie escribió y que varía entre pantallas; en una base de código TCA disciplinada, incorporarse cuesta porque hay que aprender una arquitectura difícil, pero esa arquitectura está documentada fuera de la empresa, tiene ejemplos públicos y es la misma en todos los sitios donde se usa. La primera dificultad no es transferible y hay que pagarla entera en cada equipo; la segunda se paga una vez en la carrera de una persona. Con rotación alta, eso importa más de lo que parece, y explica por qué la respuesta correcta a la rotación no es siempre bajar el listón.

Las seis señales, y qué hacer en su lugar

Estas son las señales que, si aparecen dos o más a la vez y llevan un trimestre ahí, aconsejan detener la adopción y no insistir. Ninguna es una opinión: todas se comprueban mirando el repositorio o preguntando al equipo, y por eso sirven para tener la conversación sin que degenere en preferencias personales.

La segunda señal tiene una firma inconfundible en el código, y merece la pena saber reconocerla de un vistazo, porque es el modo exacto en que una adopción se convierte en lo peor de los dos mundos.

case .aparecio:
  return .run { _ in
    let datos = try await ServicioLegado.shared.cargar()
    ServicioLegado.shared.cache = datos   // mutación fuera del reducer
    NotificationCenter.default.post(name: .datosListos, object: nil)
  }

Ahí no hay ninguna acción que represente lo ocurrido, ningún cambio de estado que un test pueda afirmar y ningún camino para reproducir el resultado. Es MVVM con la sintaxis de TCA, y paga el coste completo de la arquitectura sin comprar ni una de sus garantías. Renunciar a TCA no obliga a renunciar a sus ideas, y esta es la parte que casi nunca se dice. Las piezas más valiosas están disponibles por separado y se adoptan de una en una, con una curva mucho más suave: swift-dependencies da la inyección explícita con valores para test y preview, que es probablemente el sesenta por ciento del beneficio total; swift-navigation da la navegación dirigida por estado sin adoptar el resto; un ViewModel con @Observable puede tener su estado modelado como valor y hacer imposibles los estados inválidos, exactamente como en el Nivel 7. Un equipo que adopta estas tres cosas sobre MVVM se queda con la mayor parte del rendimiento y sin el coste de la inversión del control, y además queda en la mejor posición posible para adoptar TCA más adelante, si alguna vez lo necesita.

@Observable
@MainActor
final class DetalleModelo {
  private(set) var estado: Carga<Pedido> = .inicial   // el estado, modelado como valor
  @ObservationIgnored @Dependency(\.pedidos) var pedidos

  func aparecio() async {
    estado = .cargando
    estado = await Result { try await pedidos.detalle(id) }.aCarga()
  }
}

Ahí no hay Store, ni reducer, ni acciones, y sin embargo hay tres de las cuatro propiedades que llevas veintinueve niveles persiguiendo: la dependencia es explícita y sustituible en un test, el estado es un valor con casos exhaustivos que hacen imposible mostrar datos y error a la vez, y la clase se puede instanciar sin interfaz. Lo único que falta es la garantía de que toda mutación tenga nombre, que es exactamente lo que cuesta la curva. Poner ese precio sobre la mesa, en vez de esconderlo detrás de una recomendación categórica, es lo que permite decidir con la cabeza fría.

flowchart TD
A[Evaluar la adopcion] --> B[Hay dominio con estados que se contradicen]
B -- no --> M[MVVM con estado modelado como valor]
B -- si --> C[La app vivira varios anos]
C -- no --> M
C -- si --> D[Hay quien custodie el conocimiento]
D -- no --> P[Adoptar solo dependencias y navegacion]
D -- si --> T[Adoptar TCA por flujos]
style T fill:#a6e3a1,color:#11111b
style P fill:#f9e2af,color:#11111b
style M fill:#89b4fa,color:#11111b