Swift Package Manager Series 01 ｜ El posicionamiento y la importancia de SPM

La primera vez que muchos desarrolladores de iOS realmente entran en contacto con Swift Package Manager es a menudo porque “quieren conectar una biblioteca de terceros”. Es fácil sacar una conclusión demasiado estrecha:

¿No es SPM solo un reemplazo de CocoaPods?

Esta conclusión es sólo parcialmente correcta.

SPM ciertamente puede instalar dependencias, pero si solo lo entiende como un administrador de dependencias, subestimará lo que realmente cambia. En realidad, lo que está cambiando es cómo los proyectos Swift definen los módulos, cómo organizan las dependencias y cómo establecen los límites del proyecto.

Entonces, en este artículo primero quiero dejar clara una premisa: ** El valor de SPM no es solo “obtener el código de manera más conveniente”, sino “organizar el código de manera más estándar”. **

1. SPM es, ante todo, la entrada oficial al sistema de módulos de Swift, no solo un descargador.

El valor central de muchas herramientas proviene de la ecología, y el valor central de algunas herramientas proviene de “si es un camino oficial”.

SPM está más cerca de este último.

Su importancia surge en primer lugar de tres hechos:

• Es la solución de modularización y gestión de paquetes con soporte oficial de Swift.
• Está integrado con la dirección de evolución del compilador, la cadena de herramientas y Xcode.
• No solo administra código de terceros, sino que, naturalmente, también admite la administración de su propio código.

Estos tres puntos en conjunto significan que gradualmente se está convirtiendo en el lenguaje predeterminado para las organizaciones de ingeniería Swift.

Este no es un cambio de la misma magnitud que “un comando más para instalar dependencias”.

2. Lo que realmente encuentra es el problema de los “límites”

Lo realmente difícil de gestionar en un proyecto maduro son siempre las siguientes cuestiones:

• ¿Qué código debe separarse en módulos?
• ¿De qué capacidades debería depender directamente el proyecto anfitrión?
• Qué módulos pueden hacer referencia entre sí y cuáles no deben ser referenciados
• ¿Dónde está el límite entre las capacidades públicas y las capacidades empresariales?

Una vez que SPM ingresa al proyecto, estas cuestiones se vuelven más específicas. Porque ya no se trata simplemente de “dividir directorios en carpetas”, sino de definir:

• ¿Qué es la interfaz pública de un módulo?
• De qué módulos depende
• ¿Quién confía en ello?
• Cómo se debe probar

Por lo tanto, digo que el núcleo de SPM es obligarnos a pensar más seriamente en los límites de los módulos.

Razones de la mayor importancia

Muchos proyectos pequeños pueden sobrevivir bien con “una aplicación objetivo + varios grupos” al principio. Pero en cuanto el proyecto alcance una escala media, empezarán a aparecer problemas:

• La velocidad de compilación es cada vez más lenta.
• Las capacidades públicas y el código comercial se mezclan
• La dirección de dependencia del módulo no está controlada
• Un cambio provocará la recompilación de una gran cantidad de código irrelevante
• Es difícil saber qué código es realmente reutilizable.

En este momento, encontrará que el problema es “el límite del proyecto no existe”.

SPM se está volviendo cada vez más importante porque proporciona una ruta más estándar que “continuar acumulando directorios en el proyecto principal”. Permite que los límites de los módulos cambien de una convención a una estructura de ingeniería real.

4. La mayor diferencia entre SPM y las herramientas de dependencia de la antigua era no es solo la experiencia, sino el posicionamiento de roles.

En el pasado, era común tener expectativas simples sobre las herramientas de gestión de dependencias:

• Ayúdame a instalar la biblioteca de terceros.
• Ayúdame con versiones e integraciones.

Pero SPM pronto lo llevará a otro nivel: No sólo gestiona “bibliotecas escritas por otros”, sino que también es muy adecuado para gestionar “módulos extraídos por uno mismo”.

Este cambio es muy crítico. Porque una vez que comienzas a organizar tu código en Paquetes, la función de SPM cambia de “instalador” a “sistema de módulos”.

En este momento, las cuestiones que preocupan ya no son sólo:

• ¿Se puede instalar?

En lugar de eso:

• Cómo definir la interfaz del módulo
• Cómo ocultar la implementación interna
• Cómo mantener las dependencias unidireccionales
• Qué módulos merecen pruebas independientes

Aquí es donde la madurez de la ingeniería comienza a aumentar.

5. Muchos equipos llegarán a SPM tarde o temprano

En la superficie parece que está “actualizado”, pero en realidad se acerca más a cómo se organizan los proyectos Swift modernos.

Siempre que un equipo empiece a hacer estas cosas en serio, naturalmente se acercará más a la GDS:

• Quiere hacer una división del módulo más clara
• Quiere extraer capacidades públicas.
• Quiere reducir la expansión excesiva del proyecto principal.
• Quiere hacer explícitas las dependencias.
• Quiere que las pruebas de módulos sean más naturales.

En otras palabras, en el proceso de buscar los límites de la ingeniería, muchos equipos finalmente descubrieron que SPM es la forma más conveniente de realizar tareas.

6. Pero su valor no está en “se vuelve avanzado cuando se usa”, sino en “los límites finalmente se pueden definir en serio”

Aquí se debe evitar otro malentendido: Cuando se menciona el tema de GDS, es fácil equipararlo con “equipo modular maduro”.

En realidad, esto no es exacto.

La GDS por sí sola no conduce automáticamente a una buena estructura. Si no lo has pensado claramente en primer lugar:

• ¿Por qué existe este módulo?
• Qué expone y qué no.
• ¿Cuál es su relación con el proyecto anfitrión?

Eso simplemente movió el desorden original del directorio principal del proyecto al directorio del paquete.

Por lo tanto, el valor de la GDS no radica en “hacerla moderna”, sino en que hace que muchas cuestiones de límites que podrían haber sido vagas en el pasado finalmente ya no puedan serlo.

7. No resolverá nada automáticamente

Esto también es importante. SPM no ayuda automáticamente a resolver:

• ¿Es razonable el desmontaje del módulo?
• ¿Está claro el nombre?
• Dependencia de si la dirección es saludable.
• ¿Se ha elaborado un determinado módulo público demasiado pronto?
• ¿Están mezcladas la capa empresarial y la capa básica?

Dicho esto, SPM no es un arquitecto, es simplemente una herramienta más adecuada para albergar una buena arquitectura.

Si, para empezar, el equipo no tiene conciencia de los límites, la SPM puede terminar simplemente presentando el problema de una manera más “moderna”.

8. Conclusión: La GDS es cada vez más importante. En la superficie, parece que puede instalar bibliotecas, pero en realidad está más cerca y es más adecuado para alojar proyectos modulares.

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

La razón por la que SPM se está volviendo cada vez más importante es que en la superficie parece que finalmente nos permite instalar un CocoaPods menos. De hecho, está más cerca de facilitar que los proyectos Swift conviertan los límites de los módulos, las dependencias y las estructuras del proyecto en diseños explícitos.

Entonces, lo realmente importante nunca es solo la “gestión de la dependencia”, sino:

• Modulares
• Estandarización
• Hacer explícitos los límites

Por eso merece cada vez más ser tomado en serio.