Swift Package Manager Série 04｜Limites de código adequados para inclusão em pacotes

Um dos erros mais comuns que muitas equipes cometem quando começam a modularizar é:

Primeiro decida remover o módulo e depois pense por que o módulo existe.

Portanto, o resultado final geralmente é “copiar o acoplamento original para mais diretórios”. Superficialmente, existem mais módulos, mas na verdade as dependências não mudaram e são ainda mais confusas.

Então, o que quero falar neste artigo é: que tipo de código é adequado para ser colocado no pacote e quais são os erros de julgamento estruturais mais comuns durante a divisão.

1. Para determinar se deve ser dividido, não observe primeiro o número de arquivos, mas primeiro verifique se os limites existem naturalmente.

Se vale a pena retirar um módulo depende se ele tem limites naturais.

Os chamados limites naturais geralmente se refletem em:

• Assume um conjunto relativamente único de responsabilidades
• Sua direção de dependência é relativamente clara
• Não é necessário saber muito sobre o contexto do projeto anfitrião
• É provável que seja reutilizado em vários cenários no futuro

Se essas condições não forem atendidas, só porque “esta pasta está um pouco grande agora”, é provável que ela seja separada apenas para continuar o acoplamento em outro local.

O primeiro princípio da modularidade é “o limite já existe, apenas o deixo explícito”.

2. Os que são menos adequados para remoção no primeiro lote geralmente são grandes blocos de negócios fortemente acoplados à página.

Quando comecei a fazer isso, quando estava fazendo modularização, as coisas que fiquei mais tentado a desmontar foram:

• Página inicial
• Central de contas
• Processo de pagamento
• Detalhes do conteúdo

É claro que esses módulos são importantes, mas muitas vezes também estão profundamente associados a estas coisas:

• Roteamento -Ciclo de vida do aplicativo host
• Status da página
• enterre o ponto
• Recursos de interface do usuário

Se você começar a partir desses locais para a primeira divisão, os limites não serão claros e é fácil aparecer:

• O próprio módulo também precisa contar com o host ao contrário
• Para compartilhar algo, vários pacotes fazem referência uns aos outros
• A camada pública está poluída pela camada de negócios

Portanto, o que é mais adequado para demolição pela primeira vez geralmente é o “bloco com limite mais claro”.

3. O código adequado para inclusão no pacote geralmente possui três formas típicas:

1. Módulo de habilidade básica

Por exemplo:

• Registro
• Encapsulamento de rede
• cache local
• Leitura de configuração

Os recursos comuns desses recursos são responsabilidades claras, independência de página e grande espaço de reutilização.

2. Modelo de domínio ou módulo de serviço de domínio

Por exemplo:

• Modelo de usuário e consulta de informações do usuário
• Objetos de domínio de conteúdo e armazém de conteúdo
• Lógica de campo de pedido

Este tipo de módulo é mais voltado para os negócios, mas desde que os limites sejam claros, também é adequado para o desenvolvimento de pacotes.

3. Módulo de componente básico de UI estável

Por exemplo:

• Componentes básicos do sistema de design
• Sistema de estilo universal
• Diversos componentes interativos sem acoplamento de negócios

A premissa é que eles sejam realmente estáveis e não roubem a semântica específica da página.

4. Um mal-entendido muito comum: divisão por diretório em vez de por direção de dependência

Muitas equipes falham na modularização. Superficialmente, parece que há muito pouca desmontagem, mas na verdade está mais próximo do método de desmontagem errado.

As perguntas mais típicas são: Como antigamente dividia pastas agora é como dividir módulos.

Por exemplo:

-Home/ -User/ -Common/ -Utils/

Superficialmente parece um módulo, mas na verdade você encontrará em breve:

• Home depende de User
• User depende de Common
• Common na verdade contém um monte de lógica de negócios misturada
• Utils No final, virou uma lata de lixo com tudo enfiado dentro.

Isso mostra que o que está sendo dividido é o diretório, não o limite.

Um método de desmontagem verdadeiramente mais estável deve ser visto do ponto de vista da dependência:

• Quais módulos só podem ser confiáveis para baixo
• Quais capacidades o público está subjacente
• Quais são as camadas da área de negócio?
• Quais são exclusivos da camada host?

Somente quando a direção da dependência for clara primeiro, a divisão do módulo será estável a longo prazo.

5. Não esconda dependências para modularidade

Quando alguns projetos desmontam módulos, para evitar dependências circulares, eles passam a utilizar vários métodos de compromisso:

• Módulos públicos extra grandes
• Faça acordos em todos os lugares
• Coloque uma “camada de ponte” no meio

Essas técnicas não são impossíveis de usar, mas se forem apenas para “fazer o diagrama do módulo parecer bom”, é fácil ocultar o acoplamento real em vez de resolvê-lo.

Então, o que mais me importa é:

• Se a atual relação de dependência é comercialmente razoável
• Os módulos estão separados devido a diferentes responsabilidades reais?
• Ou é apenas para contornar as limitações da ferramenta?

Modularidade realmente saudável ocorre quando o acoplamento é claramente colocado na direção certa.

6. Um julgamento prático: Se este módulo for retirado, o projeto anfitrião ainda o compreenderá?

Esta é uma forma muito comum de me julgar.

Se você retirar um módulo candidato, pergunte-se:

• O entendimento do projeto anfitrião ainda está claro?
• O chamador externo só precisa conhecer a interface sem conhecer muitos detalhes internos? -Se ainda é um conceito completo depois de deixar o host

Se a resposta for “sim”, geralmente é mais adequado como pacote. Se a resposta for “não”, provavelmente ainda são apenas alguns detalhes de implementação dentro do host.

7. Ao desmontar pela primeira vez, é melhor desmontar menos do que desmontar em pedaços.

Ao fazer a modularização pela primeira vez, é fácil cair no impulso de “Agora que começamos a desmontar, vamos desmontar mais”. Mas uma das falhas mais comuns em projetos de médio porte é que os módulos estão muito fragmentados.

Quando o módulo estiver muito fragmentado, o custo aumentará rapidamente:

• O gráfico de dependência é mais complexo
• As relações de compilação são mais difíceis de entender
• O gerenciamento de versões e limites é mais problemático
• Ao revisar, você precisa alternar entre vários módulos

Então, ao dividir pela primeira vez, prefiro:

• Primeiro remova alguns módulos com limites claros
• observe várias iterações
• Decida se deseja continuar o refinamento

O maior medo da modularidade é que o primeiro passo seja quebrar o sistema em muitas pequenas peças que parecem independentes, mas na verdade estão interligadas umas com as outras.

8. Conclusão: O que é adequado para inclusão no Pacote é “habilidade com limites claros”

Para resumir, eu diria:

A chave para julgar se um trecho de código é adequado para inclusão em um Pacote não é quantos arquivos ele possui, mas se ele possui limites de responsabilidade relativamente claros, direções de dependência e semântica independente.

Então o que realmente importa é:

• desmontar
• De acordo com que limite?
• A direção da dependência fica mais clara após a desmontagem?

Somente se essas três coisas forem estabelecidas antecipadamente, a modularização poderá realmente reduzir a complexidade, em vez de reorganizá-la.