Método de gerenciamento Swift Package Manager Series 07｜SPM em projetos iOS de médio porte

Se eu fosse usar o SPM para gerenciar um projeto iOS de médio porte, minha primeira preocupação não seria “quantos pacotes remover”, mas estas três questões:

• Quais habilidades são realmente dignas de independência?
• Como manter a direção estável das dependências do módulo
• O que deve ser retido no projeto anfitrião e o que não deve ser retido?

Porque os projetos de médio porte têm maior probabilidade de cair em uma armadilha: Parece que a modularização começou, mas na verdade é apenas uma redistribuição da complexidade do projeto principal original para vários pacotes.

Então, o que quero falar neste artigo é como julgo módulos, hierarquias e gráficos de dependência.

1. Não buscarei “mais módulos” desde o início, mas primeiro buscarei “níveis claros”

A complexidade dos projetos de médio porte geralmente não é grande o suficiente para exigir subdivisões extremas, mas é suficiente para que “tudo no projeto principal” comece a se tornar perigoso.

O mais importante neste momento é remover primeiro as camadas.

Normalmente vejo primeiro se as seguintes categorias de coisas podem ser separadas de forma estável no projeto:

• Camada de habilidade básica
• Camada de capacidade de domínio
• Camada de reutilização da UI
• Camada do projeto host

Uma vez misturados esses quatro tipos de coisas, é fácil para o projeto sair do controle assim que a escala aumenta. Mas se a hierarquia for estabelecida primeiro, o número de módulos será um detalhe posterior.

2. Primeiro dividirei os módulos principais em três categorias.

1. Módulo de habilidade básica

Por exemplo:

• rede
• Registro
• cache
• Leitura de configuração
• Ferramentas básicas

As características desse tipo de módulo são que ele fica distante do negócio, tem forte capacidade de reutilização e a direção de dependência deve ser fechada o máximo possível.

2. Módulo de capacidade de domínio

Por exemplo:

-Conta

• Usuário
• Conteúdo
• Pedido

Esses módulos são centros de capacidade de negócios. Eles devem hospedar modelos de domínio, armazéns e casos de uso, em vez de implementações de páginas específicas.

3. Módulo de reutilização da UI

Por exemplo:

• Sistema de projeto
• Componentes comuns
• Recipiente de lista universal

Terei muito cuidado aqui para evitar dividir acidentalmente a página comercial em módulos de UI. Os módulos de reutilização da UI são mais adequados para transportar recursos de componentes estáveis, universais e de páginas cruzadas.

3. O que deve ser mantido no projeto hospedeiro?

Este é um problema que muitas equipes tendem a ignorar.

Depois que você começa a fazer SPM, é fácil ter uma tendência: “Como são todos modulares, é melhor que o projeto hospedeiro seja o mais fino possível.”

Esta afirmação é apenas parcialmente verdadeira.

O projeto host realmente não deve conter muitos recursos reutilizáveis, mas ainda deve reter algumas coisas que pertencem naturalmente ao host, como:

• Orquestração do ciclo de vida do aplicativo
• Montagem de roteamento
• Injeção de configuração de ambiente
• Montagem do módulo
• Códigos relativos à forma do produto final

Em outras palavras, o projeto anfitrião deve se concentrar na montagem e na colaboração em nível de produto, em vez de carregar um monte de capacidades que poderiam ter sido perdidas.

4. Não vou desmontá-lo muito bem no início.

Isso é algo em que insisto muito.

Uma das armadilhas em que os projetos de médio porte têm maior probabilidade de cair é a “modularização pela modularidade”, que acaba destruindo demais o sistema.

Quando o módulo estiver muito fragmentado, os problemas aparecerão imediatamente:

• Gráfico de dependência complexo
• O caminho de depuração fica mais longo
• Saltos frequentes entre módulos durante a revisão
• Uma pequena mudança envolve múltiplas ligações de pacotes

Isso pode rapidamente levar as equipes a duvidar da própria modularidade.

Então eu prefiro:

• Primeiro desmonte alguns módulos grandes com responsabilidades claras
• observe várias iterações
• Decida se deseja refinar

A escolha muito precisa do sistema na primeira vez geralmente é feita às pressas.

5. A direção da dependência é mais importante que o número de módulos

Se me pedissem para escolher entre “remover mais módulos” e “corrigir as dependências”, eu definitivamente escolheria a última opção.

Porque mais módulos não significam automaticamente uma estrutura melhor. O que realmente determina se o sistema pode evoluir de forma estável a longo prazo é se a direcção da dependência é clara.

Por exemplo, me preocupo mais se esses relacionamentos se mantêm:

-A camada base não depende da camada de negócios

• A camada de domínio não depende da camada host ao contrário
• A camada de reutilização da UI não rouba a semântica comercial da página
• A camada host é responsável pela montagem, ao invés de manter toda a implementação interna em suas mãos

Enquanto as direções de dependência estiverem confusas e não importa quantos módulos existam, o sistema será apenas um “acoplamento aninhado multicamadas”.

6. Serei muito cauteloso com “módulos públicos universais”

Este é um antipadrão que aparece frequentemente em projetos de médio porte.

Quando um projeto é modularizado no início, muitas vezes surgirá uma pergunta chamada:

-Common -Shared -Core -Base

Super módulos como este.

Se este módulo possuir recursos básicos claros, não haverá problema. Mas os “módulos públicos” em muitos projetos acabarão por se tornar:

• Pode ser confiável em qualquer lugar
• Coloque tudo lá
• Existem funções de ferramentas, modelos de negócios e componentes de UI

O resultado é que ele se torna o novo ponto central de acoplamento.

Então prefiro dividi-lo em pequenos módulos básicos com responsabilidades claras, em vez de construir um grande módulo público que cubra tudo.

7. O mais importante para a modularização de projetos de médio porte é a cognição consistente da equipe.

Isto é muito realista.

Em projetos de médio porte, muitos problemas estruturais são causados ​​pelo fato de a equipe não ter uma compreensão consistente dos limites. Por exemplo, algumas pessoas pensam:

• Tudo relacionado à página é considerado um módulo

Algumas pessoas pensam:

• Os modelos de domínio devem ser desmontados separadamente

Algumas pessoas pensam:

• Componentes públicos devem ser colocados juntos com módulos de negócios para maior comodidade

Se essas cognições não forem unificadas por um longo período, o sistema continuará a aumentar os conflitos de limites mesmo com o SPM.

Portanto, em projetos de médio porte, darei grande importância a:

• A nomenclatura das responsabilidades do módulo é consistente?
• Existe um consenso sobre a direção da dependência?
• Ao adicionar um novo código, você consegue dizer em qual camada ele deve ser colocado?

Isto é muito mais importante do que simplesmente “quantos pacotes foram abertos”.

8. Conclusão: O cerne do uso do SPM para gerenciar projetos de médio porte não é a quantidade, mas a estabilidade de longo prazo do gráfico de dependência.

Para resumir, eu diria:

Ao usar o SPM para gerenciar um projeto iOS de médio porte, o mais importante é formar uma direção de dependência estável de longo prazo entre recursos básicos, recursos de domínio, reutilização de UI e montagem de host.

Ao fazer isso, o número de módulos encontrará naturalmente o tamanho certo. Se você não puder fazer isso, não importa o quanto você divida, isso apenas reduzirá a complexidade.