Swift Package Manager Série 02 ｜ Crie o primeiro pacote Swift

Muitos tutoriais que falam sobre “criar seu primeiro pacote Swift” concentram-se em comandos ou ações do Xcode.

É claro que essas etapas precisam ser conhecidas. Mas se você souber apenas clicar em “Novo Pacote”, na verdade apenas aprendeu a “gerar um modelo” e não entendeu realmente o significado de engenharia de criar um Pacote.

Por ter sido a primeira vez que criei meu próprio pacote Swift, o que realmente começou a mudar foi a forma como pensei sobre isso:

• Esse código vale a pena ser separado em um módulo? -Qual interface este módulo deve expor?
• Quais detalhes de implementação devem ser ocultados
• De quem depende e em quem se deve confiar?

Então o que quero falar neste artigo é quais julgamentos devem ser tomados ao criar um Pacote pela primeira vez.

1. Não se apresse em construir o pacote primeiro. Primeiro pergunte se esse código deve continuar no projeto principal.

Esta é a etapa que mais me interessa.

Uma situação comum é dizer: “Vamos modularizar”. Mas o que realmente vale a pena perguntar é:

Por que este código deveria ser separado do contexto atual do projeto e se tornar um módulo independente?

Razões legítimas comuns incluem:

• Será reutilizado por vários alvos ou módulos de negócios
• Formou uma capacidade de campo relativamente estável
• Não deve mais depender dos detalhes da página ou do projeto host
• Merece limites de teste separados

Se você não consegue citar nenhum desses motivos e apenas “sente que há muitos arquivos”, provavelmente ainda não é hora de construir um pacote.

O pacote não é usado para armazenar arquivos, mas para expressar limites.

2. A coisa mais adequada para extrair pela primeira vez geralmente são pequenas habilidades com limites claros.

Se uma equipe é nova no SPM, geralmente não recomendo desmontá-la como primeira etapa:

• Página inicial inteira
• Todo o sistema de contas
• Módulo de pagamento completo

Como esses módulos geralmente estão profundamente acoplados ao projeto host, à camada de página, à camada de roteamento e à camada de estado, uma vez que os limites não sejam claramente projetados, a primeira divisão será facilmente frustrada.

Aqueles que são mais adequados para o primeiro lote de pacotes geralmente possuem estes recursos:

-Capacidades básicas da camada de rede

• Registro, monitoramento e empacotamento de pontos ocultos
• Ferramentas de processamento de imagens ou cache
• Uma biblioteca de modelos de domínio clara
• Um conjunto de componentes básicos de UI relativamente estáveis

Os recursos comuns desses módulos são:

• Menos dependência
• Responsabilidade única
• Os limites são relativamente claros

Eles são mais adequados para ajudar a equipe a estabelecer uma noção de “o que é um módulo independente”.

3. Ao criar um pacote pela primeira vez, o mais crítico é a interface pública

Uma situação comum é que após construir o primeiro pacote, você se concentre imediatamente em como organizar o diretório. Mas do ponto de vista da engenharia, o que é realmente mais importante é:

• O que o módulo expõe ao mundo exterior?
• O que é guardado dentro do módulo

Você pode pensar na criação de um Pacote como uma autocontenção:

• Quais tipos realmente valem a pena expor como public
• Quais funções utilitárias devem permanecer apenas internas
• Quais dependências não devem ser conhecidas pelo chamador

Se você simplesmente mover tudo no projeto principal original para um pacote e depois alterá-lo para public, isso não formará realmente um limite.

Portanto, ao fazer um Pacote pela primeira vez, a prática que mais vale a pena é “definir a interface”.

4. Um dos mal-entendidos mais comuns: primeiro crie o pacote e depois pense nas responsabilidades do módulo

É fácil errar com essa sequência.

A ordem correta geralmente deve ser:

1. Primeiro esclareça as responsabilidades desta habilidade
2. Vamos ver se vale a pena ser um módulo independente.
3. Finalmente hospede-o em formato de pacote

Se a ordem for invertida, as consequências comuns são:

• Um Pacote quer cuidar de tudo
• Confusão de dependência interna
• A interface externa é muito grande
• O projeto anfitrião ainda precisa saber muitos detalhes de implementação

Em outras palavras, o SPM não pode projetar módulos para a equipe, apenas é mais adequado para transportar módulos que foram claramente pensados.

5. As quatro questões que mais me preocupam ao criar um pacote pela primeira vez

Se estou revisando o primeiro pacote de uma equipe, as quatro perguntas que faço com mais frequência são:

1. Este módulo tem uma responsabilidade única e clara?

Se um módulo lida com rede, cache, status de página e pontos enterrados ao mesmo tempo, provavelmente ainda não está claro.

2. Se suas dependências são poucas o suficiente

Ao fazer um Pacote pela primeira vez, quanto menos dependências, mais fácil será o sucesso. Quando há muitas dependências, os limites ficam confusos.

3. Sua interface pública é muito menor que sua implementação interna?

Se houver dez tipos no módulo, oito deles serão expostos, indicando que o controle de limite não é bom o suficiente.

4. Vale a pena fazer testes independentes?

Módulos que merecem testes independentes são geralmente mais dignos de existência independente. Se você não consegue descobrir como testá-lo isoladamente, provavelmente ainda está muito ligado ao contexto do host.

6. O critério para o sucesso pela primeira vez é “desmontagem estável”

Quando muitas equipes fazem a modularização pela primeira vez, é mais provável que elas busquem uma “sensação de resultados”, como:

• Remova 10 módulos de uma só vez
• Todo o código público vai para o pacote
• O projeto principal perdeu muito peso imediatamente

Mas em projetos reais, os critérios mais importantes para o sucesso inicial são geralmente:

• Tenha um módulo com limites claros
• Dependências externas são saudáveis
• A equipe entende porque foi dividido assim
• Não voltou rapidamente nas próximas iterações

Porque o maior medo da modularidade é que a confiança de todos neste assunto se perca logo no primeiro passo.

7. Conclusão: O primeiro pacote Swift realmente ensina como organizar o código de acordo com os limites.

Para resumir, eu diria:

O verdadeiro significado de criar o primeiro pacote Swift é ser forçado a responder seriamente pela primeira vez “por que este código merece ser um módulo independente”.

Uma vez que você começa a olhar para o problema desta perspectiva, o SPM não é mais apenas “posso usá-lo”, mas começa a realmente entrar na entrada do pensamento de engenharia modular.