Swift Package Manager Series 05 ｜ Acceso y gestión de paquetes de terceros en proyectos de iOS

Cuando se habla de gestión de dependencia de terceros en este tipo de cuestiones, la atención se centra más en:

• ¿Se puede acceder a esta biblioteca a través de SPM?
• ¿Xcode puede reconocerlo?
• Cómo escribir el número de versión.

Por supuesto, estos son importantes, pero en proyectos reales, el costo real suele ser de varios años después de su instalación.

Porque una vez que las dependencias de terceros ingresen al proyecto, traerán toda una serie de problemas a largo plazo:

• Cómo controlar el ritmo de actualización.
• ¿Qué módulos se verán afectados por los cambios de API?
• Si la biblioteca específica está expuesta directamente al código comercial
• Una vez que desee reemplazar la biblioteca, ¿el costo será alto?

Así pues, la verdadera dificultad a la hora de “gestionar paquetes de terceros” es la gobernanza.

1. Antes de aceptar dependencias de terceros, lo primero que debe preguntarse es “¿Entrará en el límite central?”

Antes de agregar una biblioteca a un proyecto, lo primero que suelo preguntar no es:

• ¿Cuántas estrellas hay?
• ¿Es bonito el documento?

En lugar de eso:

• ¿Irá directamente a una gran cantidad de código comercial?
• ¿Definirá algún tipo de forma de interfaz para nosotros en el futuro?
• ¿Qué impacto tendrá una vez que se actualice o reemplace?

Debido a que algunas bibliotecas solo tienen capacidades periféricas, como herramientas de depuración, backends de registro y dispositivos de un solo uso; Algunas bibliotecas ingresarán directamente al núcleo del sistema, como la capa de red, la capa de imagen, la capa de enrutamiento y la capa de almacenamiento.

Una vez que este último se selecciona incorrectamente, los costos de modificación posteriores serán muy altos.

Por eso me preocupa más si ingresa a la “capa de borde” o a la “capa de columna vertebral”.

2. No permita que el código comercial conozca directamente demasiados detalles de la biblioteca de terceros

Esta es la experiencia que más fácilmente se pasa por alto, pero también la más crítica.

Supongamos que se utiliza una biblioteca de carga de imágenes y su API está en todas partes del proyecto:

• Ver capa importa directamente
• ViewModel también conoce su tipo
• La capa de herramientas también depende de ello.

Entonces esta biblioteca pronto pasará de “dependencia” a “parte de la infraestructura”. Si desea actualizarlo o reemplazarlo en el futuro, el costo será mucho mayor de lo esperado.

Entonces, un enfoque más estable suele ser:

• Envuelva su propia abstracción alrededor de límites apropiados
• Deje que la empresa dependa de la interfaz de capacidades en lugar de la biblioteca misma

Esto no significa que cualquier biblioteca de terceros deba estar completamente empaquetada, pero al menos para aquellas dependencias que profundizan en la capa troncal principal, se debe considerar seriamente el aislamiento.

3. SPM facilita el acceso, pero también puede hacer que “agregar una dependencia” sea demasiado frívolo.

Este es un efecto secundario muy real.

Debido a que el acceso a SPM es tan fácil, muchos equipos desarrollarán lentamente este hábito:

• Vi una pequeña necesidad
• Buscar una biblioteca
• agregar
• Es sólo un paquete de todos modos.

Es muy eficiente a corto plazo, pero a largo plazo se irán acumulando problemas:

• Expansión de la dependencia
• La cadena de compilación se hace más larga.
• Algunas bibliotecas no han recibido mantenimiento durante mucho tiempo.
• Múltiples funciones de biblioteca se superponen
• Hay muchas dependencias en el proyecto que “nadie puede explicar el motivo de su existencia”

Por lo tanto, la GDS hace que la gestión de la dependencia sea más ligera, pero la ligereza no significa que los estándares de gobernanza deban relajarse. Cuanto más ligera sea la herramienta, más control humano se requiere.

4. El núcleo de la gestión de versiones radica en si la estrategia de actualización es clara

Cuando supe por primera vez este contenido sobre la versión SPM, primero presté atención a:

• Versión exacta
• versión de alcance
• hasta el siguiente mayor

Es necesario conocer estas reglas, pero las cuestiones de ingeniería más importantes son en realidad:

• ¿Quién es responsable de mejorar esta dependencia?
• Con qué frecuencia revisar las versiones
• ¿La actualización debería adaptarse a las necesidades empresariales o gestionarse periódicamente?
• Cómo evaluar rápidamente el impacto cuando falla una actualización

Si nadie es responsable de estas cosas, no importa cuán bellamente escrita esté la restricción de versión, solo se convertirá en un “valor fijo que no ha cambiado en varios años”.

Por lo tanto, depender de la gestión de versiones es esencialmente una cuestión de ritmo de gobernanza.

5. Lo más aterrador de la dependencia de terceros es “nadie lo verá después de ingresar al sistema”

Todo el mundo se tomaba muy en serio muchas dependencias el día en que fueron introducidas, pero nadie se ocupó de ellas después de eso. Esto conlleva varios riesgos típicos:

• Las actualizaciones de seguridad llevan mucho tiempo rezagadas.
• La acumulación de cambios de API explota en una actualización
• Nadie en el equipo sabe quién más confía en esta biblioteca.
• Bibliotecas de habilidades similares se superponen continuamente

Entonces el proyecto entrará lentamente en un estado:

• Las dependencias no son inutilizables.
• Pero nadie se atreve a moverse.

Esto es más común y más difícil de solucionar que “elegir la biblioteca equivocada en primer lugar”.

6. Lo que valoro más es si la lista de dependencias es “explicable”

Una lista de dependencias de proyectos saludable no es necesariamente corta, pero preferiblemente explicable.

En otras palabras, al recoger una dependencia, el equipo puede indicar claramente:

• ¿Qué problema resuelve?
• ¿es así?
• En qué piso se encuentra
• Si existen fronteras de aislamiento.
• Si es necesario reemplazarlo en el futuro, ¿cuál será el costo principal?

Si una dependencia se ha convertido en:

• “Ha estado allí antes”
• “Parece que se usa en alguna parte”
• “Borralo por miedo a que pase algo”

Entonces ha entrado en una zona de gobernanza fuera de control.

7. Una estrategia práctica: tratar las dependencias de terceros en capas

Normalmente divido las dependencias en tres categorías:

1. Dependencia marginal

Por ejemplo, algunas ayudas al desarrollo, informes de registros y herramientas de baja frecuencia. Incluso si este tipo de dependencia se utiliza más directamente, los riesgos son relativamente controlables.

2. Dependencia de la plataforma

Por ejemplo, imágenes, red, almacenamiento, enrutamiento, etc. Es probable que este tipo de dependencia ingrese al tronco del sistema y el alcance de la exposición debe controlarse cuidadosamente.

3. Dependencias profundamente acopladas con reemplazabilidad débil

Una vez que algunas bibliotecas estén conectadas, afectarán a una gran cantidad de diseños de API. Este tipo de dependencia requiere límites claros al principio; de lo contrario, el coste de reposición será muy alto en el futuro.

Este enfoque en capas es más realista que “todos lo usan directamente” o “una capa incluye todos”.

8. Conclusión: El núcleo del paquete de terceros es la gobernanza a largo plazo

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

Al gestionar paquetes de terceros en un proyecto de iOS, lo que realmente importa es “después de que ingresan al sistema, ¿puedes controlar sus límites, el ritmo de actualización y los costos de reemplazo?”

Por tanto, la gestión de la dependencia es una capacidad de gobernanza a largo plazo.