Swift Package Manager Series 02｜Créer le premier package Swift

De nombreux didacticiels qui parlent de « créer votre premier package Swift » se concentrent sur les commandes ou les actions Xcode.

Bien entendu, ces étapes doivent être connues. Mais si vous savez seulement comment cliquer sur “Nouveau package”, vous avez en réalité seulement appris à “générer un modèle” et vous n’avez pas vraiment compris l’importance technique de la création d’un package.

Parce que c’était la première fois que je créais mon propre package Swift, ce qui a vraiment commencé à changer, c’est la façon dont j’y pensais :

• Ce code mérite-t-il d’être séparé en module ? -Quelle interface ce module doit-il exposer ?
• Quels détails d’implémentation doivent être masqués
• De qui dépend-il et sur qui faut-il s’appuyer ?

Ce dont je veux parler dans cet article, c’est des jugements à prendre lors de la première création d’un package.

1. Ne vous précipitez pas pour créer le package en premier. Demandez d’abord si ce code doit continuer à rester dans le projet principal.

C’est l’étape qui me tient le plus à cœur.

Une situation courante consiste à dire : « Modularisons-le ». Mais ce qui vaut vraiment la peine de se demander :

Pourquoi ce code devrait-il être séparé du contexte actuel du projet et devenir un module indépendant ?

Les raisons légitimes courantes comprennent :

• Il sera réutilisé par plusieurs cibles ou plusieurs modules métiers
• Il a formé une capacité de terrain relativement stable
• Cela ne devrait plus dépendre des détails de la page ou du projet hôte
• Il mérite des limites de test distinctes

Si vous ne pouvez citer aucune de ces raisons et que vous avez simplement « l’impression qu’il y a trop de fichiers », il n’est probablement pas encore temps de créer un package.

Le package n’est pas utilisé pour stocker des fichiers, il est utilisé pour exprimer des limites.

2. La chose la plus appropriée à extraire pour la première fois est généralement de petites capacités avec des limites claires.

Si une équipe est nouvelle dans SPM, je ne recommande généralement pas de la supprimer dans un premier temps :

• Page d’accueil entière
• Système de compte complet
• Module de paiement complet

Étant donné que ces modules sont souvent profondément couplés au projet hôte, à la couche de page, à la couche de routage et à la couche d’état, une fois que les limites ne sont pas clairement définies, la première division sera facilement contrecarrée.

Ceux qui conviennent mieux au premier lot de packages ont généralement ces capacités :

-Capacités de base de la couche réseau

• Journalisation, surveillance et emballage de points cachés
• Outils de traitement d’images ou de mise en cache
• Une bibliothèque de modèles de domaine claire
• Un ensemble de composants de base de l’interface utilisateur relativement stables

Les caractéristiques communes de ces modules sont :

• Moins de dépendance
• Responsabilité unique
• Les limites sont relativement claires

Ils sont plus adaptés pour aider l’équipe à se faire une idée de « ce qu’est un module indépendant ».

3. Lors de la première création d’un package, la chose la plus critique est l’interface publique

Une situation courante est qu’après avoir construit le premier package, vous vous concentrerez immédiatement sur la façon d’organiser le répertoire. Mais d’un point de vue technique, ce qui est vraiment plus important est :

• Qu’est-ce que le module expose au monde extérieur ?
• Ce qui est conservé à l’intérieur du module

Vous pouvez considérer la création d’un package comme une mesure de retenue :

• Quels types valent vraiment la peine d’être exposés comme public
• Quelles fonctions utilitaires ne doivent rester qu’internes
• Quelles dépendances ne doivent pas être connues de l’appelant

Si vous déplacez simplement tout le projet principal d’origine dans un seul package, puis que vous le remplacez par public, cela ne formera pas vraiment de limite.

Par conséquent, lors de la création d’un package pour la première fois, la pratique la plus intéressante consiste à “définir l’interface”.

4. L’un des malentendus les plus courants : créez d’abord le package, puis réfléchissez aux responsabilités du module

Il est facile de se tromper avec cette séquence.

L’ordre correct devrait généralement être :

1. Clarifiez d’abord les responsabilités de cette capacité
2. Voyons s’il vaut la peine d’être un module indépendant.
3. Enfin, hébergez-le sous forme de package

Si l’ordre est inversé, les conséquences courantes sont :

• Un package veut s’occuper de tout
• Confusion des dépendances internes
• L’interface externe est trop grande
• Le projet hôte a encore besoin de connaître de nombreux détails de mise en œuvre

En d’autres termes, SPM ne peut pas concevoir de modules pour l’équipe, il est simplement plus adapté au transport de modules clairement pensés.

5. Les quatre problèmes qui me tiennent le plus à cœur lors de la première création d’un package

Si j’examine le premier package d’une équipe, les quatre questions que je pose le plus souvent sont :

1. Ce module a-t-il une responsabilité unique et claire ?

Si un module gère simultanément le réseau, le cache, l’état de la page et les points enterrés, ce n’est probablement pas encore clair.

2. Si ses dépendances sont suffisamment peu nombreuses

Lorsque vous créez un package pour la première fois, moins il y a de dépendances, plus il est facile de réussir. Lorsqu’il y a trop de dépendances, les frontières deviennent floues.

3. Son interface publique est-elle beaucoup plus petite que son implémentation interne ?

S’il y a dix types dans le module, huit d’entre eux seront exposés, indiquant que le contrôle des limites n’est pas assez bon.

4. Cela vaut-il la peine de procéder à des tests indépendants ?

Les modules qui méritent d’être testés indépendamment sont généralement plus dignes d’une existence indépendante. Si vous ne parvenez pas à comprendre comment le tester de manière isolée, il est probablement encore trop étroitement lié au contexte hôte.

6. Le critère de réussite pour la première fois est le « démontage stable »

Lorsque de nombreuses équipes effectuent la modularisation pour la première fois, elles sont plus susceptibles de rechercher un « sentiment de résultat », tel que :

• Supprimez 10 modules en une seule fois
• Tout le code public va dans le package
• Le projet principal a perdu beaucoup de poids immédiatement

Mais dans les projets réels, les critères les plus importants pour réussir du premier coup sont généralement :

• Avoir un module avec des limites claires
• Les dépendances externes sont saines
• L’équipe comprend pourquoi elle a été divisée ainsi
• Cela n’est pas revenu rapidement dans les itérations suivantes

Car la plus grande crainte de la modularité est que la confiance de chacun en la matière soit perdue dans un premier temps.

7. Conclusion : Le premier package Swift enseigne véritablement comment organiser le code en fonction des limites.

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

Le vrai sens de la création du premier Swift Package est d’être obligé de répondre sérieusement pour la première fois “pourquoi ce code mérite d’être un module autonome”.

Une fois que vous commencez à considérer le problème sous cet angle, SPM ne consiste plus seulement à « puis-je l’utiliser », mais commence à véritablement entrer dans la pensée de l’ingénierie modulaire.