Swift Package Manager Série 01｜O posicionamento e a importância do SPM

A primeira vez que muitos desenvolvedores iOS realmente entram em contato com o Swift Package Manager é porque “querem conectar uma biblioteca de terceiros”. É fácil tirar uma conclusão excessivamente estreita:

O SPM não é apenas um substituto para o CocoaPods?

Esta conclusão está apenas parcialmente correta.

O SPM certamente pode instalar dependências, mas se você o entender apenas como um gerenciador de dependências, subestimará o que ele realmente muda. O que está mudando é como os projetos Swift definem os módulos, como eles organizam as dependências e como estabelecem os limites do projeto.

Portanto, neste artigo quero deixar clara uma premissa primeiro: **O valor do SPM não é apenas “obter o código de forma mais conveniente”, mas “organizar o código de forma mais padronizada”. **

1. SPM é antes de tudo a entrada oficial do sistema de módulo do Swift, não apenas um downloader.

O valor central de muitas ferramentas vem da ecologia, e o valor central de algumas ferramentas vem de “se é um caminho oficial”.

O SPM está mais próximo deste último.

A sua importância decorre primeiro de três factos:

• É a solução de modularização e gerenciamento de pacotes com suporte oficial da Swift
• Está integrado com a direção de evolução do compilador, cadeia de ferramentas e Xcode
• Ele não apenas gerencia código de terceiros, mas também suporta naturalmente o gerenciamento de seu próprio código

Esses três pontos juntos significam que ela está gradualmente se tornando a linguagem padrão para organizações de engenharia Swift.

Esta não é uma mudança da mesma magnitude de “mais um comando para instalar dependências”.

2. O que realmente encontra é o problema do “limite”

O que é realmente difícil de gerenciar em um projeto maduro são sempre as seguintes questões:

• Qual código deve ser separado em módulos
• De quais capacidades o projeto anfitrião deve depender diretamente?
• Quais módulos podem fazer referência entre si e quais não devem ser referenciados
• Onde está a fronteira entre as capacidades públicas e as capacidades empresariais?

Depois que o SPM entra no projeto, essas questões tornam-se mais específicas. Porque não se trata mais apenas de “dividir diretórios em pastas”, mas sim definir:

• Qual é a interface pública de um módulo?
• De quais módulos depende
• Quem confia nisso
• Como deve ser testado

Portanto, digo que o núcleo do SPM é nos forçar a pensar mais seriamente sobre os limites dos módulos.

Razões para aumentar a importância

Muitos projetos pequenos podem sobreviver bem com “um alvo de aplicativo + vários grupos” no início. Mas assim que o projeto atingir a escala média, os problemas começarão a aparecer:

• A velocidade de compilação está ficando cada vez mais lenta
• Capacidades públicas e código comercial são misturados
• A direção da dependência do módulo não é controlada
• Uma alteração irá desencadear a recompilação de uma grande quantidade de código irrelevante
• É difícil dizer qual código é realmente reutilizável

Neste momento, você descobrirá que o problema é “o limite do projeto não existe”.

O SPM está se tornando cada vez mais importante porque fornece um caminho mais padrão do que “continuar empilhando diretórios no projeto principal”. Ele permite que os limites do módulo mudem de uma convenção para uma estrutura de engenharia real.

4. A maior diferença entre o SPM e as ferramentas de dependência da velha era não é apenas a experiência, mas o posicionamento da função

No passado, era comum ter expectativas simples em relação às ferramentas de gerenciamento de dependências:

• Ajude-me a instalar a biblioteca de terceiros
• Ajude-me com versões e integrações

Mas o SPM em breve levará isso a outro nível: Não só gere “bibliotecas escritas por terceiros”, mas também é muito adequado para gerir “módulos retirados por si mesmo”.

Essa mudança é muito crítica. Porque assim que você começar a organizar seu código em Pacotes, a função do SPM muda de “instalador” para “sistema de módulo”.

Neste momento, as questões preocupantes já não são apenas:

• Pode ser instalado?

Em vez disso:

• Como definir a interface do módulo
• Como ocultar a implementação interna
• Como manter dependências unilaterais
• Quais módulos merecem testes independentes

É aqui que a maturidade da engenharia começa a aumentar.

5. Muitas equipes chegarão ao SPM mais cedo ou mais tarde

Superficialmente parece que está “atualizado”, mas na realidade está mais próximo de como os projetos modernos do Swift são organizados.

Contanto que uma equipe comece a fazer essas coisas com seriedade, naturalmente se aproximará do SPM:

• Quer fazer uma divisão de módulo mais clara
• Quer extrair capacidades públicas
• Quer reduzir a expansão excessiva do projeto principal
• Quer tornar as dependências explícitas
• Quer tornar o teste de módulo mais natural

Em outras palavras, no processo de busca dos limites da engenharia, muitas equipes finalmente descobriram que o SPM é a maneira mais conveniente de realizar tarefas.

6. Mas seu valor não está em “torna-se avançado quando usado”, mas em “os limites podem finalmente ser definidos seriamente”

Outro mal-entendido deve ser evitado aqui: Quando o tema SPM é mencionado, é fácil equipará-lo a “equipe modular madura”.

Na verdade, isso não é exato.

O SPM por si só não leva automaticamente a uma boa estrutura. Se você ainda não pensou claramente sobre isso:

• Por que este módulo existe?
• O que expõe e o que não expõe
• Qual é a sua relação com o projeto anfitrião?

Isso apenas moveu a bagunça original do diretório principal do projeto para o diretório Package.

Portanto, o valor do SPM não reside em “torná-lo moderno”, mas em fazer com que muitas questões de limites que poderiam ter sido vagas no passado finalmente não possam mais ser vagas.

7. Não resolverá nada automaticamente

Isto também é importante. O SPM não ajuda a resolver automaticamente:

• A desmontagem do módulo é razoável?
• A nomenclatura está clara?
• Dependência se a direção é saudável
• Algum módulo público foi sorteado muito cedo?
• A camada de negócios e a camada básica estão misturadas?

Dito isto, o SPM não é um arquiteto, é apenas uma ferramenta mais adequada para hospedar uma boa arquitetura.

Se a equipe não tiver consciência dos limites para começar, o SPM pode acabar apenas empacotando o problema de uma forma mais “moderna”.

8. Conclusão: o SPM está se tornando cada vez mais importante. Superficialmente parece que pode instalar bibliotecas, mas na verdade está mais próximo disso e é mais adequado para hospedar projetos modulares.

Para resumir, eu diria:

A razão pela qual o SPM está se tornando cada vez mais importante é que superficialmente parece que ele finalmente nos permite instalar um CocoaPods a menos. Na verdade, está mais perto de tornar mais fácil para os projetos Swift transformar limites de módulos, dependências e estruturas de projetos em designs explícitos.

Portanto, o que é realmente importante nunca é apenas “gerenciamento de dependências”, mas:

• Modular
• Padronização
• Torne os limites explícitos

É por isso que cada vez mais merece ser levado a sério.