Elegir para tu equipo: el criterio honesto

Las cuatro lecciones anteriores han descrito herramientas: el patrón MV, el modelo de vista moderno con @Observable, las arquitecturas unidireccionales como TCA y la separación en capas con un repository como aduana. Ninguna de ellas es la respuesta, porque la pregunta nunca fue cuál es mejor en abstracto. Una arquitectura la ejecutan personas concretas, con una antigüedad concreta en el proyecto, bajo una presión de calendario concreta, y esas variables pesan más en el resultado que cualquier propiedad formal del patrón elegido. Un diseño impecable que el equipo no sostiene se degrada en meses hasta quedar peor que el diseño mediocre que todos entendían. Este cierre trata de eso: de elegir mirando al equipo y no al blog de moda, y de escribir la decisión de forma que pueda revisarse sin que nadie pierda la cara.

Las tres variables que deciden

El tamaño no se mide en pantallas sino en superficie de estado compartido: cuántas entidades vive el usuario a la vez, cuántas pantallas escriben sobre las mismas y cuánta asincronía las cruza. Diez pantallas independientes son un proyecto pequeño; tres pantallas que comparten una sesión, un carrito y una sincronización en segundo plano son un proyecto grande.

Esa distinción explica por qué las comparativas basadas en el número de pantallas no predicen nada. La complejidad de una app no crece con la cantidad de vistas sino con la cantidad de pares de vistas que pueden interferir entre sí, y esa magnitud crece mucho más deprisa. Añadir la cuarta pantalla que escribe sobre el carrito no suma una unidad de dificultad: suma tres relaciones nuevas que alguien tendrá que mantener coherentes.

La rotación importa porque una arquitectura es también un mecanismo de transmisión de conocimiento. Si cada seis meses entra gente nueva, el patrón explícito y verificado por el compilador vale mucho más que el patrón implícito que se aprendía leyendo a quien ya se fue. La pregunta operativa es incómoda pero útil: si mañana desaparecieran las dos personas con más antigüedad, cuánto del diseño seguiría siendo evidente a partir del código, y cuánto era en realidad tradición oral sostenida por su presencia en las revisiones.

El apetito por la ceremonia es la variable que casi nadie mide y la que más predice el fracaso. Se mide con hechos, no con intenciones: cuántas pruebas escribe hoy el equipo sin que nadie las pida, si las revisiones de código discuten diseño o solo estilo, si la última convención acordada sigue viva seis meses después.

Conviene ver el mismo requisito escrito en los tres regímenes, porque la diferencia de coste se hace visible de golpe. El requisito es trivial a propósito: no permitir el envío mientras el campo esté vacío.

// Regimen 1: estado suelto en la vista
struct EnvioView: View {
    @State private var texto = ""
    var body: some View {
        Button("Enviar") { }.disabled(texto.isEmpty)
    }
}

// Regimen 2: modelo de vista con la regla nombrada
@Observable final class EnvioViewModel {
    var texto = ""
    var puedeEnviar: Bool { !texto.isEmpty }
}

// Regimen 3: la regla vive en un reducer y la mutacion es un dato
@Reducer struct Envio {
    @ObservableState struct State: Equatable {
        var texto = ""
        var puedeEnviar: Bool { !texto.isEmpty }
    }
    enum Action: Equatable { case textoCambio(String), enviarTocado }
}

Ninguno de los tres es incorrecto y los tres expresan la misma regla. Lo que cambia es cuánto contexto hay que sostener para leerlos y cuánto se gana cuando el requisito deja de estar solo.

Con un solo requisito, el tercer régimen parece un despilfarro evidente. Con cuarenta requisitos que se cruzan entre sí y efectos que llegan tarde, la relación se invierte y el primero se vuelve insostenible. El error consiste en decidir mirando un requisito cuando vas a vivir con cuarenta, o en decidir mirando cuarenta cuando solo vas a tener uno.

La matriz honesta

Con las tres variables sobre la mesa, la recomendación deja de ser opinión. Esta tabla no sustituye al juicio, pero obliga a nombrar por qué te apartas de ella.

Hay dos formas de usar mal esta tabla. La primera es tratarla como un veredicto y saltarse la medición, con lo que solo has cambiado una opinión por otra con formato de tabla. La segunda es leer solo la fila que confirma lo que ya querías hacer, que es el uso más frecuente de cualquier matriz de decisión publicada. El valor de la tabla no está en la recomendación sino en la obligación de escribir tres números antes de opinar.

La última fila es la más importante y la que más se ignora. Cuando la app pide formalidad y el equipo no tiene apetito, adoptar la arquitectura formal produce lo peor de ambos mundos: la ceremonia se escribe mal, las acciones degeneran en setters, las pruebas exhaustivas se desactivan una a una y al cabo de un año queda un patrón caro que ya no garantiza nada.

flowchart TD
A[Decision de arquitectura] --> B{superficie de estado alta}
B -->|no| MV[Patron MV con capas minimas]
B -->|si| C{el equipo escribe pruebas hoy sin que se lo pidan}
C -->|no| F[Formar y separar capas antes de formalizar]
C -->|si| D{la rotacion es alta}
D -->|no| ISLA[Arquitectura formal solo en las islas criticas]
D -->|si| TODO[Arquitectura formal generalizada y modulos]
style MV fill:#a6e3a1,color:#11111b
style F fill:#f9e2af,color:#11111b
style TODO fill:#89b4fa,color:#11111b

Los costes que nadie mete en la ecuación

Las comparativas suelen contar líneas de código y detenerse ahí, que es la parte más barata. La formación cuesta semanas de productividad reducida por persona, y se paga de nuevo con cada incorporación. Los tiempos de compilación de una arquitectura con tipos genéricos anidados degradan el bucle de trabajo diario, y ese bucle es lo que determina cuántas veces al día alguien prueba una idea. Una dependencia externa impone su calendario de migraciones al tuyo. Y el coste que casi nunca se estima es el de reversión: cuánto costaría volver atrás si la decisión sale mal, porque una decisión con reversión barata puede tomarse con la mitad de certeza que una irreversible.

Cómo se revisa sin drama

Una decisión de arquitectura debería escribirse en una página con cuatro apartados: los síntomas que la motivan, la opción elegida, las opciones descartadas con su motivo, y los criterios objetivos que obligarían a revisarla, con fecha. Ese último apartado es el que convierte una creencia en una hipótesis. Criterios útiles: que las incidencias por estados imposibles no bajen en dos ciclos, que el tiempo de compilación supere un umbral acordado, que una incorporación tarde más de un mes en abrir una pull request en solitario. Cuando el criterio se cumple, la revisión no es una derrota de nadie: es el plan funcionando.

Ese documento tiene además una función que no es técnica y que justifica por sí sola escribirlo: transfiere la decisión de las personas al proyecto. Quien entre dentro de un año no tendrá que reconstruir el razonamiento preguntando a quien quede, ni deducirlo del código, ni volver a discutir desde cero una cuestión ya resuelta. Y quien defendió la opción descartada puede señalar el criterio de revisión en lugar de reabrir el debate cada trimestre, que es la forma más silenciosa en que un equipo pierde tiempo.