Swift Package Manager Series 06｜Scénarios applicables et limitations de SPM

Une fois qu’un consensus est atteint au sein de la communauté technique, un autre problème surgit facilement : Tout le monde a commencé à dire par défaut « puisque la direction est la bonne, alors nous devrions tout mettre en œuvre dès que possible ».

Il est également facile pour SPM de suivre ce rythme.

Il s’agit en effet d’un outil très important pour les projets Swift modernes, mais « important » ne signifie pas « doit être pleinement promu immédiatement et à tout moment ». Ce n’est pas parce que les outils sont avancés que le projet actuel a déjà les limites et les conditions organisationnelles pour le mener à bien.

Donc je n’aime jamais vraiment ce genre de conclusion générale :

• “Il est temps de tout déplacer vers SPM”
• “Si vous n’utilisez pas SPM, vous prendrez du retard.”

Une question plus pratique devrait être :

Si le projet est actuellement adapté à la migration de certaines fonctionnalités vers SPM et s’il sera plus stable une fois la migration terminée.

1. La condition préalable pour être apte à la GPS est que les limites commencent à être claires.

Si un projet est actuellement dans cet état :

• Tout le code est fortement couplé dans une seule cible d’application
• Les pages, les services, le routage et les configurations peuvent se pénétrer
• Les frontières entre capacités publiques et capacités commerciales prêtent à confusion

Si vous vous précipitez vers SPM à ce moment-là, vous déplacerez probablement simplement le couplage existant intact dans plusieurs packages.

Cela semble modulaire en surface, mais en fait les dépendances sont plus difficiles à comprendre et plus difficiles à modifier.

L’ordre que je préfère est donc :

1. Laissez d’abord les limites devenir claires
2. Réutilisez SPM pour héberger ces limites

Plutôt que l’inverse, attendez-vous à ce que SPM aide automatiquement à créer des limites.

2. Quel est le meilleur moment pour commencer à utiliser SPM ?

Je considère généralement les signaux suivants indiquant qu’un projet est prêt à introduire ou à étendre la GPS :

• Il existe des modules de capacités publiques clairs qui peuvent être indépendants
• L’équipe a commencé à avoir une idée des limites, au lieu de simplement diviser le code par répertoire
• Certaines capacités méritent des tests indépendants et une évolution indépendante
• Le projet principal a engendré des coûts de maintenance importants en raison de l’agrandissement
• L’équipe est prête à supporter des coûts de conception supplémentaires pour les limites des modules

Si ces conditions apparaissent progressivement, la GPS devient souvent une prochaine étape naturelle.

3. Quand n’est-il pas approprié de « se forcer » ?

Le « renforcement » fait ici référence à la promotion de la GPS en tant que mission politique.

Je serais très prudent dans les situations suivantes :

1. Le projet est encore très petit et le principal problème n’est pas du tout les limites des modules.

Si le projet actuel ne compte que quelques personnes, est de petite taille et a des limites relativement simples, le problème principal n’est peut-être pas du tout modulaire.

L’introduction d’un ensemble de packages trop tôt à ce stade peut apporter plus de complexité que d’avantages.

2. L’équipe n’a pas de consensus de base sur les limites.

Si vous êtes connecté maintenant :

• Comment distinguer la couche de base et la couche métier
• Comment distinguer la couche page et la couche service
• Comment distinguer les modules publics et les modules hôtes

S’il n’y a pas encore de consensus, SPM se contentera d’exposer ces différends à l’avance, sans pour autant les résoudre.

3. Juste pour « avoir l’air avancé »

C’est le type de motivation le plus dangereux. Si la raison pour adopter la GPS est simplement :

• Tout le monde l’utilise
• Le schéma d’architecture sera plus beau
• Look plus moderne sur le CV

Il y a une forte probabilité qu’il devienne finalement « une forme améliorée, une structure inchangée ».

4. L’aspect le plus facilement surestimé du SPM : penser qu’il engendrera automatiquement une bonne architecture

Ce ne sera pas le cas.

Les points forts de SPM sont :

• Limites du module d’hébergement
• Dépendances explicites
• Rendre l’évolution des modules plus naturelle

Mais cela ne répondra pas à l’équipe :

• Quel module mérite d’exister
• Comment concevoir en fonction de la direction
• L’étage public est-il tiré trop tôt ?
• Certains codes des affaires ne devraient-ils pas être indépendants en premier lieu ?

Cela dit, SPM s’apparente plus à une bonne fondation qu’à un architecte. Sans connaissance du design, une structure complexe sera quand même construite même si les fondations sont remplacées.

5. La stratégie de migration est plus importante que « devriez-vous migrer ou non ? »

De nombreux projets ont échoué en raison de « changements législatifs trop drastiques ».

Une stratégie de migration plus stable est généralement :

• Commencer à piloter les modules avec les limites les plus claires en premier
• Effectuez d’abord un petit nombre de fractionnements à haute certitude
• Exécuter plusieurs itérations pour vérifier les dépendances et les coûts de collaboration
• Décider s’il faut continuer à se développer

Au lieu de simplement venir :

• Déballage complet de l’entrepôt
• Tout le code public est forcé dans le package
• Migrez toutes les dépendances tierces en même temps

La modularisation est un projet à long terme et ne convient pas à un avancement en une seule étape.

6. Un critère de jugement pratique : après avoir utilisé SPM, le projet sera-t-il plus clair ou plus alambiqué ?

Si une modification est effectuée après la migration :

• La direction des dépendances est plus claire -Les responsabilités des modules sont plus claires
• Il est plus facile de juger de l’ampleur de l’impact lors de l’examen
• Les limites des tests sont plus naturelles

Alors cette migration en vaut probablement la peine.

Si une fois la migration terminée :

• Il y a plus de modules mais les responsabilités ne sont pas plus claires
• Le projet hôte connaît encore un tas d’implémentations internes
• Changer une fonction nécessite de passer d’un paquet à l’autre

Cela signifie que le problème ne vient pas de l’outil, mais de la conception des limites elle-même.

7. Conclusion : SPM vaut la peine d’être utilisé, mais ne vaut pas la peine d’être utilisé comme migration formaliste

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

Quand utiliser SPM, la clé n’est pas « de savoir si c’est la bonne direction », mais « si le projet et l’équipe sont actuellement prêts à utiliser les limites des modules pour supporter la complexité ».

L’approche vraiment stable est donc :

• Utilisez-le au bon moment
• Commencez par des limites appropriées
• Utilisé pour porter des structures clairement pensées

De cette manière, SPM deviendra un outil de réduction des charges plutôt qu’un nouveau cycle de tâches d’ingénierie.