SwiftUI Series 15｜Créer un projet SwiftUI maintenable à partir de zéro

Si on me demandait de créer un projet SwiftUI à partir de zéro, la première chose que je considérerais ne serait pas l’apparence du répertoire, et je ne m’en soucierais pas non plus :

• Devez-vous soumettre un modèle d’architecture complet ? -Dois-je d’abord dessiner beaucoup de couches de base ?

Ce à quoi je pense en premier, ce sont ces choses-là :

• Comment le statut circule
• Comment changer de responsabilité de page
• Quand et dans quelle mesure les composants sont-ils pompés ?
• Le projet deviendra-t-il difficile à modifier au bout de trois mois ?

Parce que de nombreux projets SwiftUI sont assez légers au début, le véritable tournant se produit souvent après deux ou trois mois :

• De plus en plus de pages
• L’état est de pire en pire
• La réutilisation des composants devient de plus en plus aléatoire
• Commencez à empiler la logique métier dans View

Donc, ce que la «maintenabilité» veut vraiment résoudre, c’est la stabilité après la croissance, et non la vitesse de développement au cours de la première semaine.

1. Je ne vais pas construire un cadre lourd dès le début, mais clarifier d’abord les responsabilités.

L’un des malentendus les plus courants lorsqu’on démarre un projet à partir de zéro est :

• L’entreprise n’a pas encore démarré
• Disposez d’abord un ensemble complet de structures qui semblent complètes

Ce n’est pas nécessairement faux, mais le risque est le suivant :

• résumé trop tôt
• La structure ne correspond pas à la réalité du business
• L’équipe continuera à le contourner plus tard

Je préfère donc :

• Précisez d’abord les limites des responsabilités
• Ajoutez progressivement des couches à mesure que la complexité augmente

Plutôt que « d’être grand et complet le premier jour », j’apprécie davantage « d’être fluide le premier mois ».

2. La première chose que je comprends habituellement, ce sont les trois couches : la couche de page, la couche d’état et la couche de capacités.

1. Couche de page

Responsable de :

• Structure
• Combinaison de composants
• Cartographie de l’état de la page

2. Couche d’état

Responsable de :

• Statut de l’entreprise
• Processus asynchrones
• Changement d’état sémantique de page

3. Couche de capacités

Responsable de :

• réseau
• Stockage
• Services de domaine
• Composants communs et capacités de style

Ces trois couches ne peuvent pas nécessairement être démantelées très finement dès le début, mais la prise de conscience doit être là en premier. Sinon, les projets SwiftUI peuvent facilement se glisser dans “tout écrire directement dans la vue”.

3. Je me méfierai beaucoup des « vues géantes »

Écrire une interface utilisateur dans SwiftUI est très simple, donc l’une des mauvaises odeurs les plus courantes est :

• La structure est écrite en View
• La demande est écrite dans View
• Le jugement de statut est écrit dans View
• L’assemblage de rédaction est également écrit dans View

Bien sûr, cela semble très rapide au début, mais une fois que le projet devient complexe, la Vue deviendra rapidement :

• Difficile à lire
• Difficile de changer
• Imprévisible

Le problème ici est que View assume trop de responsabilités de non-affichage.

4. Je vais délibérément ralentir la réutilisation des composants au lieu de faire des efforts difficiles au début.

Il est facile pour de nombreuses équipes de rechercher au début une « bibliothèque de composants universelle ». Mais dans les projets réels, faire une abstraction trop tôt est souvent plus dangereux que de faire une abstraction plus tard :

• L’interface sera conçue pour être trop large
• De nombreuses options sont préparées pour des scénarios futurs possibles
• Les composants semblent être réutilisés, mais en réalité celui qui les utilise se sentira mal à l’aise

Je préfère donc d’abord laisser le composant se développer sur une ou deux pages réelles, puis l’extraire une fois que le modèle est suffisamment stable. Les composants ainsi extraits sont généralement plus proches d’une utilisation réelle que la gymnastique abstraite.

5. Les frontières des États sont généralement plus importantes que la structure des répertoires

De nombreux projets passent beaucoup de temps à discuter au début :

• Fonctionnalité d’abord ou couche d’abord
• Comment diviser les dossiers

Bien sûr, ces éléments sont importants, mais ce qui m’importe le plus, c’est :

• Quel statut est géré par la page elle-même ?
• Quels états sont gérés par des objets métier externes
• Quel statut doit être partagé et lequel ne doit pas être partagé

Car ce qui détermine réellement les coûts de maintenance, c’est souvent la question de savoir si le statut est en bon état.

6. Le cœur de la maintenabilité est en fait de laisser chaque couche “expliquer clairement de quoi elle est responsable”

Si un projet devient de plus en plus difficile à modifier par la suite, les signes suivants apparaissent généralement :

• La structure de la page n’affiche pas la priorité
• L’attribution du statut devient de plus en plus floue
• Les limites des composants deviennent de plus en plus abstraites
• Une fois les exigences modifiées, la logique doit être complétée sur plusieurs niveaux

Ainsi, pour un projet SwiftUI maintenable, ce que j’apprécie le plus est généralement :

• La page peut être lue d’un seul coup d’œil
• Le statut peut être distingué en un coup d’œil
• Les limites des composants sont naturelles -La logique métier n’est pas empilée dans View

Ces quatre choses sont très simples, mais extrêmement précieuses à long terme.

7. Conclusion : lors de la création d’un projet SwiftUI à partir de zéro, ce qui doit vraiment être défini correctement en premier, c’est la limite, pas le modèle.

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

Pour créer un projet SwiftUI maintenable à partir de zéro, le plus important est de définir correctement les limites des États, les responsabilités des pages et l’abstraction des composants.

Une fois ces limites établies, le projet deviendra plus long et plus stable ; Si les limites ne sont pas établies, aussi avancé que soit le modèle, il peut facilement être emporté par les affaires réelles.