Vous avez suivi un cours, regardé une série de vidéos sur YouTube ou lu une série d'articles sur le développement iOS, et vous vous sentez désormais prêt à écrire votre premier projet favori.

Tout d’abord, bravo ! C'est génial. Tu es cool! 💪

Deuxièmement, un projet animalier constitue un fantastique coup de pouce pour vos compétences. Lorsque vous commencez à faire quelque chose par vous-même, sans suivre les instructions, vous devez consacrer beaucoup de temps et d'efforts, beaucoup rechercher sur Google, lire des tas de nouvelles informations et essayer de les filtrer et de les adapter précisément à votre cas. Bref, c'est déjà une véritable tâche qui vous boostera cinq fois.

Cependant, la plupart des débutants ignorent les éléments essentiels (non pas par initiative, mais sans en comprendre l’importance). Au cours des six derniers mois, j'ai activement mentorat et aider les nouveaux arrivants avec leurs questions et problèmes, y compris leurs projets favoris.

J'ai identifié les 3 principaux points que vous, en tant que débutant, devriez intégrer dans votre liste d'éléments incontournables, maîtriser, comprendre et utiliser.

Niveau d'accès

Au début, presque personne ne prête attention au modificateur private . Pendant ce temps, tout le monde peut instantanément expliquer SOLID si vous le réveillez au milieu de la nuit. Après avoir lu divers articles intelligents, les gens essaient de créer un groupe de classes selon l'idée de S (responsabilité unique).

Et puis, en toute conscience, ils changent la propriété de class A de class B et vice versa.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

En général, si ce n'est toujours pas clair, voici le plan : écrivez toujours private partout, et lorsque le compilateur se plaint, réfléchissez : est-il acceptable d'accéder à cette propriété ou fonction de l'extérieur ? Et si c'est le cas, supprimez private .

Lorsque vous réfléchissez, guidez-vous avec des comparaisons réelles. Par exemple, si votre classe est un magasin, alors la propriété goods doit évidemment être accessible au client externe. Mais le moneyInCashRegister ne peut clairement être modifié que par un employé interne du magasin.

Après tout, un client ne devrait pas avoir accès à la caisse enregistreuse, même avec put , et encore moins fetch .

On pourrait dire : « Je comprends parfaitement quelle propriété peut être touchée et laquelle ne le peut pas, même sans un modificateur private ». Cependant, l'écriture de modificateurs de niveau d'accès fait partie de la conception. Je suis sûr que vous ne créeriez pas un plan pour une maison avec une porte au troisième étage donnant sur l'extérieur.

Et puis, n’oubliez pas de ne pas l’ouvrir. Après tout, il est probable que d’autres utilisent également votre code.

À propos, une situation similaire existe avec var et let . Encore une fois, utilisez toujours let sauf si vous êtes immédiatement sûr de modifier la valeur.

Simplicité architecturale

J'ai remarqué une tendance selon laquelle les débutants essaient de tout planifier à l'avance. Bien que cela soit louable, les développeurs commettent souvent des erreurs en raison de leur manque d’expérience. Ils préparent des gestionnaires trop complexes (généralement copiés à partir de StackOverflow ) avec de nombreuses méthodes compliquées, qu’ils n’utilisent finalement jamais. En conséquence, la quantité et la complexité du code augmentent.

Au lieu de ce qui semblait être un service pratique et prêt à l'emploi, notre programmeur s'est retrouvé avec seulement des problèmes et des malentendus. Il en va de même pour l'architecture.

Permettez-moi de vous parcourir brièvement l'histoire de la programmation pour vous faire comprendre mon point de vue. À la fin des années 1960, à mesure que la popularité de la programmation commençait à croître, la taille des programmes augmentait également. Comme vous pouvez le comprendre, une taille de programme plus grande signifie plus de lignes de code, ce qui entraîne une complexité et une difficulté accrues dans la compréhension du programme.

Pour résoudre ce problème, une programmation structurée a émergé – des fonctions et des procédures permettant de diviser les programmes en parties plus petites et gérables. Le code est devenu modulaire, réutilisable et plus compréhensible.

L’avènement de la structuration a conduit à une nouvelle croissance des programmes jusqu’à ce qu’ils atteignent à nouveau leurs limites en termes de taille et de complexité. Ainsi, à la fin des années 1970 et au début des années 1980, l’approche de programmation orientée objet a vu le jour. Cette solution a permis la création de systèmes flexibles et évolutifs, répondant à des tâches de plus en plus complexes.

Au cours de la décennie suivante, nous avons assisté à l’essor des jeux informatiques. La réaction aux actions des utilisateurs (clics, pressions) s'est avérée critique, conduisant à l'émergence de la programmation événementielle.

Et pour organiser le code dans les applications Web et de bureau – lorsque les mêmes données devaient être réorganisées sous différentes perspectives – le modèle MVC (c'est-à-dire séparer le modèle de sa représentation visuelle) a émergé.

Vous avez saisi l'idée principale : un problème surgit, -> une solution émerge. Problème -> Solution.

Alors pourquoi les programmeurs débutants commencent-ils désormais à appliquer des solutions (architectures) à un moment où les problèmes ne sont pas encore survenus ? Les tutoriels suggèrent immédiatement de choisir au moins un MVP. Les tâches de test pour un/deux écrans précisent toujours de NE PAS utiliser MVC.

Au cours des entretiens, une personne qui a écrit quelques projets favoris avec le même un ou deux écrans est interrogée sur les problèmes de VIPER. Comment pourrait-il connaître les problèmes s’il ne les a pas encore rencontrés ?

Les gens parlent souvent de la commodité de la testabilité dans le contexte de l’architecture, mais ils n’ont jamais écrit de tests. Et s’ils l’ont fait, cela était basé uniquement sur un didacticiel, se concentrant uniquement sur les tests unitaires sans les lier à une application réelle.

Ils peuvent expliquer le schéma MVP en termes simples, mais ils sont souvent confus lorsqu'il s'agit de protocoles portant des noms similaires, comme ViewInput et ViewOutput . Au fond, ils voient déjà tout ça comme du surcoût 🙄🤯

Conclusion : ne vous créez pas de problèmes. N'ayez pas honte de MVC. Lorsque votre contrôleur devient trop volumineux ou que vous rencontrez des inconvénients, vous comprendrez qu'il est temps de rechercher de nouvelles approches.

Simplicité de l'interface utilisateur

Le développement front-end est un paradis de dopamine pour les débutants. Vous écrivez du code et voyez immédiatement le résultat à l'écran : vous recevez votre récompense 🍭. C'est indéniablement motivant. Cependant, il y a un revers à cette médaille. Les débutants s’efforcent souvent de créer immédiatement une interface utilisateur trop complexe.

De plus, les fonctionnalités complexes ont tendance à suivre une interface utilisateur complexe. Même si SwiftUI simplifie aujourd’hui la tâche, on peut encore passer beaucoup de temps à ajouter des cloches et des sifflets sans faire de réels progrès.

J'ai appris le développement iOS dans un cours où nous formions des équipes et travaillions sur un seul projet. Dans mon équipe, un gars a suggéré de commencer le développement de notre application en choisissant les polices et les couleurs pour le mode sombre.

Dans l’ensemble, il y a consacré tout le cours, et il convient de noter que les polices et les couleurs se sont révélées fabuleuses. Cependant, le gars n’a écrit pratiquement aucune ligne de code pendant tout ce temps.

Sans aucun doute, la beauté et la fonctionnalité de votre application sont cruciales. A terme, il faudra consacrer du temps à cet aspect. Il vaut mieux commencer par quelque chose de plus simple. Développez un MVP (produit minimum viable), concentrez-vous sur les fonctionnalités les plus critiques et lancez-vous à partir de là.

Le règle 80-20 s'applique ici - créez les bases de l'application, puis ajoutez les extras. L’approche inverse conduira à se débattre avec des nuances complexes et à constamment faire face à une fonctionnalité principale qui ne cesse de se briser.

Pour les nouveaux arrivants dans le développement mobile, il existe un risque d’adopter prématurément des solutions complexes. Même si les avantages visuels du développement front-end peuvent être alléchants, il est souvent plus judicieux de commencer par un simple MVP.

Les tendances historiques suggèrent que les solutions doivent évoluer en réponse à de véritables défis.

Comprendre les principes fondamentaux et résoudre les problèmes du monde réel à mesure qu’ils surviennent sont essentiels à un développement efficace.

Également publié ici