Clean Swift
Résonnez-vous avec l’un des éléments suivants?
- Vos contrôleurs de vue deviennent-ils massifs et difficiles à comprendre, corrigent-ils des bugs et ajoutent-ils de nouvelles fonctionnalités ?
- D’accord, vous avez déplacé la logique métier vers les modèles. Mais maintenant, vos modèles deviennent trop gros.
- Votre application utilise-t-elle un storyboard gigantesque ?
- Avez-vous déjà perdu 4 heures pour essayer de reproduire un bug, puis une semaine pour le corriger ? Et toujours nulle part? Prêt à juste le réparer?
- Ajouter une nouvelle fonctionnalité signifie une régression et plus de re, re, re-affacturage?
- Vous sentez-vous coupable lorsque votre client dit « Ça marchait »?
- Le compromis effort /avantage avec TDD n’en vaut tout simplement pas la peine.
Bien sûr, nous savons tous que le test résout tous ces problèmes. Mais vous avez essayé d’écrire des tests unitaires et vous avez abandonné.
La première raison pour laquelle les gens abandonnent le TDD et les tests est qu’ils écrivent des tests au-dessus d’une mauvaise architecture d’application.
Pensez-y. Si vous pouvez construire la plus belle maison du monde mais sur de mauvaises fondations, la maison s’effondrera. La même chose est vraie pour votre architecture d’application.
J’ai essayé à plusieurs reprises au fil des ans de travailler avec des tests unitaires (en particulier avec iOS) et j’ai échoué à trouver un moyen qui ait du sens et le fait d’une manière où le temps vs les avantages sont payants. Je sens que je l’ai trouvé dans cette Architecture.– Darren Ehlers
Mais cela ne doit pas être ainsi. Vous n’avez pas à vous en tenir à MVC. Vous êtes donc en route pour chercher quelque chose de mieux.
- Vous êtes convaincu que MVC n’est pas le moyen d’avancer.
- Vous avez donc essayé MVVM avec ReactiveCocoa, mais vous devez apprendre une nouvelle chose. Plus de dépendances, Yikes!
- Ou même VIPÈRE. Mais la configuration de toutes les interfaces dans le wireframe est si complexe. Et vous ne pouvez pas utiliser de séquences.
J’ai commencé à implémenter l’architecture Clean Swift juste pour la comparer à l’architecture VIPER d’origine. Je dois dire que vous avez fait un excellent travail avec elle et j’aime vraiment lire vos messages.–Razvan
Et si vous n’avez pas à apprendre encore un autre framework? Vous n’avez pas besoin d’ajouter de nouvelle dépendance.
Imaginez que vous puissiez reprendre le contrôle de votre code. Vous pouvez savoir rapidement et exactement où se trouvent les choses. Vous pouvez corriger les bugs et ajouter de nouvelles fonctionnalités en toute confiance. Vous pouvez décomposer votre flux d’applications en plusieurs storyboards. Et oui, vous pouvez continuer à utiliser segues. Et non, il n’y a pas de fil métallique pour vous confondre.
Enfin, vous pouvez amener les clients à dire oui au paiement du TDD et leur montrer une preuve solide de la rentabilité de leur investissement. Vous serez en mesure d’identifier en toute confiance où se trouve un bug et d’avoir une réponse sans culpabilité au commentaire le plus redouté – Cela fonctionnait auparavant.
Une bonne architecture d’application facilite les tests.
Entrez simplement votre nom et votre e-mail ci-dessous. Vous ferez un premier pas énorme pour améliorer vos compétences en développement iOS et impressionner vos pairs avec un code et des tests propres. Vous apprendrez à appliquer l’architecture propre d’Oncle Bob à vos applications iOS.
Heureux de vous avoir à bord.
Maintenant que vous vous êtes abonné, vous recevrez un lien dans votre boîte de réception pour télécharger mes modèles Clean Swift Xcode afin de générer automatiquement tous les composants pour vous. Ne perdez pas de temps à écrire le même code standard. Concentrez-vous sur l’écriture de votre logique métier.
Vos modèles fonctionnent comme un charme. Tout est très soigné et je préfère le motif d’architecture Propre à VIPER.– Augustin
Vous devriez également lire l’architecture iOS Clean Swift pour Corriger le contrôleur de vue massive pour obtenir une introduction à Clean Swift. Cet article montre les concepts en utilisant un exemple directement de l’oncle Bob lui-même. Il vous explique également comment utiliser les modèles Xcode pour générer les composants Clean Swift. Vous commencerez donc à implémenter la logique métier de votre application en un rien de temps.
Au cours des prochaines semaines, nous approfondirons également les sujets suivants:
- Appliquez Clean Swift et le cycle VIP aux exemples de codes d’Apple
- Mettez vos méthodes déléguées dans le contrôleur de vue, l’interacteur ou le travailleur
- Routeur avancé avec plusieurs storyboards
- Écrivez des tests rapides et maintenables en toute confiance pour apporter des modifications
- Une approche externe-interne des tests – de l’acceptation aux tests unitaires
- Écrivez vos propres simulacres et talons
- Plongez en profondeur dans chaque composant Clean Swift
- >
- Comparez Clean Swift, MVVM+ReactiveCocoa et VIPER
- Programmation orientée protocole et Clean Swift
- Convertissant votre projet existant pour nettoyer Swift
- Comment Clean Swift fonctionne-t-il dans un grand projet
- Extraction de code commun pour réutilisation dans les workers et les objets de service
- Comment décomposer la logique métier complexe à l’aide de workers
Si vous voulez que je pour écrire d’abord l’un de ces sujets particuliers, ou si vous avez d’autres sujets en tête, envoyez-moi un e-mail.
De plus, si vous travaillez avec Objective-C et que vous souhaitez m’aider à tester une version Objective-C des modèles Xcode, envoyez-moi un e-mail après votre abonnement.
J’aime entendre comment vous appliquez Clean Swift à vos projets iOS.
Je dois dire que l’architecture VIP se développe vraiment sur moi. À l’aide de modèles, tout devient clair et très simple, sans la sensation que l’architecture produit trop de code standard.–Mihai
