Swift Package Manager Series 04｜Limites de code pouvant être incluses dans les packages

L’une des erreurs les plus courantes commises par de nombreuses équipes lorsqu’elles commencent à faire de la modularisation est :

Décidez d’abord de supprimer le module, puis réfléchissez à la raison pour laquelle le module existe.

Ainsi, le résultat final est généralement “copier le couplage d’origine dans plusieurs répertoires”. En apparence, il y a plus de modules, mais en réalité les dépendances n’ont pas changé et sont encore plus déroutantes.

Donc, ce dont je veux parler dans cet article est : quel type de code peut être mis dans le package et quelles sont les erreurs de jugement structurelles les plus courantes lors du fractionnement.

1. Pour déterminer s’il doit être divisé, ne regardez pas d’abord le nombre de fichiers, mais regardez d’abord si les limites existent naturellement.

La pertinence de retirer un module dépend de ses limites naturelles.

Les limites dites naturelles se reflètent généralement dans :

• Il assume un ensemble relativement unique de responsabilités
• Son sens de dépendance est relativement clair
• Il n’est pas nécessaire de connaître grand chose sur le contexte du projet hôte
• Il est susceptible d’être réutilisé dans plusieurs scénarios à l’avenir

Si ces conditions ne sont pas remplies, simplement parce que « ce dossier est un peu gros maintenant », alors il est probable qu’il soit séparé juste pour continuer le couplage à un autre endroit.

Le premier principe de la modularité est “la frontière existe déjà, je la rends juste explicite”.

2. Ceux qui conviennent le moins à la suppression dans le premier lot sont souvent de gros blocs métiers fortement couplés à la page.

Lorsque j’ai commencé à faire cela, lorsque je faisais de la modularisation, les éléments que j’étais le plus tenté de démonter étaient :

• Page d’accueil
• Centre de comptes
• Processus de paiement
• Détails du contenu

Bien sûr, ces modules sont importants, mais ils sont aussi souvent profondément liés à ces éléments :

• Routage -Cycle de vie de l’application hôte
• Statut des pages
• enterrer le problème
• Ressources d’interface utilisateur

Si vous partez de ces endroits pour le premier fractionnement, les limites ne seront pas claires, et il est facile d’apparaître :

• Le module lui-même doit également s’appuyer sur l’hôte en sens inverse
• Afin de partager quelque chose, plusieurs packages se référencent les uns les autres
• La couche publique est polluée par la couche métier

Par conséquent, ce qui est le plus approprié pour la démolition pour la première fois est généralement le « bloc avec la limite la plus claire ».

3. Le code pouvant être inclus dans le package a généralement trois formes typiques :

1. Module de capacités de base

Par exemple :

• Journal
• Encapsulation réseau
• cache local
• Lecture des configurations

Les caractéristiques communes de ces fonctionnalités sont des responsabilités claires, l’indépendance des pages et un grand espace de réutilisation.

2. Modèle de domaine ou module de service de domaine

Par exemple :

• Modèle utilisateur et requête d’informations utilisateur
• Objets de domaine de contenu et entrepôt de contenu
• Logique du champ de commande

Ce type de module est plus orienté métier, mais tant que les limites sont claires, il convient également au développement de packages.

3. Module de composant de base de l’interface utilisateur stable

Par exemple :

• Concevoir les composants de base du système
• Système de style universel
• Plusieurs composants interactifs sans couplage métier

Le principe est qu’ils sont vraiment stables et ne volent pas la sémantique spécifique à la page.

4. Un malentendu très courant : le fractionnement par répertoire plutôt que par direction de dépendance

De nombreuses équipes échouent dans la modularisation. En apparence, il semble qu’il y ait trop peu de démontage, mais en fait c’est plus proche d’une mauvaise méthode de démontage.

Les questions les plus courantes sont : Comment diviser les dossiers dans le passé est maintenant la façon de diviser les modules.

Par exemple :

• Home/
• User/
• Common/
• Utils/

En surface, cela ressemble à un module, mais en fait vous rencontrerez bientôt :

• Home dépend de User
• User dépend de Common
• Common contient en fait un tas de logique métier mélangée
• Utils Au final, c’est devenu une poubelle avec tout ce qu’il y avait dedans.

Cela montre que ce qui est divisé est le répertoire et non la frontière.

Une méthode de démontage vraiment plus stable doit être considérée du point de vue de la dépendance :

• Quels modules ne peuvent être invoqués que vers le bas
• Quelles capacités le public sous-tend-il
• Quelles sont les couches de domaines d’activité ?
• Lesquels sont exclusifs à la couche hôte ?

Ce n’est que lorsque la direction de la dépendance est claire que la division des modules sera stable à long terme.

5. Ne cachez pas les dépendances pour la modularité

Lorsque certains projets démantelent des modules, afin d’éviter les dépendances circulaires, ils commencent à utiliser diverses méthodes de compromis :

• Modules publics extra larges
• Dessinez des accords partout
• Mettre une “couche pont” au milieu

Ces techniques ne sont pas impossibles à utiliser, mais si elles visent simplement à « donner une belle apparence au diagramme de module », il est facile de cacher le couplage réel au lieu de le résoudre.

Donc ce qui m’intéresse le plus, c’est :

• Si la relation de dépendance actuelle est commercialement raisonnable
• Les modules sont-ils séparés en raison de responsabilités réelles différentes ?
• Ou est-ce juste pour contourner les limites de l’outil ?

Une modularité vraiment saine, c’est lorsque l’accouplement est clairement placé dans la bonne direction.

6. Un jugement pratique : Si ce module est supprimé, le projet hôte le comprendra-t-il toujours ?

C’est une façon très courante de me juger.

Si vous sortez un module candidat, demandez-vous :

• La compréhension du projet hôte est-elle encore claire ?
• L’appelant externe a-t-il seulement besoin de connaître l’interface sans connaître beaucoup de détails internes ? -S’il s’agit encore d’un concept complet après avoir quitté l’hôte

Si la réponse est « oui », alors il est généralement mieux adapté en tant que package. Si la réponse est « non », il s’agit probablement encore d’un tas de détails d’implémentation à l’intérieur de l’hôte.

7. Lors du premier démontage, il vaut mieux démonter moins que de le démonter en morceaux.

Lorsqu’on fait de la modularisation pour la première fois, il est facile de tomber dans l’impulsion du “Maintenant que nous avons commencé à le démonter, démontons-le davantage”. Mais l’un des échecs les plus courants dans les projets de taille moyenne est que les modules sont trop fragmentés.

Une fois le module trop fragmenté, le coût augmentera rapidement :

• Le graphe de dépendance est plus complexe
• Les relations de compilation sont plus difficiles à comprendre
• La gestion des versions et des limites est plus problématique
• Lors de la révision, vous devez parcourir de nombreux modules

Alors lors du premier partage, je préfère :

• Supprimez d’abord quelques modules avec des limites claires
• observer plusieurs itérations
• Décider s’il faut poursuivre le raffinement

La plus grande crainte de la modularité est que la première étape consiste à diviser le système en plusieurs petits morceaux qui semblent indépendants mais qui sont en réalité étroitement liés les uns aux autres.

8. Conclusion : Ce qui convient à l’inclusion dans le package est « une capacité avec des limites claires »

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

La clé pour juger si un morceau de code peut être inclus dans un package n’est pas le nombre de fichiers qu’il contient, mais s’il a des limites de responsabilité, des directions de dépendance et une sémantique indépendante relativement claires.

Alors ce qui compte vraiment c’est :

• démonter
• Selon quelle frontière ?
• La direction des dépendances est-elle plus claire après le démontage ?

Ce n’est que si ces trois éléments sont établis à l’avance que la modularisation peut réellement réduire la complexité, plutôt que la réorganiser.