Swift Package Manager Series 02 ｜ Cree el primer paquete Swift

Muchos tutoriales que hablan sobre “crear su primer paquete Swift” se centran en comandos o acciones de Xcode.

Por supuesto, es necesario conocer estos pasos. Pero si solo sabe cómo hacer clic en “Nuevo paquete”, en realidad solo ha aprendido a “generar una plantilla” y no ha comprendido realmente la importancia de ingeniería de crear un paquete.

Como era la primera vez que creé mi propio paquete Swift, lo que realmente empezó a cambiar fue la forma en que lo pensaba:

• ¿Es digno de ser separado este código en un módulo? -¿Qué interfaz debería exponer este módulo?
• Qué detalles de implementación deben ocultarse
• ¿De quién depende y en quién se debe confiar?

Entonces, de lo que quiero hablar en este artículo es de qué criterios se deben tomar al crear un paquete por primera vez.

1. No se apresure a crear el paquete primero. Primero pregunte si este código debería continuar en el proyecto principal.

Este es el paso que más me importa.

Una situación común es decir: “Vamos a modularizarlo”. Pero lo que realmente vale la pena preguntar es:

¿Por qué este código debería separarse del contexto actual del proyecto y convertirse en un módulo independiente?

Las razones legítimas comunes incluyen:

• Será reutilizado por múltiples objetivos o múltiples módulos comerciales.
• Ha formado una capacidad de campo relativamente estable.
• Ya no debería depender de los detalles de la página o del proyecto anfitrión.
• Merece límites de prueba separados

Si no puede nombrar ninguna de estas razones y simplemente “siente que hay demasiados archivos”, probablemente aún no sea el momento de crear un paquete.

El paquete no se usa para almacenar archivos, se usa para expresar límites.

2. Lo más adecuado para extraer por primera vez suelen ser pequeñas habilidades con límites claros.

Si un equipo es nuevo en SPM, normalmente no recomiendo derribarlo como primer paso:

• Página de inicio completa
• Todo el sistema de cuentas
• Módulo de pago completo

Debido a que estos módulos a menudo están profundamente acoplados con el proyecto anfitrión, la capa de página, la capa de enrutamiento y la capa de estado, una vez que los límites no están claramente diseñados, la primera división se frustrará fácilmente.

Los que son más adecuados para el primer lote de Paquetes suelen tener estas capacidades:

-Capacidades básicas de la capa de red.

• Registro, monitoreo y empaquetado de puntos ocultos.
• Herramientas de procesamiento de imágenes o almacenamiento en caché.
• Una biblioteca de modelos de dominio clara
• Un conjunto de componentes básicos de UI relativamente estables.

Las características comunes de estos módulos son:

• Menos dependencia
• Responsabilidad única
• Los límites son relativamente claros.

Son más adecuados para ayudar al equipo a establecer una idea de “qué es un módulo independiente”.

3. Al crear un Paquete por primera vez, lo más crítico es la interfaz pública

Una situación común es que después de crear el primer paquete, inmediatamente se concentrará en cómo organizar el directorio. Pero desde una perspectiva de ingeniería, lo que es realmente más importante es:

• ¿Qué expone el módulo al mundo exterior?
• Lo que se guarda dentro del módulo

Puedes pensar en crear un paquete como un autocontrol:

• ¿Qué tipos realmente vale la pena exponer como public?
• ¿Qué funciones de utilidad deberían permanecer solo internas?
• Qué dependencias no deben ser conocidas por la persona que llama

Si simplemente mueve todo el proyecto principal original a un paquete y luego lo cambia a public, en realidad no formará un límite.

Por lo tanto, al crear un Paquete por primera vez, la práctica que más vale la pena es “definir la interfaz”.

4. Uno de los malentendidos más comunes: primero cree el paquete y luego piense en las responsabilidades del módulo

Es fácil equivocarse con esta secuencia.

El orden correcto normalmente debería ser:

1. Primero aclare las responsabilidades de esta habilidad.
2. Veamos si merece la pena ser un módulo independiente.
3. Finalmente hospedarlo en forma de Paquete

Si se invierte el orden, las consecuencias comunes son:

• Un Paquete quiere encargarse de todo
• Confusión de dependencia interna
• La interfaz externa es demasiado grande
• El proyecto anfitrión aún necesita conocer muchos detalles de implementación.

En otras palabras, SPM no puede diseñar módulos para el equipo, simplemente es más adecuado para transportar módulos que han sido claramente pensados.

5. Los cuatro temas que más me importan cuando creo un Paquete por primera vez

Si estoy revisando el primer paquete de un equipo, las cuatro preguntas que hago con más frecuencia son:

1. ¿Tiene este módulo una responsabilidad única y clara?

Si un módulo maneja la red, el caché, el estado de la página y los puntos enterrados al mismo tiempo, probablemente aún no esté claro.

2. Si sus dependencias son lo suficientemente pocas

Al crear un paquete por primera vez, cuantas menos dependencias, más fácil será tener éxito. Cuando hay demasiadas dependencias, los límites se vuelven borrosos.

3. ¿Su interfaz pública es mucho más pequeña que su implementación interna?

Si hay diez tipos en el módulo, ocho de ellos quedarán expuestos, lo que indica que el control de límites no es lo suficientemente bueno.

4. ¿Vale la pena realizar pruebas independientes?

Los módulos que merecen pruebas independientes suelen ser más dignos de existencia independiente. Si no puede descubrir cómo probarlo de forma aislada, probablemente todavía esté demasiado vinculado al contexto del host.

6. El criterio de éxito por primera vez es el “desmontaje estable”

Cuando muchos equipos realizan la modularización por primera vez, es más probable que persigan una “sensación de resultados”, como por ejemplo:

• Retire 10 módulos de una vez
• Todo el código público va al paquete.
• El proyecto principal perdió mucho peso inmediatamente.

Pero en proyectos reales, los criterios más importantes para el éxito a la primera suelen ser:

• Tener un módulo con límites claros.
• Las dependencias externas son saludables.
• El equipo entiende por qué se dividió así.
• No volvió rápidamente en las siguientes iteraciones.

Porque el mayor temor a la modularidad es que la confianza de todos en este asunto se pierda en el primer paso.

7. Conclusión: El primer paquete Swift realmente enseña cómo organizar el código según límites.

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

El verdadero significado de crear el primer paquete Swift es verse obligado a responder seriamente por primera vez “por qué este código merece ser un módulo independiente”.

Una vez que comienza a mirar el problema desde esta perspectiva, SPM ya no es solo “puedo usarlo”, sino que comienza a ingresar verdaderamente a la entrada del pensamiento de ingeniería modular.