Swift Package Manager Série 05｜Acesso e gerenciamento de pacotes de terceiros em projetos iOS

Ao falar sobre gerenciamento de dependências de terceiros nessas questões, o foco é mais avançado:

• Esta biblioteca pode ser acessada através do SPM?
• O Xcode pode reconhecê-lo?
• Como escrever o número da versão

É claro que estes são importantes, mas em projetos reais, o custo real geralmente ocorre vários anos após a instalação.

Porque uma vez que as dependências de terceiros entrem no projeto, isso trará uma série de problemas de longo prazo:

• Como controlar o ritmo de atualização
• Quais módulos serão afetados pelas alterações da API?
• Se a biblioteca específica está diretamente exposta ao código comercial
• Uma vez que você queira substituir a biblioteca, o custo será alto?

Portanto, a verdadeira dificuldade em “gerir pacotes de terceiros” é a governação.

1. Antes de aceitar dependências de terceiros, a primeira coisa a perguntar é “Será que isso entrará no limite principal?”

Antes de uma biblioteca ser adicionada a um projeto, a primeira coisa que costumo perguntar não é:

• Quantas estrelas existem?
• O documento é lindo?

Em vez disso:

• Irá diretamente para muitos códigos de negócios?
• Isso definirá algum tipo de formato de interface para nós no futuro?
• Qual será o impacto que terá quando for atualizado ou substituído?

Como algumas bibliotecas possuem apenas recursos periféricos, como ferramentas de depuração, back-ends de registro e gadgets únicos; Algumas bibliotecas entrarão diretamente no núcleo do sistema, como a camada de rede, a camada de imagem, a camada de roteamento e a camada de armazenamento.

Uma vez que este último seja selecionado incorretamente, os custos de modificação subsequentes serão muito elevados.

Portanto, estou mais preocupado se ele entra na “camada de borda” ou na “camada de backbone”.

2. Não deixe o código comercial saber diretamente muitos detalhes da biblioteca de terceiros

Esta é a experiência mais facilmente esquecida, mas a mais crítica.

Suponha que uma biblioteca de carregamento de imagens seja usada e sua API esteja em todo o projeto:

• Ver importações de camadas diretamente
• ViewModel também conhece seu tipo
• A camada da ferramenta também depende disso

Então esta biblioteca em breve mudará de “dependência” para “parte da infraestrutura”. Se você quiser atualizá-lo ou substituí-lo no futuro, o custo será muito maior do que o esperado.

Portanto, uma abordagem mais estável é geralmente:

• Envolva sua própria abstração em torno de limites apropriados
• Deixe a empresa confiar na interface de capacidade em vez da biblioteca em si

Isso não significa que qualquer biblioteca de terceiros deva ser totalmente empacotada, mas pelo menos para as dependências que vão fundo na camada principal do tronco, o isolamento deve ser seriamente considerado.

3. O SPM facilita o acesso, mas também pode facilmente tornar “adicionar uma dependência” muito frívolo.

Este é um efeito colateral muito real.

Como o acesso ao SPM é tão fácil, muitas equipes desenvolverão lentamente este hábito:

• Vi uma pequena necessidade
• Pesquise uma biblioteca
• adicionar
• É apenas um pacote de qualquer maneira

É muito eficiente no curto prazo, mas os problemas a longo prazo irão acumular-se gradualmente:

• Expansão de dependência
• A cadeia de compilação torna-se mais longa
• Algumas bibliotecas não são mantidas há muito tempo
• Várias funções de biblioteca se sobrepõem
• Existem muitas dependências no projeto que “ninguém consegue explicar o motivo da existência”

Portanto, o SPM torna a gestão de dependências mais leve, mas leveza não significa que os padrões de governação devam ser relaxados. Quanto mais leve for a ferramenta, mais controle humano será necessário.

4. O núcleo do gerenciamento de versões reside em saber se a estratégia de atualização é clara

Quando aprendi este conteúdo sobre a versão SPM, primeiro prestei atenção em:

• Versão exata
• versão do escopo
• upToNextMajor

Essas regras precisam ser conhecidas, mas as questões de engenharia mais importantes são, na verdade:

• Quem é responsável pela atualização desta dependência?
• Com que frequência revisar versões
• A atualização deve seguir as necessidades do negócio ou ser gerenciada regularmente?
• Como avaliar rapidamente o impacto quando uma atualização falha

Se ninguém for responsável por essas coisas, não importa quão bem escrita seja a restrição de versão, ela se tornará apenas um “valor fixo que não foi alterado por vários anos”.

Portanto, confiar no gerenciamento de versões é essencialmente uma questão de ritmo de governança.

5. O que há de mais temível na dependência de terceiros é “ninguém vai olhar para isso depois de entrar no sistema”

Todos levaram muitas dependências muito a sério no dia em que foram introduzidas, mas ninguém cuidou delas depois disso. Isso traz vários riscos típicos:

• As atualizações de segurança estão atrasadas há muito tempo
• O backlog de alterações da API explode em uma atualização
• Ninguém na equipe sabe quem mais depende desta biblioteca
• Bibliotecas de habilidades semelhantes são continuamente sobrepostas

Então o projeto entrará lentamente em um estado:

• Dependências não são inutilizáveis
• Mas ninguém se atreve a se mover

Isso é mais comum e mais difícil de lidar do que “escolher a biblioteca errada em primeiro lugar”.

6. O que mais valorizo ​​é se a lista de dependências é “explicável”

Uma lista saudável de dependências de projetos não é necessariamente curta, mas preferencialmente explicável.

Ou seja, ao escolher uma dependência, a equipe pode afirmar claramente:

• Que problema isso resolve?
• é isso
• Em que andar está localizado
• Se existem fronteiras de isolamento
• Caso seja necessário substituí-lo no futuro, qual será o principal custo?

Se uma dependência se tornou:

• “Já esteve lá antes”
• “Parece ser usado em algum lugar”
• “Exclua por medo de que algo aconteça”

Então entrou efectivamente numa zona de governação fora de controlo.

7. Uma estratégia prática: trate dependências de terceiros em camadas

Normalmente divido as dependências em três categorias:

1. Dependência marginal

Por exemplo, alguns auxílios ao desenvolvimento, relatórios de log e ferramentas de baixa frequência. Mesmo que este tipo de dependência seja utilizado de forma mais direta, os riscos são relativamente controláveis.

2. Dependência de plataforma

Por exemplo, imagens, rede, armazenamento, roteamento, etc. É provável que esse tipo de dependência entre no tronco do sistema e o escopo da exposição deve ser cuidadosamente controlado.

3. Dependências profundamente acopladas com fraca capacidade de substituição

Depois que algumas bibliotecas estiverem conectadas, elas afetarão um grande número de designs de API. Este tipo de dependência requer limites claros no início, caso contrário o custo de substituição será muito elevado no futuro.

Essa abordagem em camadas é mais realista do que “todos usam diretamente” ou “uma camada está incluída”.

8. Conclusão: O núcleo do pacote de terceiros é a governança de longo prazo

Para resumir, eu diria:

Ao gerenciar pacotes de terceiros em um projeto iOS, o que realmente importa é “depois que ele entra no sistema, você consegue controlar seus limites, ritmo de atualização e custos de substituição?”

Portanto, a gestão de dependências é uma capacidade de governação a longo prazo.