Swift Package Manager Series 07 ｜ Método de gestión SPM en proyectos iOS de tamaño mediano

Si tuviera que usar SPM para administrar un proyecto iOS de tamaño mediano, mi primera preocupación no sería “cuántos paquetes eliminar”, sino estas tres preguntas:

• ¿Qué habilidades son realmente dignas de independencia?
• Cómo mantener una dirección estable de las dependencias de los módulos.
• ¿Qué debería conservarse en el proyecto anfitrión y qué no debería conservarse?

Porque los proyectos de tamaño mediano tienen más probabilidades de caer en una trampa: Parece que la modularización ha comenzado, pero en realidad es solo una redistribución de la complejidad del proyecto principal original a múltiples paquetes.

Entonces, de lo que quiero hablar en este artículo es de cómo juzgo los módulos, las jerarquías y los gráficos de dependencia.

1. No buscaré “más módulos” desde el principio, sino que primero buscaré “niveles claros”

La complejidad de los proyectos de tamaño mediano generalmente no es lo suficientemente grande como para requerir una subdivisión extrema, pero sí es suficiente para que “todo en el proyecto principal” comience a volverse peligroso.

Lo más importante en este momento es quitar primero las capas.

Por lo general, primero veo si las siguientes categorías de cosas se pueden separar de manera estable en el proyecto:

• Capa de habilidad básica
• Capa de capacidad de dominio
• Capa de reutilización de UI
• Capa de proyecto anfitrión

Una vez que estos cuatro tipos de cosas se mezclan, es fácil que el proyecto se salga de control tan pronto como aumenta la escala. Pero si primero se establece la jerarquía, el número de módulos será un detalle posterior.

2. Primero dividiré los módulos principales en tres categorías.

1. Módulo de habilidades básicas

Por ejemplo:

• red
• Iniciar sesión
• caché
• Lectura de configuración
• Herramientas básicas

Las características de este tipo de módulo son que está lejos del negocio, tiene una gran reutilización y la dirección de dependencia debe cerrarse lo más posible.

2. Módulo de capacidad de dominio

Por ejemplo:

-Cuenta

• Usuario
• Contenido
• Orden

Estos módulos son centros de capacidad empresarial. Deberían albergar modelos de dominio, almacenes y casos de uso, en lugar de implementaciones de páginas específicas.

3. Módulo de reutilización de UI

Por ejemplo:

• Sistema de diseño
• Componentes comunes
• Contenedor de lista universal

Seré muy cuidadoso aquí para evitar dividir accidentalmente la página comercial en módulos de interfaz de usuario. Los módulos de reutilización de UI son más adecuados para llevar capacidades de componentes estables, universales y entre páginas.

3. ¿Qué se debe conservar en el proyecto anfitrión?

Este es un tema que muchos equipos tienden a pasar por alto.

Una vez que empiezas a hacer SPM, es fácil tener una tendencia: “Dado que todos son modulares, es mejor que el proyecto anfitrión sea lo más delgado posible”.

Esta afirmación es sólo una verdad a medias.

El proyecto anfitrión realmente no debería tener demasiadas capacidades reutilizables, pero aún así debería conservar algunas cosas que naturalmente pertenecen al anfitrión, como por ejemplo:

• Orquestación del ciclo de vida de la aplicación.
• Montaje de enrutamiento
• Inyección de configuración del entorno.
• Montaje del módulo
• Códigos relacionados con la forma del producto final.

En otras palabras, el proyecto anfitrión debería centrarse en el ensamblaje y la colaboración a nivel de producto, en lugar de incluir un montón de capacidades que podrían haberse hundido.

4. No lo desmantelaré demasiado al principio.

Esto es algo en lo que insisto mucho.

Uno de los escollos en los que es más probable que caigan los proyectos de tamaño medio es el de la “modularización por la modularidad”, que acaba desgarrando demasiado el sistema.

Una vez que el módulo esté demasiado fragmentado, los problemas aparecerán inmediatamente:

• Gráfico de dependencia complejo
• La ruta de depuración se vuelve más larga.
• Saltos frecuentes entre módulos durante la revisión
• Un pequeño cambio implica múltiples enlaces de paquetes.

Esto puede llevar rápidamente a los equipos a dudar de la propia modularidad.

Entonces prefiero:

• Primero desmantelar algunos módulos grandes con responsabilidades claras.
• observar varias iteraciones
• Decidir si refinar

La elección muy fina del sistema la primera vez suele hacerse con prisas.

5. La dirección de la dependencia es más importante que la cantidad de módulos

Si me pidieran que eligiera entre “eliminar más módulos” y “rectificar las dependencias”, definitivamente elegiría lo último.

Porque más módulos no equivalen automáticamente a una mejor estructura. Lo que realmente determina si el sistema puede evolucionar de manera estable a largo plazo es si la dirección de la dependencia es clara.

Por ejemplo, me importa más si estas relaciones se mantienen:

-La capa base no depende de la capa empresarial

• La capa de dominio no depende de la capa de host a la inversa.
• La capa de reutilización de la interfaz de usuario no roba la semántica empresarial de la página.
• La capa de host es responsable del ensamblaje, en lugar de tener toda la implementación interna en sus manos.

Mientras las direcciones de dependencia estén desordenadas y no importa cuántos módulos haya, el sistema solo será un “acoplamiento anidado de múltiples capas”.

6. Seré muy cauteloso con los “módulos públicos universales”

Este es un antipatrón que aparece con frecuencia en proyectos de tamaño mediano.

Cuando un proyecto se modulariza al principio, a menudo habrá una pregunta llamada:

• Common
• Shared
• Core
• Base

Súper módulos como este.

Si este módulo tiene capacidades básicas claras, entonces no hay problema. Pero los “módulos públicos” de muchos proyectos acabarán convirtiéndose en:

• Se puede confiar en cualquier lugar
• Pon todo ahí
• Hay funciones de herramienta, modelos de negocio y componentes de interfaz de usuario.

El resultado es que se convierte en el nuevo punto central de acoplamiento.

Por eso prefiero dividirlo en pequeños módulos básicos con responsabilidades claras, en lugar de construir un módulo público grande que cubra todo.

7. Lo más importante para la modularización de proyectos de tamaño mediano es la cognición consistente del equipo.

Esto es muy realista.

En proyectos de tamaño mediano, muchos problemas estructurales se deben a que el equipo no tiene una comprensión consistente de los límites. Por ejemplo, algunas personas piensan:

• Todo lo relacionado con la página se considera un módulo.

Algunas personas piensan:

• Los modelos de dominio deben desmontarse por separado.

Algunas personas piensan:

• Los componentes públicos deben colocarse junto con los módulos comerciales para mayor comodidad.

Si estas cogniciones no se unifican durante mucho tiempo, el sistema seguirá generando conflictos de límites incluso con SPM.

Por eso, en proyectos de tamaño mediano, daré gran importancia a:

• ¿Es coherente la denominación de las responsabilidades de los módulos?
• ¿Existe consenso sobre la dirección de la dependencia?
• Al agregar código nuevo, ¿puedes decir en qué capa se debe colocar?

Esto es mucho más importante que simplemente “cuántos paquetes se abrieron”.

8. Conclusión: El núcleo del uso de SPM para gestionar proyectos de tamaño mediano no es la cantidad, sino la estabilidad a largo plazo del gráfico de dependencia.

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

Cuando se utiliza SPM para administrar un proyecto iOS de tamaño mediano, lo más importante es formar una dirección de dependencia estable a largo plazo entre las capacidades básicas, las capacidades de dominio, la reutilización de la interfaz de usuario y el ensamblaje del host.

Al hacer esto, el número de módulos encontrará naturalmente el tamaño correcto. Si no puede hacer esto, no importa cuánto lo divida, simplemente volverá a dividir la complejidad.