Permettez-moi de partager quelque chose avec vous. J'aime l'idée du développement multiplateforme. La possibilité d'utiliser un ensemble d'outils pour toutes mes tâches est un rêve. Qui ne voudrait pas utiliser un seul outil pour mener à bien ses tâches? Écrire une fois, courir partout? Je veux!
J'aime aussi l'idée d'une société utopique. Une société où chacun respecte les croyances des autres, a des arguments significatifs / logiques / raisonnables et se donne pour tâche de devenir meilleur qu'hier. Cependant, le monde réel est rarement aussi parfait.
Je veux l'admettre, je souhaite depuis longtemps discuter du différend entre le développement d'applications natives, multiplateformes et hybrides. Pas à cause d'un manque de motivation, mais plutôt à cause de l'espoir ou du désir qu'un jour un ensemble combiné d'outils apparaisse, ouvre les portes et offre la meilleure valeur pour la création d'applications mobiles. J'attends toujours ce jour, et cet article devrait aider à expliquer mon attachement au développement natif.
Natif, multiplateforme, hybride? Quoi?
Je pourrais élaborer sur les différences de chaque type de développement, mais comme les comparaisons entre elles peuvent se faire pendant très longtemps, je vais essayer de rendre cette partie courte.
Développement natif
En développement natif, nous utilisons des outils spécialisés pour créer des applications pour iOS ou Android. Autrement dit, il existe une base de code pour chaque plate-forme. Les boîtes à outils incluent généralement Swift / Objective-C + Xcode / AppCode pour iOS et Kotlin / Java + Android Studio pour Android.
Développement multiplateforme
Nous utilisons une plateforme / un outil qui traduit / compile / exécute votre code comme s'il s'agissait de composants natifs. Le processus diffère selon les outils que vous utilisez, mais le résultat final est que le même code s'exécute et fonctionne presque de la même manière sur les plates-formes Android et iOS.
Quelques exemples d'outils: Xamarin, React Native, Flutter
Développement hybride
En développement hybride, nous utilisons une plate-forme / un outil qui lance une WebView, qui héberge ensuite votre application. Essentiellement, cela signifie que votre application est un site Web qui s'exécute à partir de sa propre application. Une plate-forme / un outil donne généralement accès à ses propres fonctions, comme une caméra, via des plugins.
Exemples d'instruments: Cordova et Ionic
Fonctionnalités principales vs essentielles
Pour bien comprendre mon choix, je dois expliquer deux types de caractéristiques d'outil différents.
Depuis de nombreuses années, il y a un débat sur la raison pour laquelle un outil est meilleur qu'un autre. La plupart des articles traitent des caractéristiques évidentes de l'outil, telles que la taille de la base de code, le temps de développement, le nombre de plates-formes pour lesquelles vous pouvez développer des applications, etc. Ces comparaisons, j'aime appeler les «principales caractéristiques» de chaque boîte à outils. Les principales caractéristiques de l'outil sont les plus directes pour les comparer avec d'autres outils, car vous pouvez généralement voir empiriquement les différences (c'est-à-dire les vitesses de développement, le temps de construction, etc.). Ces caractéristiques préoccupent généralement la plupart des gens, mais elles n'en révèlent pas l'essence.
Pour bien comprendre les conséquences du choix d'un outil, vous devez considérer les «caractéristiques inhérentes». Ces caractéristiques sont généralement plus subtiles et leur impact est plus difficile à évaluer que les caractéristiques principales. Malheureusement, une compréhension de l'influence de ces caractéristiques ne se produit généralement qu'après avoir sélectionné un outil et investi d'importants fonds. Ces caractéristiques sont l'exhaustivité et la clarté de la documentation, la disponibilité d'outils pratiques, etc.
Prendre la bonne décision sur un outil de développement nécessite de comprendre ses caractéristiques intrinsèques.
Pourquoi choisir le développement natif
Au fil des années de développement logiciel, j'ai eu l'opportunité d'utiliser plusieurs outils pour différents projets. Habituellement, le choix des outils de développement a été fait pour moi par un ingénieur de gestion ou technique. Dès que je suis passé à la pige, j'ai décidé de décider du stack technologique.
En fin de compte, ma décision finale s'est résumée à considérer non seulement les facteurs des outils, mais aussi comment les caractéristiques inhérentes affecteront chacun de mes projets dans diverses situations au fil du temps et voici mes conclusions.
1. Une popularité constante
Quand j'ai commencé la programmation en 2013, il y avait beaucoup de voix hype Cordova et Appcelerator. Quelques années plus tard, Hype est passé à Xamarin. Quelques années plus tard, c'était déjà React Native. Maintenant? Flutter gagne en popularité.
J'ai constaté que la popularité de l'outil représente également le soutien qu'il reçoit. Si l'outil appartient à une entreprise privée, la popularité est assimilée aux ventes, ce qui entraîne une augmentation des coûts de support. Si l'outil est open source, la popularité dépend du nombre de développeurs actifs qui améliorent la base de code. La popularité peut aller et venir et influencer l'ensemble de l'écosystème de développement autour de cet outil.
Jetez un œil à ce graphique Google Trends, qui présente divers outils multiplateformes au fil du temps.
Le graphique Google Trends affiche approximativement les résultats du nombre de requêtes de recherche pour diverses technologies mobiles multiplateformes.
Bien que ce graphique soit une estimation approximative de la popularité (car il ne représente que les résultats du nombre de recherches), il donne un aperçu de ce que j'ai vécu en tant que développeur. Les entreprises et les particuliers ont tendance à utiliser ce qui est nouveau. Cela ne signifie pas nécessairement que l'outil est meilleur ou pire (car de nombreux articles plaideront pour / contre, quelle que soit la date de sortie), mais les gens passent toujours à quelque chose de plus récent.
Lorsqu'un outil est publié, il est généralement promu par la communauté du développement et est considéré comme un «avenir». Cela peut entraîner une perte de support des outils plus anciens et une atrophie lente au fil du temps.
Comparez cela au développement natif, qui est garanti de recevoir un soutien. Alors qu'Apple prend en charge iOS et Google prend en charge Android, le développement natif sera toujours pertinent. C'est pourquoi le développement natif a le plus grand écosystème de développeurs; il n'était que plus longtemps et sa popularité était constante.
Une autre considération à prendre est le transfert du projet. La probabilité que le prochain développeur ait au moins une certaine expérience dans le domaine du développement natif est assez élevée. Même s'ils ne fonctionnent pas principalement avec des outils natifs, la plupart des développeurs se sont au moins en quelque sorte liés à ces outils, ce qui est beaucoup moins probable avec les solutions multiplateformes.
2. Valeurs / vision de l'entreprise
J'entends rarement beaucoup de gens discuter de la valeur commerciale lors de la comparaison des outils de développement. J'ai posé des questions à divers développeurs et même propriétaires de l'entreprise technique, et le plus souvent, ce que j'ai reçu en retour était un regard vide. Il est important de comprendre comment la valeur commerciale est corrélée avec un outil particulier et comment elle peut fournir cette valeur.
Par exemple, prenez Xamarin. En février 2016, Microsoft a acheté Xamarin pour environ 400 à 500 millions de dollars. À cette époque, la vision de Microsoft était principalement liée au développement d'applications mobiles. Ils ont fait des progrès significatifs avec cet outil et l'ont même inclus en tant que complément prêt à l'emploi pour Visual Studio et Visual Studio pour Mac. Avance rapide de quelques années, et la vision de Microsoft est passée à l'intelligence artificielle.
Tout au long de ce changement de vision, j'ai travaillé sur un projet avec Xamarin. Pendant ce temps, je me suis familiarisé avec une plate-forme avec laquelle je devais passer d'un ensemble d'outils stable à un outil qui se dégradait lentement. Chaque mise à jour de l'outil ressemblait à une tentative, du moins de ne rien casser. Dans le meilleur des cas, tout a fonctionné comme il se doit. Dans le pire des cas, vous avez passé des heures, voire un jour ou deux, à annuler les mises à jour et à essayer de remettre votre environnement dans un état sain.
Cette lente dégradation n'est pas documentée sur la page d'accueil de Xamarin (ce qui est compréhensible), mais si vous recherchez des informations sur les forums, vous pouvez sentir que quelque chose a changé au fil du temps. Les messages sur les choses qui fonctionnaient hors de la boîte maintenant ne fonctionnent tout simplement pas, ou sur la façon dont l'expérience du développeur avec cet outil a changé. Tout cela affecte directement le coût de développement, non seulement à cause des heures brutes, mais aussi à cause de la qualité du code.
Le rodage lors de la transition vers un nouvel outil entraîne une augmentation des frais généraux et une perte de profit
J'admets que le développement natif a aussi ses problèmes ici. Par exemple, Apple essaie généralement de faire évoluer les développeurs d'une certaine manière (par exemple, en utilisant Storybords ou le modèle MVC). La boîte à outils n'est également pas toujours parfaite, donc j'utilise réellement AppCode pour la plupart de mon développement iOS. Néanmoins, Apple et Google dépensent énormément de temps et d'argent pour s'assurer que les développeurs sont à l'aise pour développer des solutions natives. Il suffit de regarder Android Jetpack, SwiftUI ou même de passer à Kotlin et Swift.
En fin de compte, Google ou Apple n'a pas la meilleure vision du monde, mais elle est cohérente. Il est peu probable que les entreprises refusent du jour au lendemain de prendre en charge leurs outils.
3. Gain de temps
Oh oui, un gain de temps. Le Saint Graal de l'efficacité du développement. Ce sujet très controversé concernant TOUT outil de développement peut créer ou détruire une entreprise. Ce sujet est au premier plan de tout projet, car il affecte directement le coût. Mais prenons un peu de recul et posons-nous une question.
Que pouvons-nous faire pour gagner du temps?
Je vais vous expliquer. Comme pour les logiciels d'entreprise, il existe généralement plusieurs façons de résoudre un problème. La décision provient principalement de la situation d'une personne ou d'une entreprise en particulier. Cela signifie que l'approche «une solution pour tous» est dangereuse; cela se rapproche également beaucoup de la mentalité «nous avons toujours fait». Malheureusement, en matière de développement mobile, une approche courante pour gagner du temps consiste à choisir un outil multiplateforme. Mais est-ce si bon? Pouvons-nous, disons, trouver une autre méthode pour résoudre le problème? Dans les affaires, il y a un dicton "Les gens sont au-dessus des processus, au-dessus des outils."
Des gens au-dessus des processus, des outils
C'est exactement ce qui doit être pris en compte lors de la prise de décision. Comment se déroule le développement entre le choix d'un outil et la création de processus / procédures ou même la création d'une approche différente du développement?
Un outil capable de résoudre une mauvaise mentalité en cours de développement?
L'outil rationalise-t-il le processus de développement?
Un processus ou une mentalité légèrement modifiée peut-il conduire à de meilleurs résultats permettant de gagner du temps?
Pouvons-nous utiliser l'infrastructure pour résoudre nos problèmes?
Ce sont toutes des questions correctes qui montrent également la complexité de la solution. Ce n'est pas aussi simple que de choisir le prochain framework multiplateforme au lieu du développement natif. Qu'est-ce qui est bon pour vous ou votre entreprise? Vous seul pouvez faire ce choix.
Étant donné que le développement natif produira un produit de meilleure qualité par défaut et sera pris en charge presque à l'infini, je choisirai cet ensemble d'outils. Mes valeurs personnelles déterminent ce choix (viser l'excellence). Le développement personnel prend vraiment plus de temps (combien plus varie). Existe-t-il un moyen de gagner du temps? Dois-je gagner du temps? Dois-je simplement rechercher des projets où le budget n'est pas un problème?
Une façon de résoudre le problème du gain de temps est de créer du code qui peut être réutilisé. Créez du code réutilisable de haute qualité qui peut être rapidement intégré et déployé sur plusieurs projets. Comme j'ai choisi une boîte à outils pour la durabilité, je peux être sûr que mon code réutilisable sera utilisable pendant un certain temps.
4. Autres inférences
Finalement, j'ai tiré de nombreuses autres conclusions avant de choisir un développement natif. Beaucoup d'entre eux ont fait dans ma carrière entière, en essayant divers outils, processus et approches. Une description de tout cela rendrait cet article incroyablement volumineux. Par conséquent, par souci de concision, je donnerai des thèses sur certains d'entre eux.
Choses que j'ai considérées avant de choisir un développement natif:
1. Temps pour le développeur d'intégration
2. Infrastructure de soutien
3. Pipelines CI / CD
4. Le coût du soutien des projets hérités
5. Couches d'abstraction = plus de marge d'erreur
6. Disponibilité des développeurs (nombre de développeurs utilisant l'outil spécifié)
7. Hiérarchie commerciale (Airbnb a une excellente série de blogs qui aborde ce sujet)
8. Dépendance de la plateforme aux plugins
9. Bonheur du développeur lors de l'utilisation de l'outil
10. Coûts de conception: nécessité de concevoir de manière à prendre en charge les deux plates-formes
11. Structure de projet personnalisée
12. Ressources de connaissances - le nombre de domaines de connaissances nécessaires (par exemple, Xamarin nécessite: + plateforme Xamarin Api, C #, fonctionnalité Android spécifique, fonctionnalité iOS spécifique et connaissance des fonctionnalités de chaque plateforme et comment elles interagissent via Xamarin.)
13. Licence + coût
14. Le paysage des systèmes d'exploitation mobiles. Par exemple: combien de temps dureront seulement 2 plateformes majeures?
Conclusions
Au cours des 2 dernières années, il a utilisé le développement mobile natif comme son principal ensemble d'outils. L'une des nombreuses raisons pour lesquelles je suis satisfait de ma décision est que j'ai pris le temps de considérer autant de subtilités que possible pour chaque outil. Je connais les avantages et les inconvénients, et cela me donne des avantages.
J'espère que cet article vous aidera à poser les bonnes questions lors du choix d'un outil. Ne prenez pas le marketing à sa valeur nominale et VEUILLEZ ne pas suivre le battage médiatique. Creusez, salissez et pensez de manière critique.