Swift Package Manager Series 04 ｜ Límites de código adecuados para su inclusión en paquetes

Uno de los errores más comunes que cometen muchos equipos cuando comienzan a realizar la modularización es:

Primero decida eliminar el módulo y luego piense por qué existe el módulo.

Entonces, el resultado final suele ser “copiar el acoplamiento original a más directorios”. En la superficie, hay más módulos, pero en realidad las dependencias no han cambiado y son aún más confusas.

Entonces, de lo que quiero hablar en este artículo es: qué tipo de código es adecuado para colocar en el paquete y cuáles son los errores estructurales más comunes al dividir.

1. Para determinar si se debe dividir, no mire primero la cantidad de archivos, sino primero si los límites existen naturalmente.

Si vale la pena eliminar un módulo depende de si tiene límites naturales.

Los llamados límites naturales suelen reflejarse en:

• Asume un conjunto relativamente único de responsabilidades.
• Su dirección de dependencia es relativamente clara.
• No es necesario saber mucho sobre el contexto del proyecto anfitrión.
• Es probable que se reutilice en múltiples escenarios en el futuro.

Si no se cumplen estas condiciones, simplemente porque “esta carpeta es un poco grande ahora”, es probable que se separe para continuar acoplando en otro lugar.

El primer principio de modularidad es “el límite ya existe, simplemente lo hago explícito”.

2. Los que son menos adecuados para eliminar en el primer lote suelen ser grandes bloques comerciales que están fuertemente acoplados con la página.

Cuando comencé a hacer esto por primera vez, cuando estaba modularizando, las cosas que más me sentí tentado a desmantelar fueron:

• Página de inicio
• Centro de cuentas
• Proceso de pago
• Detalles del contenido

Por supuesto, estos módulos son importantes, pero a menudo también están profundamente relacionados con estas cosas:

• Enrutamiento -Ciclo de vida de la aplicación host
• Estado de la página
• enterrar el punto
• Recursos de interfaz de usuario

Si comienza desde estos lugares para la primera división, los límites no serán claros y es fácil que aparezcan:

• El módulo en sí también necesita depender del host a la inversa.
• Para compartir algo, varios paquetes hacen referencia entre sí.
• La capa pública está contaminada por la capa empresarial.

Por tanto, lo que es más adecuado para la demolición por primera vez suele ser el “bloque con el límite más claro”.

3. El código adecuado para su inclusión en el paquete suele tener tres formas típicas:

1. Módulo de habilidades básicas

Por ejemplo:

• Iniciar sesión
• Encapsulación de red
• caché local
• Lectura de configuración

Las características comunes de estas capacidades son responsabilidades claras, independencia de página y un gran espacio de reutilización.

2. Modelo de dominio o módulo de servicio de dominio

Por ejemplo:

• Modelo de usuario y consulta de información del usuario.
• Objetos de dominio de contenido y almacén de contenido.
• Lógica del campo de orden

Este tipo de módulo está más orientado a los negocios, pero siempre que los límites sean claros, también es adecuado para el desarrollo de paquetes.

3. Módulo de componente básico de UI estable

Por ejemplo:

• Diseño de componentes básicos del sistema.
• Sistema de estilo universal
• Varios componentes interactivos sin acoplamiento empresarial.

La premisa es que son realmente estables y no roban la semántica específica de la página.

4. Un malentendido muy común: dividir por directorio en lugar de por dirección de dependencia

Muchos equipos fracasan en la modularización. En la superficie, parece que hay muy poco desmantelamiento, pero en realidad está más cerca del método de desmantelamiento incorrecto.

Las preguntas más típicas son: Cómo dividir carpetas en el pasado ahora es cómo dividir módulos.

Por ejemplo:

• Home/
• User/
• Common/
• Utils/

A primera vista parece un módulo, pero en realidad pronto encontrarás:

• Home depende de User
• User depende de Common
• Common en realidad contiene un montón de lógica de negocios mezclada
• Utils Al final, se convirtió en un cubo de basura con todo lo que había dentro.

Esto muestra que lo que se está dividiendo es el directorio, no el límite.

Un método de desmontaje verdaderamente más estable debe verse desde el punto de vista de la dependencia:

• ¿En qué módulos solo se puede confiar hacia abajo?
• ¿Qué capacidades son las subyacentes al público?
• ¿Cuáles son las capas del área de negocio?
• ¿Cuáles son exclusivos de la capa huésped?

Sólo cuando la dirección de la dependencia sea clara primero, la división del módulo será estable a largo plazo.

5. No ocultes las dependencias por modularidad

Cuando algunos proyectos desmantelan módulos, para evitar dependencias circulares, comienzan a utilizar varios métodos de compromiso:

• Módulos públicos extra grandes.
• Dibujar acuerdos en todas partes.
• Poner una “capa puente” en el medio.

Estas técnicas no son imposibles de usar, pero si son sólo para “hacer que el diagrama del módulo se vea bien”, es fácil ocultar el acoplamiento real en lugar de resolverlo.

Entonces lo que más me importa es:

• Si la relación de dependencia actual es razonable desde el punto de vista comercial.
• ¿Los módulos están separados debido a diferentes responsabilidades reales?
• ¿O es simplemente para eludir las limitaciones de la herramienta?

La modularidad realmente saludable es cuando el acoplamiento se coloca claramente en la dirección correcta.

6. Un juicio práctico: si se elimina este módulo, ¿el proyecto anfitrión aún lo entenderá?

Ésta es una forma muy común de juzgarme a mí mismo.

Si saca un módulo candidato, pregúntese:

• ¿Está todavía claro el entendimiento del proyecto anfitrión al respecto?
• ¿La persona que llama externamente sólo necesita conocer la interfaz sin conocer muchos detalles internos? -Si sigue siendo un concepto completo después de dejar el anfitrión.

Si la respuesta es “sí”, entonces suele ser más adecuado como Paquete. Si la respuesta es “no”, probablemente todavía sean solo un montón de detalles de implementación dentro del host.

7. Al desmontar por primera vez, es mejor desmontar menos que desmontarlo en pedazos.

Al realizar la modularización por primera vez, es fácil caer en el impulso de “Ahora que hemos empezado a desmantelarlo, desmantelémoslo más”. Pero uno de los fallos más comunes en proyectos de tamaño mediano es que los módulos están demasiado fragmentados.

Una vez que el módulo está demasiado fragmentado, el costo aumentará rápidamente:

• El gráfico de dependencia es más complejo.
• Las relaciones de compilación son más difíciles de entender.
• La gestión de versiones y límites es más problemática.
• Al revisar, debes saltar hacia adelante y hacia atrás a través de muchos módulos.

Entonces, cuando divido por primera vez, prefiero:

• Primero elimine algunos módulos con límites claros.
• observar varias iteraciones
• Decidir si continuar con el refinamiento

El mayor temor a la modularidad es que el primer paso es dividir el sistema en muchas piezas pequeñas que parecen independientes pero que en realidad están entrelazadas entre sí.

8. Conclusión: Lo que es adecuado para incluir en el Paquete es “capacidad con límites claros”

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

La clave para juzgar si un fragmento de código es adecuado para su inclusión en un Paquete no es cuántos archivos tiene, sino si tiene límites de responsabilidad relativamente claros, direcciones de dependencia y semántica independiente.

Entonces lo que realmente importa es:

• desmantelar
• ¿Según qué límite?
• ¿La dirección de dependencia es más clara después del desmontaje?

Sólo si estas tres cosas se establecen de antemano, la modularización realmente puede reducir la complejidad, en lugar de reorganizarla.