Swift Package Manager Série 06｜Cenários aplicáveis ​​e limitações do SPM

Uma vez alcançado um consenso na comunidade técnica, surge facilmente outro problema: Todos começaram a optar por “já que a direção é certa, então devemos fazer tudo o mais rápido possível”.

É fácil para o SPM entrar nesse ritmo também.

Na verdade, é uma ferramenta muito importante para projetos Swift modernos, mas “importante” não significa “deve ser totalmente promovido imediatamente e em todos os momentos”. Só porque as ferramentas são avançadas não significa que o projeto atual já tenha os limites e as condições organizacionais para realizá-lo.

Então, eu nunca gosto desse tipo de conclusão geral:

• “É hora de passar tudo para SPM”
• “Se você não usar SPM, ficará para trás.”

Uma questão mais prática deveria ser:

Se o projeto é atualmente adequado para migrar determinados recursos para o SPM e se será mais estável após a conclusão da migração.

1. O pré-requisito para ser adequado ao SPM é que os limites tenham começado a ficar claros.

Se um projeto estiver atualmente neste estado:

• Todo o código é altamente acoplado em um destino de aplicativo
• Páginas, serviços, roteamento e configurações podem penetrar uns nos outros
• As fronteiras entre capacidades públicas e capacidades empresariais são confusas

Se você correr para o SPM neste momento, provavelmente apenas moverá o acoplamento existente intacto para vários pacotes.

Parece modular superficialmente, mas na verdade as dependências são mais difíceis de entender e mais dolorosas de mudar.

Então a ordem que prefiro é:

1. Deixe os limites ficarem claros primeiro
2. Reutilize o SPM para hospedar esses limites

Em vez do contrário, espere que o SPM ajude automaticamente a criar limites.

2. Qual é o melhor momento para começar a usar o SPM?

Geralmente considero os seguintes sinais de que um projeto está pronto para introduzir ou expandir o SPM:

• Existem módulos claros de capacidade pública que podem ser independentes
• A equipe começou a ter uma noção de limites, em vez de apenas dividir o código por diretório
• Certas capacidades merecem testes independentes e evolução independente
• O projeto principal incorreu em custos de manutenção significativos devido à expansão
• A equipe está disposta a arcar com custos adicionais de design para limites de módulos

Se estas condições surgirem gradualmente, o SPM muitas vezes torna-se o próximo passo natural.

3. Quando não é apropriado “se forçar”?

“Fortalecimento” aqui refere-se ao avanço do SPM como missão política.

Eu seria muito cauteloso nas seguintes situações:

1. O projeto ainda é muito pequeno e o principal problema não são os limites do módulo.

Se o projeto atual tiver apenas algumas pessoas, for de pequena escala e tiver limites relativamente simples, o problema principal poderá não ser modular.

A introdução de vários pacotes muito cedo neste momento pode trazer mais complexidade do que benefícios.

2. A equipe não tem consenso básico sobre limites.

Se você estiver conectado agora:

• Como distinguir a camada básica e a camada de negócios
• Como distinguir a camada de página e a camada de serviço
• Como distinguir módulos públicos e módulos host

Se ainda não houver consenso, a SPM apenas exporá antecipadamente essas disputas, mas poderá não resolvê-las.

3. Apenas para “parecer avançado”

Este é o tipo de motivação mais perigoso. Se o motivo para adotar o SPM for apenas:

• Todo mundo está usando
• O diagrama de arquitetura ficará melhor
• Visual mais moderno no currículo

Há uma grande probabilidade de que eventualmente se torne uma “forma atualizada, estrutura inalterada”.

4. O aspecto mais facilmente superestimado do SPM: pensar que ele trará automaticamente uma boa arquitetura

Não vai.

Os pontos fortes do SPM são:

• Limites do módulo de hospedagem
• Dependências explícitas
• Torne a evolução do módulo mais natural

Mas não vai responder pela equipe:

• Qual módulo merece existir
• Como projetar dependendo da direção
• O piso público é sorteado muito cedo?
• Em primeiro lugar, determinados códigos comerciais não deveriam ser independentes?

Dito isto, o SPM é mais uma boa base do que um arquiteto. Sem conhecimento do projeto, uma estrutura complexa ainda será construída, mesmo que a fundação seja substituída.

5. A estratégia de migração é mais importante do que “você deve migrar ou não?”

Muitos projetos falharam devido a “mudanças demasiado drásticas na lei”.

Uma estratégia de migração mais estável é geralmente:

• Comece a pilotar os módulos com os limites mais claros primeiro
• Faça primeiro um pequeno número de divisões de alta certeza
• Execute várias iterações para verificar dependências e custos de colaboração
• Decida se deseja continuar a expandir

Em vez de apenas aparecer:

• Desempacotamento completo do armazém
• Todo o código público é forçado no pacote
• Migre todas as dependências de terceiros de uma só vez

A modularização é um projeto de longo prazo e não é adequada para avanço em uma única etapa.

6. Um critério de julgamento prático: depois de usar o SPM, o projeto ficará mais claro ou mais complicado?

Se uma alteração for feita após a migração:

• A direção da dependência é mais clara -As responsabilidades do módulo são mais claras
• É mais fácil avaliar o escopo do impacto durante a revisão
• Os limites dos testes são mais naturais

Então esta migração provavelmente valerá a pena.

Se após a conclusão da migração:

• Existem mais módulos mas as responsabilidades não são mais claras
• O projeto anfitrião ainda conhece várias implementações internas
• Alterar uma função requer alternar entre vários pacotes

Isso significa que o problema não é a ferramenta, mas o próprio design dos limites.

7. Conclusão: vale a pena usar SPM, mas não vale a pena usá-lo como uma migração formalista

Para resumir, eu diria:

Quando usar o SPM, a chave não é “se é a direção certa”, mas “se o projeto e a equipe estão atualmente prontos para usar os limites do módulo para transportar a complexidade”.

Portanto, a abordagem realmente estável é:

• Use-o na hora certa
• Comece com limites apropriados
• Utilizado para transportar estruturas claramente pensadas

Desta forma, o SPM se tornará uma ferramenta de redução de encargos, em vez de uma nova rodada de encargos de engenharia.