Swift Package Manager Series 01｜Le positionnement et l'importance de SPM

La première fois que de nombreux développeurs iOS entrent réellement en contact avec Swift Package Manager, c’est souvent parce qu’ils « souhaitent connecter une bibliothèque tierce ». Il est facile de tirer une conclusion trop étroite :

Le SPM ne remplace-t-il pas simplement les CocoaPods ?

Cette conclusion n’est que partiellement correcte.

SPM peut certes installer des dépendances, mais si vous le comprenez uniquement comme un gestionnaire de dépendances, vous sous-estimerez ce qu’il change réellement. Ce que cela change, c’est en fait la manière dont les projets Swift définissent les modules, comment ils organisent les dépendances et comment ils établissent les limites du projet.

Donc, dans cet article, je veux d’abord clarifier une prémisse : **La valeur de SPM n’est pas seulement « d’obtenir le code plus facilement », mais « d’organiser le code de manière plus standard ». **

1. SPM est avant tout l’entrée officielle du système de modules de Swift, pas seulement un téléchargeur.

La valeur fondamentale de nombreux outils vient de l’écologie, et la valeur fondamentale de certains outils vient de « s’il s’agit d’une voie officielle ».

SPM est plus proche de ce dernier.

Son importance tient d’abord à trois faits :

• Il s’agit de la solution de gestion de packages et de modularisation officiellement prise en charge par Swift.
• Il est intégré au sens d’évolution du compilateur, de la chaîne d’outils et de Xcode
• Il gère non seulement le code tiers, mais prend également naturellement en charge la gestion de votre propre code

Ces trois points réunis font qu’il devient progressivement le langage par défaut des organisations d’ingénierie Swift.

Ce n’est pas un changement de la même ampleur qu’« une commande de plus pour installer des dépendances ».

2. Ce qu’il rencontre réellement, c’est le problème des « limites »

Ce qui est vraiment difficile à gérer dans un projet mature, ce sont toujours les problématiques suivantes :

• Quel code doit être séparé en modules
• De quelles capacités le projet hôte devrait-il dépendre directement ?
• Quels modules peuvent se référencer les uns les autres et lesquels ne doivent pas être référencés
• Où se situe la frontière entre les capacités publiques et les capacités des entreprises ?

Une fois que SPM entre dans le projet, ces problématiques deviennent plus spécifiques. Car il ne s’agit plus seulement de « diviser les répertoires en dossiers », mais bien de définir :

• Quelle est l’interface publique d’un module ?
• De quels modules cela dépend
• Qui en dépend
• Comment il doit être testé

Par conséquent, je dis que le cœur de SPM est de nous forcer à réfléchir plus sérieusement aux limites des modules.

Raisons d’une importance accrue

De nombreux petits projets peuvent bien survivre avec « une cible d’application + un groupe de groupes » au début. Mais dès que le projet atteint une envergure moyenne, des problèmes commenceront à apparaître :

• La vitesse de compilation devient de plus en plus lente
• Les capacités publiques et le code des affaires sont mélangés
• La direction de dépendance du module n’est pas contrôlée
• Un changement déclenchera la recompilation d’une grande quantité de code non pertinent
• Difficile de dire quel code est réellement réutilisable

À ce stade, vous constaterez que le problème est que « les limites du projet n’existent pas ».

SPM devient de plus en plus important car il fournit un chemin plus standard que “continuer à empiler les répertoires dans le projet principal”. Il permet aux limites des modules de passer d’une convention à une véritable structure d’ingénierie.

4. La plus grande différence entre SPM et les outils de dépendance de l’ancienne époque n’est pas seulement l’expérience, mais aussi le positionnement du rôle

Dans le passé, il était courant d’avoir des attentes simples à l’égard des outils de gestion des dépendances :

• Help me install the third-party library
• Aidez-moi avec les versions et les intégrations

But SPM will soon take it to another level: Il gère non seulement les « bibliothèques écrites par d’autres », mais est également très adapté à la gestion des « modules souscrits par soi-même ».

Ce changement est très critique. Parce qu’une fois que vous commencez à organiser votre code en packages, le rôle de SPM passe de “installateur” à “système de modules”.

À l’heure actuelle, les sujets de préoccupation ne se limitent plus à :

• Peut-il être installé ?

Au lieu de cela :

• Comment définir l’interface du module
• Comment masquer l’implémentation interne
• Comment garder les dépendances à sens unique
• Quels modules méritent des tests indépendants

C’est là que la maturité de l’ingénierie commence à augmenter.

5. De nombreuses équipes atteindront SPM tôt ou tard

En apparence, cela semble “mis à jour”, mais en réalité, c’est plus proche de la façon dont les projets Swift modernes sont organisés.

Tant qu’une équipe commence à faire ces choses sérieusement, elle se rapprochera naturellement du SPM :

• Vous voulez faire une division de module plus claire
• Vous souhaitez extraire des capacités publiques
• Vous souhaitez réduire la surexpansion du projet principal
• Vous souhaitez rendre les dépendances explicites
• Want to make module testing more natural

En d’autres termes, en recherchant les limites de l’ingénierie, de nombreuses équipes ont finalement découvert que la SPM était le moyen le plus pratique d’effectuer des tâches.

6. Mais sa valeur n’est pas dans “il devient avancé lorsqu’il est utilisé”, mais dans “les limites peuvent enfin être définies sérieusement”

Un autre malentendu doit être évité ici : Lorsque le thème de la GPS est évoqué, il est facile de l’assimiler à « une équipe modulaire mature ».

This is actually not accurate.

La GPS en elle-même ne conduit pas automatiquement à une bonne structure. Si vous n’y avez pas réfléchi clairement dès le départ :

• Why does this module exist?
• What it exposes and what it doesn’t
• Quelle est sa relation avec le projet hôte ?

Cela vient de déplacer le désordre d’origine du répertoire principal du projet vers le répertoire Package.

La valeur de la GPS ne réside donc pas dans le fait de « la rendre moderne », mais dans le fait qu’elle fait en sorte que de nombreuses questions de frontières qui auraient pu être vagues dans le passé ne puissent plus l’être.

7. It won’t automatically solve anything

Ceci est également important. SPM ne permet pas automatiquement de résoudre :

• Is the module dismantling reasonable?
• Le nom est-il clair ?
• Dependence on whether the direction is healthy
• Is a certain public module drawn too early?
• La couche métier et la couche de base sont-elles mélangées ?

Cela dit, SPM n’est pas un architecte, c’est juste un outil mieux adapté pour héberger une bonne architecture.

Si l’équipe n’a aucune conscience des limites au départ, la GPS peut finir par simplement présenter le problème d’une manière plus « moderne ».

8. Conclusion : la GPS devient de plus en plus importante. En apparence, il semble qu’il puisse installer des bibliothèques, mais en fait il en est plus proche et est plus adapté à l’hébergement de projets modulaires.

Pour le dire sous une forme plus courte, je dirais :

La raison pour laquelle SPM devient de plus en plus important est qu’en apparence, il semble qu’il nous permette enfin d’installer un CocoaPod de moins. En fait, il est plus facile pour les projets Swift de transformer plus facilement les limites des modules, les dépendances et les structures de projet en conceptions explicites.

Ce qui est vraiment important n’est donc pas seulement la « gestion des dépendances », mais :

• Modulaire
• Normalisation
• Make boundaries explicit

C’est pourquoi il mérite de plus en plus d’être pris au sérieux.