Swift Package Manager Series 07｜Méthode de gestion SPM dans les projets iOS de taille moyenne

Si je devais utiliser SPM pour gérer un projet iOS de taille moyenne, ma première préoccupation ne serait pas « combien de packages supprimer », mais ces trois questions :

• Quelles capacités méritent vraiment l’indépendance ?
• Comment maintenir une direction stable des dépendances des modules
• Qu’est-ce qui doit être retenu dans le projet d’accueil et qu’est-ce qui ne doit pas être retenu ?

Parce que les projets de taille moyenne sont les plus susceptibles de tomber dans le piège : Il semble que la modularisation ait commencé, mais en fait il ne s’agit que d’une redistribution de la complexité du projet principal d’origine vers plusieurs packages.

Donc, ce dont je veux parler dans cet article, c’est la façon dont je juge les modules, les hiérarchies et les graphiques de dépendances.

1. Je ne poursuivrai pas “plus de modules” depuis le début, mais je poursuivrai d’abord “des niveaux clairs”

La complexité des projets de taille moyenne n’est généralement pas suffisamment grande pour nécessiter une subdivision extrême, mais elle suffit pour que « tout dans le projet principal » commence à devenir dangereux.

La chose la plus importante à ce stade est de commencer par retirer les couches.

Je vois généralement d’abord si les catégories de choses suivantes peuvent être séparées de manière stable dans le projet :

• Couche de capacité de base
• Couche de capacité de domaine
• Couche de réutilisation de l’interface utilisateur
• Couche de projet hôte

Une fois ces quatre types de choses mélangés, il est facile pour le projet de devenir incontrôlable dès que l’échelle augmente. Mais si la hiérarchie est établie en premier, le nombre de modules sera un détail ultérieur.

2. Je vais d’abord diviser les modules de base en trois catégories.

1. Module de capacités de base

Par exemple :

• réseau
• Journal
• cache
• Lecture des configurations
• Outils de base

Les caractéristiques de ce type de module sont qu’il est éloigné de l’entreprise, qu’il a une forte réutilisabilité et que la direction des dépendances doit être fermée autant que possible.

2. Module de capacité de domaine

Par exemple :

-Compte

• Utilisateur
• Contenu
• Commande

Ces modules sont des centres de capacités commerciales. Ils doivent héberger des modèles de domaine, des entrepôts, des cas d’utilisation, plutôt que des implémentations de pages spécifiques.

3. Module de réutilisation de l’interface utilisateur

Par exemple :

• Système de conception
• Composants communs
• Conteneur de liste universelle

Je ferai très attention ici pour éviter de diviser accidentellement la page commerciale en modules d’interface utilisateur. Les modules de réutilisation de l’interface utilisateur sont plus adaptés pour offrir des fonctionnalités de composants stables, universelles et multipages.

3. Que faut-il retenir dans le projet hôte ?

C’est un problème que de nombreuses équipes ont tendance à négliger.

Une fois que vous commencez à faire du GPS, il est facile d’avoir une tendance : “Comme ils sont tous modulaires, il est préférable que le projet hôte soit le plus mince possible.”

Cette affirmation n’est qu’à moitié vraie.

Le projet hôte ne devrait vraiment pas comporter trop de fonctionnalités réutilisables, mais il devrait tout de même conserver certaines éléments qui appartiennent naturellement à l’hôte, tels que :

• Orchestration du cycle de vie des applications
• Assemblage de routage
• Injection de configuration d’environnement
• Assemblage des modules
• Codes liés à la forme du produit final

En d’autres termes, le projet hôte devrait se concentrer sur la collaboration au niveau de l’assemblage et du produit, plutôt que de proposer un ensemble de fonctionnalités qui auraient pu être abandonnées.

4. Je ne vais pas le démonter trop finement au début.

C’est quelque chose sur lequel j’insiste beaucoup.

L’un des écueils dans lesquels les projets de taille moyenne risquent le plus de tomber est la « modularisation au nom de la modularité », qui finit par trop déchirer le système.

Une fois le module trop fragmenté, des problèmes apparaîtront immédiatement :

• Graphique de dépendance complexe
• Le chemin de débogage devient plus long
• Sauts fréquents entre les modules pendant la révision
• Un petit changement implique plusieurs liens de packages

Cela peut rapidement amener les équipes à douter de la modularité elle-même.

Je préfère donc :

• Démonter d’abord quelques gros modules avec des responsabilités claires
• observer plusieurs itérations
• Décider s’il faut affiner

Choisir le système très finement du premier coup se fait généralement dans l’urgence.

5. La direction des dépendances est plus importante que le nombre de modules

Si on me demandait de choisir entre “supprimer plus de modules” et “redresser les dépendances”, je choisirais certainement cette dernière.

Parce que plus de modules n’équivaut pas automatiquement à une meilleure structure. Ce qui détermine réellement si le système peut évoluer de manière stable à long terme, c’est si la direction de la dépendance est claire.

Par exemple, je me soucie davantage de savoir si ces relations sont valables :

-La couche de base ne dépend pas de la couche métier

• La couche domaine ne s’appuie pas sur la couche hôte à l’envers
• La couche de réutilisation de l’interface utilisateur ne vole pas la sémantique métier de la page
• La couche hôte est responsable de l’assemblage, plutôt que de détenir toute la mise en œuvre interne entre ses mains.

Tant que les directions de dépendance sont perturbées et quel que soit le nombre de modules, le système ne sera qu’un “couplage imbriqué multicouche”.

6. Je me méfierai beaucoup des « modules publics universels »

Il s’agit d’un anti-modèle qui apparaît fréquemment dans les projets de taille moyenne.

Lorsqu’un projet est modularisé au début, il y aura souvent une question appelée :

• Common
• Shared
• Core
• Base

Des super modules comme celui-ci.

Si ce module possède des capacités de base claires, alors il n’y a pas de problème. Mais les « modules publics » de nombreux projets deviendront à terme :

• On peut compter sur n’importe où
• Mettez tout là-dedans
• Il existe à la fois des fonctions d’outils, des modèles commerciaux et des composants d’interface utilisateur

Le résultat est qu’il devient le nouveau point de couplage central.

Je préfère donc le diviser en petits modules de base avec des responsabilités claires, plutôt que de construire un grand module public qui couvre tout.

7. La chose la plus importante pour la modularisation des projets de taille moyenne est une cognition cohérente en équipe.

C’est très réaliste.

Dans les projets de taille moyenne, de nombreux problèmes structurels sont causés par le fait que l’équipe n’a pas une compréhension cohérente des limites. Par exemple, certaines personnes pensent :

• Tout ce qui concerne la page est considéré comme un module

Certains pensent :

• Les modèles de domaine doivent être démontés séparément

Certains pensent :

• Les composants publics doivent être placés avec les modules métier pour plus de commodité

Si ces cognitions ne sont pas unifiées pendant une longue période, le système continuera à accroître les conflits de frontières, même avec SPM.

Ainsi dans les projets de taille moyenne, j’attacherai une grande importance à :

• La dénomination des responsabilités des modules est-elle cohérente ?
• Existe-t-il un consensus sur le sens de la dépendance ?
• Lors de l’ajout d’un nouveau code, pouvez-vous indiquer sur quel calque il doit être placé ?

C’est bien plus important que simplement « combien de paquets ont été ouverts ».

8. Conclusion : Le cœur de l’utilisation de SPM pour gérer des projets de taille moyenne n’est pas la quantité, mais la stabilité à long terme du graphe de dépendances.

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

Lorsque vous utilisez SPM pour gérer un projet iOS de taille moyenne, le plus important est de former une direction de dépendance stable à long terme entre les capacités de base, les capacités de domaine, la réutilisation de l’interface utilisateur et l’assemblage de l’hôte.

En faisant cela, le nombre de modules trouvera naturellement la bonne taille. Si vous ne pouvez pas faire cela, peu importe à quel point vous le divisez, cela ne fera que recouper la complexité.