SwiftUI Serie 15 ｜ Cree un proyecto SwiftUI mantenible desde cero

Si me pidieran que creara un proyecto SwiftUI desde cero, lo primero que consideraría no sería el aspecto del directorio, ni me preocuparía primero por ello:

• ¿Necesita enviar una plantilla de arquitectura completa? -¿Necesito dibujar muchas capas base primero?

Lo primero que estoy pensando son estas cosas:

• Cómo fluye el estado
• Cómo cambiar las responsabilidades de la página
• ¿Cuándo y en qué medida se bombean los componentes?
• ¿Será difícil modificar el proyecto después de tres meses?

Debido a que muchos proyectos de SwiftUI son bastante livianos al principio, el verdadero hito a menudo ocurre después de dos o tres meses:

• Cada vez más páginas.
• El estado está cada vez peor.
• La reutilización de componentes es cada vez más aleatoria.
• Comience a apilar la lógica empresarial en View

Entonces, lo que la “mantenibilidad” realmente quiere resolver es la estabilidad después del crecimiento, no la velocidad del desarrollo en la primera semana.

1. No construiré un marco pesado desde el principio, pero primero aclararé las responsabilidades.

Uno de los malentendidos más comunes a la hora de iniciar un proyecto desde cero es:

• El negocio aún no ha comenzado.
• Primero, diseñe un conjunto completo de estructuras que parezcan completas.

Esto no es necesariamente incorrecto, pero el riesgo es:

• resumen demasiado pronto
• La estructura no se corresponde con el negocio real.
• El equipo seguirá evitandolo más tarde.

Entonces prefiero:

• Primero, aclare los límites de las responsabilidades.
• Agregue capas gradualmente a medida que aumenta la complejidad.

En lugar de “ser grande y completo el primer día”, valoro más “estar suave el primer mes”.

2. Lo primero que normalmente entiendo son las tres capas: capa de página, capa de estado y capa de capacidad.

1. Capa de página

Responsable de:

• Estructura
• Combinación de componentes
• Mapeo de estado de página

2. Capa de estado

Responsable de:

• Estado del negocio
• Procesos asincrónicos
• Cambio de estado semántico de página

3. Capa de capacidad

Responsable de:

• red
• Almacenamiento
• Servicios de dominio
• Componentes comunes y capacidades de estilo.

Es posible que estas tres capas no necesariamente se desmantelen muy finamente desde el principio, pero primero debe haber conciencia. De lo contrario, los proyectos de SwiftUI pueden caer fácilmente en “escribir todo directamente en la Vista”.

3. Seré muy cauteloso con las “vistas gigantes”

Escribir UI en SwiftUI es muy fácil, por lo que uno de los malos olores más comunes es:

• La estructura está escrita en Vista.
• La solicitud está escrita en Ver
• El juicio de estado está escrito en Ver
• El ensamblaje de redacción publicitaria también está escrito en Ver.

Por supuesto, parece muy rápido en las primeras etapas, pero una vez que el proyecto se vuelve complejo, la Vista rápidamente se convertirá en:

• Difícil de leer
• Difícil de cambiar
• Impredecible

El problema aquí es que la Vista asume demasiadas responsabilidades no relacionadas con la visualización.

4. Deliberadamente ralentizaré la reutilización de componentes en lugar de hacerlo con fuerza al principio.

Al principio, es fácil para muchos equipos buscar una “biblioteca de componentes universal”. Pero en proyectos reales, abstraer demasiado pronto suele ser más peligroso que hacerlo más tarde:

• La interfaz se diseñará para que sea demasiado amplia.
• Se preparan muchas opciones para posibles escenarios futuros.
• Los componentes parecen reutilizarse, pero en realidad quien los use se sentirá incómodo

Por lo tanto, prefiero dejar que el componente crezca primero en una o dos páginas reales y luego extraerlo una vez que el patrón sea lo suficientemente estable. Los componentes extraídos de esta manera suelen estar más cerca de su uso real que la gimnasia abstracta.

5. Los límites estatales suelen ser más importantes que la estructura del directorio

Muchos proyectos pasan mucho tiempo discutiendo al principio:

• Característica primero o capa primero
• Cómo dividir carpetas

Por supuesto que estos son importantes, pero lo que más me importa es:

• ¿Qué estado gestiona la propia página?
• Qué estados son gestionados por objetos comerciales externos.
• Qué estado se debe compartir y cuál no se debe compartir

Porque lo que realmente determina los costes de mantenimiento es a menudo si el estado está funcionando.

6. El núcleo de la mantenibilidad es en realidad permitir que cada capa “explique claramente de qué es responsable”

Si un proyecto se vuelve cada vez más difícil de cambiar más adelante, normalmente se presentan estas señales:

• La estructura de la página no muestra la prioridad.
• La atribución de estatus se vuelve cada vez más borrosa.
• Los límites de los componentes son cada vez más abstractos.
• Una vez que se cambian los requisitos, la lógica debe complementarse en muchas capas.

Entonces, para un proyecto SwiftUI mantenible, lo que más valoro suele ser:

• La página se puede leer de un vistazo.
• El estado se puede distinguir de un vistazo
• Los límites de los componentes son naturales. -La lógica empresarial no está apilada en Ver

Estas cuatro cosas son muy simples, pero extremadamente valiosas a largo plazo.

7. Conclusión: al crear un proyecto SwiftUI desde cero, lo que realmente debe configurarse correctamente primero es el límite, no la plantilla.

Para decirlo en forma más breve, diría:

Para crear un proyecto SwiftUI que se pueda mantener desde cero, lo más importante es definir correctamente los límites estatales, las responsabilidades de la página y la abstracción de los componentes.

Una vez que se establezcan estos límites, el proyecto será más largo y estable; Si no se establecen límites, no importa cuán avanzado sea el modelo, el negocio real puede borrarlo fácilmente.