Refactorisez un écran en préservant son comportement

Ce cas d’usage s’applique lorsqu’un fichier SwiftUI contient tout le code d’un écran devenu si complexe que la moindre modification semble risquée. L’objectif n’est ni de repenser la fonctionnalité ni d’inventer une nouvelle architecture. Demandez à Codex de préserver le comportement et la disposition de l’écran, puis de le découper en petites sous-vues en explicitant les échanges de données. La prochaine modification sera ainsi plus facile à examiner.

Utilisez le plugin Build iOS Apps pour ce type de refactorisation. Son skill de refactorisation des vues SwiftUI recommande de privilégier MV par défaut plutôt que MVVM, de placer la logique métier dans les services ou les modèles et d’utiliser en priorité l’état local de la vue et les dépendances fournies par l’environnement. Ne conservez un modèle de vue que si la fonctionnalité en a clairement besoin.

Quelles consignes donner à Codex ?

Commencez par indiquer le fichier d’un écran précis et demandez à Codex d’en améliorer la structure tout en préservant son comportement. Incluez les consignes de refactorisation suivantes dans votre prompt :

• Réorganisez le fichier pour qu’il soit facile à parcourir de haut en bas. Présentez, dans cet ordre, les dépendances fournies par l’environnement, les propriétés stockées, les propriétés calculées qui décrivent l’état sans produire de vue, init, body, les fonctions et propriétés auxiliaires qui produisent des vues, puis les autres méthodes auxiliaires.
• Extrayez les sections qui forment un ensemble cohérent dans des types View dédiés. Limitez leurs entrées à quelques paramètres explicites, liaisons @Binding et fonctions de rappel.
• Limitez le nombre et la taille des propriétés calculées de type some View. Évitez de reconstituer un écran gigantesque en juxtaposant une longue série de fragments de vue définis par des propriétés calculées privées.
• Déplacez les actions de bouton complexes et les effets de bord hors de body, et confiez la logique métier proprement dite aux services ou aux modèles.
• Préservez la stabilité de l’arborescence de la vue racine. Placez les conditions dans les sections ou les modificateurs concernés plutôt que d’utiliser des branches if/else à la racine pour remplacer des écrans entiers.
• À chaque étape, vérifiez quelle vue possède les modèles suivis par Observation et corrigez ce point si nécessaire. Sous iOS 17 et versions ultérieures, la vue qui possède un modèle racine @Observable doit le stocker dans @State. N’utilisez les anciens wrappers d’observation que si votre cible de déploiement l’exige.

Demandez une vérification ciblée à chaque étape

Vérifiez que la refactorisation préserve bien le comportement de l’écran. Après chaque extraction significative, demandez à Codex d’effectuer la vérification la plus légère qui couvre l’écran : une compilation, un aperçu, un test ou une vérification sur simulateur. Demandez-lui ensuite de résumer les changements de structure et de préciser ce qu’il a délibérément conservé.

Conseils pratiques

Découpez l’écran avant de discuter de l’architecture

Si un écran est trop volumineux, demandez à Codex d’extraire chaque section dans une vue dédiée avant d’introduire une nouvelle couche d’abstraction. Une arborescence de vues plus courte et plus explicite suffit souvent à éviter l’ajout d’un modèle de vue.

Limitez l’interface de chaque sous-vue au strict nécessaire

Privilégiez les valeurs déclarées avec let, les liaisons @Binding et les fonctions de rappel dédiées à une seule action plutôt que de transmettre l’intégralité du modèle parent à chaque vue enfant. Vous pourrez ainsi prévisualiser plus facilement chaque section extraite et risquerez moins de la rendre à nouveau dépendante de l’écran entier par inadvertance.

Demandez à Codex de préciser ce qu’il a délibérément conservé

Pour vérifier la refactorisation, demandez à Codex d’énumérer explicitement les éléments qu’il a préservés : les règles métier, le comportement de la navigation, la persistance des données, la signification des événements et des mesures d’analyse, ainsi que la disposition de l’écran telle que l’utilisateur la voit. La revue de code sera bien plus rapide.