Swift Package Manager Series 06 ｜ Escenarios aplicables y limitaciones de SPM

Una vez que se alcanza un consenso en la comunidad técnica, fácilmente surge otro problema: Todos comenzaron a decir por defecto “ya que la dirección es correcta, entonces deberíamos hacer todo lo posible lo antes posible”.

También es fácil que SPM caiga en este ritmo.

De hecho, es una herramienta muy importante para los proyectos Swift modernos, pero “importante” no significa “debe promocionarse por completo de inmediato en todo momento”. El hecho de que las herramientas sean avanzadas no significa que el proyecto actual ya tenga los límites y las condiciones organizativas para emprenderlo.

Así que nunca me gusta ese tipo de conclusión general:

• “Es hora de pasar todo a SPM”
• “Si no utilizas SPM, te quedarás atrás”.

Una pregunta más práctica debería ser:

Si el proyecto es actualmente adecuado para migrar ciertas capacidades a SPM y si será más estable una vez completada la migración.

1. El requisito previo para ser adecuado para la GDS es que los límites hayan comenzado a ser claros.

Si un proyecto se encuentra actualmente en este estado:

• Todo el código está altamente acoplado en un objetivo de aplicación.
• Las páginas, los servicios, el enrutamiento y las configuraciones pueden penetrarse entre sí.
• Los límites entre capacidades públicas y capacidades empresariales son confusos.

Si se apresura a utilizar SPM en este momento, probablemente simplemente moverá el acoplamiento existente intacto a varios paquetes.

Parece modular en la superficie, pero en realidad las dependencias son más difíciles de entender y más dolorosas de cambiar.

Entonces el orden que prefiero es:

1. Primero, deje que los límites se aclaren
2. Reutilizar SPM para albergar estos límites

En lugar de lo contrario, espere que la GDS ayude automáticamente a crear límites.

2. ¿Cuándo es el mejor momento para empezar a utilizar SPM?

Generalmente considero las siguientes señales de que un proyecto está listo para introducir o expandir la GDS:

• Hay módulos de capacidad pública claros que pueden ser independientes.
• El equipo ha comenzado a tener una sensación de límites, en lugar de simplemente dividir el código por directorio.
• Ciertas capacidades merecen pruebas independientes y una evolución independiente.
• El proyecto principal ha incurrido en importantes costes de mantenimiento debido a la ampliación.
• El equipo está dispuesto a asumir costos de diseño adicionales para los límites de los módulos.

Si estas condiciones surgen gradualmente, la GDS a menudo se convierte en el siguiente paso natural.

3. ¿Cuándo no es apropiado “forzarse”?

“Fortalecer” aquí se refiere a promover la GDS como misión política.

Sería muy cauteloso en las siguientes situaciones:

1. El proyecto aún es muy pequeño y el principal problema no son los límites del módulo en absoluto.

Si el proyecto actual sólo cuenta con unas pocas personas, es de pequeña escala y tiene límites relativamente simples, es posible que el problema principal no sea modular en absoluto.

Introducir un montón de Paquetes demasiado pronto en este momento puede traer mayor complejidad que beneficios.

2. El equipo no tiene un consenso básico sobre los límites.

Si estás conectado ahora:

• Cómo distinguir la capa básica y la capa empresarial.
• Cómo distinguir la capa de página y la capa de servicio
• Cómo distinguir módulos públicos y módulos host

Si aún no hay consenso, SPM sólo expondrá estas disputas por adelantado, pero es posible que no las resuelva.

3. Sólo para “parecer avanzado”

Este es el tipo de motivación más peligroso. Si el motivo para adoptar GDS es simplemente:

• Todos los demás lo están usando.
• El diagrama de arquitectura se verá mejor.
• Aspecto más moderno en el currículum.

Existe una alta probabilidad de que eventualmente se convierta en una “forma mejorada, estructura sin cambios”.

4. El aspecto más fácilmente sobreestimado de SPM: pensar que automáticamente generará una buena arquitectura

No lo hará.

Los puntos fuertes de la GDS son:

• Límites del módulo de hosting
• Dependencias explícitas
• Hacer que la evolución del módulo sea más natural.

Pero no responderá por el equipo:

• ¿Qué módulo merece existir?
• Cómo diseñar dependiendo de la dirección.
• ¿El piso público se sortea demasiado pronto?
• ¿Ciertos códigos comerciales no deberían ser independientes en primer lugar?

Dicho esto, SPM es más una buena base que un arquitecto. Sin conciencia de diseño, se seguirá construyendo una estructura compleja incluso si se reemplazan los cimientos.

5. La estrategia de migración es más importante que “¿deberías migrar o no?”

Muchos proyectos han fracasado debido a “cambios legislativos demasiado drásticos”.

Una estrategia de migración más estable suele ser:

• Comience a probar los módulos con los límites más claros primero
• Primero haga una pequeña cantidad de divisiones de alta certeza
• Ejecutar varias iteraciones para verificar dependencias y costos de colaboración.
• Decidir si continuar expandiéndonos

En lugar de simplemente aparecer:

• Desembalaje completo del almacén.
• Todo el código público se fuerza en el paquete.
• Migrar todas las dependencias de terceros a la vez

La modularización es un proyecto a largo plazo y no es adecuado para un avance de un solo paso.

6. Un criterio de juicio práctico: después de usar SPM, ¿el proyecto será más claro o más complicado?

Si se realiza un cambio después de la migración:

• La dirección de dependencia es más clara. -Las responsabilidades del módulo son más claras.
• Es más fácil juzgar el alcance del impacto durante la revisión.
• Los límites de las pruebas son más naturales.

Entonces lo más probable es que esta migración valga la pena.

Si una vez completada la migración:

• Hay más módulos pero las responsabilidades no están más claras.
• El proyecto anfitrión todavía conoce un montón de implementaciones internas.
• Cambiar una función requiere saltar de un lado a otro entre varios paquetes

Eso significa que el problema no es la herramienta, sino el diseño de límites en sí.

7. Conclusión: Vale la pena utilizar SPM, pero no como migración formalista

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

Cuándo usar SPM, la clave no es “si es la dirección correcta”, sino “si el proyecto y el equipo están actualmente listos para usar los límites de los módulos para llevar la complejidad”.

Entonces el enfoque realmente estable es:

• Úsalo en el momento adecuado.
• Comience con límites apropiados
• Se utiliza para transportar estructuras claramente pensadas.

De esta manera, la SPM se convertirá en una herramienta de reducción de cargas en lugar de una nueva ronda de cargas de ingeniería.