Refactoriza una pantalla sin cambiar su comportamiento

Este caso de uso te sirve cuando el código de una pantalla de SwiftUI ha crecido tanto dentro de un solo archivo que hasta el cambio más pequeño parece arriesgado. El objetivo no es rediseñar la funcionalidad ni inventar una arquitectura nueva. Pídele a Codex que conserve el comportamiento y la disposición de los elementos, y que luego divida la pantalla en subvistas pequeñas con un flujo de datos explícito. Así será más fácil revisar el siguiente cambio.

Usa el complemento Build iOS Apps para este tipo de refactorización. Su habilidad para refactorizar vistas de SwiftUI sigue criterios concretos: usa MV de forma predeterminada en lugar de MVVM, mantén la lógica de negocio en servicios o modelos, recurre primero al estado local de la vista y a las dependencias del entorno, y conserva un modelo de vista solo cuando la funcionalidad lo necesite claramente.

Qué pedirle a Codex

Empieza por indicar el archivo de una pantalla específica y pídele a Codex que mejore su estructura sin cambiar su comportamiento. Conviene incluir estas reglas de refactorización directamente en el prompt:

• Reordena el archivo para que sea fácil identificar, de arriba abajo, las dependencias del entorno, las propiedades almacenadas, el estado calculado que no representa vistas, init, body, los auxiliares de vista y los métodos auxiliares.
• Extrae las secciones que tengan sentido por sí solas y crea un tipo View para cada una, con entradas pequeñas y explícitas, enlaces @Binding y callbacks.
• Usa pocas propiedades calculadas de tipo some View como auxiliares y mantenlas breves. Evita convertir una pantalla enorme en una larga lista de propiedades calculadas privadas que devuelven fragmentos de vista.
• Saca de body las acciones de botón que no sean triviales y los efectos secundarios. Lleva la lógica de negocio propiamente dicha a servicios o modelos.
• Mantén estable el árbol de la vista raíz. Prefiere los condicionales dentro de secciones o modificadores a las ramas if/else de nivel superior que reemplazan pantallas enteras.
• A medida que avances, corrige qué vista se encarga de cada modelo de Observation. En iOS 17 o posterior, la vista propietaria de un modelo raíz @Observable debe almacenarlo en @State. Usa los wrappers anteriores para modelos observables solo si lo exige la versión mínima de iOS que admite tu app.

Pide una validación breve en cada paso

Comprueba que la refactorización conserve el comportamiento. Pídele a Codex que, cada vez que extraiga una sección relevante, ejecute la comprobación más pequeña que permita verificar la pantalla, ya sea con una compilación, una vista previa, una prueba o el simulador. Luego pídele que resuma qué cambió en la estructura y qué conservó de forma intencional.

Consejos prácticos

Divide primero la pantalla y deja la discusión sobre arquitectura para después

Si una pantalla es demasiado grande, pídele a Codex que extraiga las vistas de cada sección antes de introducir otra capa de abstracción. Con un árbol de vistas más corto y explícito, muchas veces deja de hacer falta un modelo de vista.

Pasa a cada subvista la interfaz más pequeña posible

Prefiere valores let, enlaces @Binding y callbacks con un solo propósito en lugar de pasar el modelo completo de la vista padre a cada vista hija. Así es más fácil obtener una vista previa de cada sección extraída y menos probable que, por accidente, vuelvas a acoplarla a toda la pantalla.

Pídele a Codex que indique qué decidió conservar

Para refactorizar con seguridad, conviene que Codex enumere explícitamente lo que dejó intacto: las reglas de negocio, el comportamiento de la navegación, la persistencia, el significado de los datos de analítica y la disposición de los elementos que ve el usuario. Esto agiliza mucho la revisión.