Swift Package Manager Series 05｜Accès et gestion des packages tiers dans les projets iOS

Lorsqu’on parle de gestion des dépendances de tiers sur de telles questions, l’accent est mis davantage sur l’avenir :

• Cette bibliothèque est-elle accessible via SPM ?
• Xcode peut-il le reconnaître ?
• Comment écrire le numéro de version

Bien sûr, ces éléments sont importants, mais dans les projets réels, le coût réel se situe souvent plusieurs années après l’installation.

Car une fois que des dépendances tierces entreront dans le projet, cela entraînera toute une série de problèmes à long terme :

• Comment contrôler le rythme de mise à niveau
• Quels modules seront affectés par les changements d’API ?
• Si la bibliothèque spécifique est directement exposée au code métier
• Une fois que vous souhaitez remplacer la bibliothèque, le coût sera-t-il élevé ?

La vraie difficulté dans la « gestion des packages tiers » est donc la gouvernance.

1. Avant d’accepter des dépendances tierces, la première chose à se demander est “Est-ce que cela entrera dans la limite centrale ?”

Avant qu’une bibliothèque ne soit ajoutée à un projet, la première chose que je demande habituellement n’est pas :

• Combien y a-t-il d’étoiles ?
• Le document est-il beau ?

Au lieu de cela :

• Est-ce que cela ira directement dans de nombreux codes commerciaux ?
• Est-ce que cela définira une sorte de forme d’interface pour nous à l’avenir ?
• Quel sera son impact une fois mis à niveau ou remplacé ?

Parce que certaines bibliothèques n’ont que des fonctionnalités périphériques, telles que des outils de débogage, des backends de journalisation et des gadgets ponctuels ; Certaines bibliothèques entreront directement au cœur du système, comme la couche réseau, la couche image, la couche de routage et la couche de stockage.

Une fois ce dernier mal sélectionné, les coûts de modification ultérieurs seront très élevés.

Je suis donc plus préoccupé de savoir s’il entre dans la « couche périphérique » ou dans la « couche dorsale ».

2. Ne laissez pas le code métier connaître directement trop de détails sur la bibliothèque tierce

C’est l’expérience la plus facilement négligée, mais la plus critique.

Supposons qu’une bibliothèque de chargement d’images soit utilisée et que son API soit partout dans le projet :

• Afficher la couche directement importée
• ViewModel connaît aussi son type
• La couche d’outils en dépend aussi

Ensuite, cette bibliothèque passera bientôt de « dépendance » à « partie de l’infrastructure ». Si vous souhaitez le mettre à niveau ou le remplacer à l’avenir, le coût sera bien plus élevé que prévu.

Ainsi, une approche plus stable est généralement :

• Enveloppez votre propre abstraction autour de limites appropriées
• Laissez l’entreprise s’appuyer sur l’interface de fonctionnalités plutôt que sur la bibliothèque elle-même

Cela ne signifie pas que toute bibliothèque tierce doit être entièrement packagée, mais au moins pour les dépendances qui pénètrent profondément dans la couche principale du tronc, l’isolation doit être sérieusement envisagée.

3. SPM facilite l’accès, mais il peut aussi facilement rendre “l’ajout d’une dépendance” trop frivole.

Il s’agit d’un effet secondaire très réel.

L’accès à SPM étant si simple, de nombreuses équipes développeront lentement cette habitude :

• J’ai vu un petit besoin
• Rechercher une bibliothèque
• ajouter
• De toute façon, c’est juste un paquet

C’est très efficace à court terme, mais les problèmes à long terme vont progressivement s’accumuler :

• Extension des dépendances
• La chaîne de compilation s’allonge
• Certaines bibliothèques ne sont plus maintenues depuis longtemps
• Plusieurs fonctions de bibliothèque se chevauchent
• Il existe de nombreuses dépendances dans le projet dont “personne ne peut expliquer la raison d’être”

Par conséquent, la GPS rend la gestion des dépendances plus légère, mais la légèreté ne signifie pas que les normes de gouvernance doivent être assouplies. Plus l’outil est léger, plus le contrôle humain est nécessaire.

4. Le cœur de la gestion des versions réside dans la clarté de la stratégie de mise à niveau

Lorsque j’ai appris ce contenu pour la première fois sur la version SPM, j’ai d’abord prêté attention à :

• Version exacte
• version portée
• jusqu’àNextMajor

Ces règles doivent être connues, mais les questions d’ingénierie les plus importantes sont en réalité :

• Qui est responsable de la mise à niveau de cette dépendance ?
• À quelle fréquence réviser les versions
• La mise à niveau doit-elle suivre les besoins de l’entreprise ou être gérée régulièrement ?
• Comment évaluer rapidement l’impact d’un échec de mise à niveau

Si personne n’est responsable de ces choses, alors, aussi belle soit la contrainte de version, elle ne deviendra qu’une “valeur fixe qui n’a pas été modifiée depuis plusieurs années”.

S’appuyer sur la gestion des versions est donc essentiellement une question de rythme de gouvernance.

5. La chose la plus effrayante à propos de la dépendance envers les tiers est “personne ne la regardera après être entré dans le système”

Tout le monde était très sérieux au sujet de nombreuses dépendances le jour où elles ont été introduites, mais personne ne s’en est occupé par la suite. Cela entraîne plusieurs risques typiques :

• Les mises à jour de sécurité sont à la traîne depuis longtemps
• Le retard dans les modifications de l’API explose en une mise à niveau
• Personne dans l’équipe ne sait qui d’autre s’appuie sur cette bibliothèque
• Des bibliothèques de capacités similaires sont continuellement superposées

Ensuite, le projet entrera lentement dans un état :

• Les dépendances ne sont pas inutilisables
• Mais personne n’ose bouger

C’est plus courant et plus difficile à gérer que de « choisir la mauvaise bibliothèque en premier lieu ».

6. Ce que j’apprécie le plus, c’est de savoir si la liste de dépendances est “explicable”

Une liste saine de dépendances de projet n’est pas nécessairement courte, mais de préférence explicable.

En d’autres termes, lors du relevé d’une dépendance, l’équipe peut clairement indiquer :

• Quel problème cela résout-il ?
• est-ce que c’est
• A quel étage il se trouve
• S’il existe des frontières d’isolement
• S’il doit être remplacé à l’avenir, quel sera le coût principal ?

Si une dépendance est devenue :

• “C’est déjà arrivé là-bas”
• “Il semble que ce soit utilisé quelque part”
• “Supprimez-le de peur que quelque chose n’arrive”

Ensuite, il est entré dans une zone de gouvernance hors de contrôle.

7. Une stratégie pratique : traiter les dépendances tierces en couches

Je divise généralement les dépendances en trois catégories :

1. Dépendance marginale

Par exemple, certaines aides au développement, les rapports de journaux et les outils basse fréquence. Même si ce type de dépendance est utilisé plus directement, les risques restent relativement contrôlables.

2. Dépendance à la plateforme

Par exemple, images, réseau, stockage, routage, etc. Ce type de dépendance est susceptible de pénétrer dans le tronc du système et la portée de l’exposition doit être soigneusement contrôlée.

3. Dépendances profondément couplées avec une faible remplaçabilité

Une fois certaines bibliothèques connectées, elles affecteront un grand nombre de conceptions d’API. Ce type de dépendance nécessite des limites claires au début, sinon le coût de remplacement sera très élevé à l’avenir.

Cette approche en couches est plus réaliste que « tous l’utilisent directement » ou « une couche est tout incluse ».

8. Conclusion : Le cœur du package tiers est la gouvernance à long terme

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

Lors de la gestion de packages tiers dans un projet iOS, ce qui compte vraiment est « une fois qu’ils sont entrés dans le système, pouvez-vous contrôler ses limites, son rythme de mise à niveau et ses coûts de remplacement ? »

La gestion des dépendances est donc une capacité de gouvernance à long terme.