Bonjour à tous, je m'appelle Gevorg. Je suis responsable du mobile chez Profi.ru. Je veux partager avec vous l'histoire de notre expérience avec React Native. Je vais vous expliquer comment nous avons évalué les avantages et les inconvénients du développement de React Native - en théorie et en pratique. L'article sera utile à ceux qui sont intéressés par le développement mobile multiplateforme, mais qui n'ont pas encore décidé de suivre cette voie ou non.
Accélération maximale
Tout a commencé avec le fait que nous avons décidé d'accélérer le développement de 10 fois au niveau de l'entreprise. Nous nous sommes fixé comme objectif impossible de dépasser l'horizon habituel des événements et d'essayer de nouvelles choses. Toutes les équipes de développement Profi.ru ont repris les expériences. À cette époque, l'entreprise comptait 13 développeurs mobiles natifs, dont moi et deux chefs d'équipe. Mon équipe a travaillé sur deux applications mobiles. Dans le premier, les clients recherchent des spécialistes, dans le second - des experts clients. Pour moi, cette période a été incompréhensible et émotionnellement stressante. Selon mes sentiments, nous avons fait tellement pour que tout fonctionne rapidement.
Nous avons utilisé une architecture commune tout au long du projet et surveillé la pureté du code. Générateurs utilisés qui créent tous les fichiers de module. Ils ont essayé de retirer toute la logique métier sur le backend. Nous avons mis en place CI / CD, et les applications couvertes par les tests E2E. Pour toutes ces raisons, certaines applications ont été publiées de manière stable une fois par semaine. Je ne savais pas comment accélérer le développement même deux fois. De loin à 10. Par conséquent, nous avons déterminé ce qui est important pour nous.
- Base de code unifiée. Je voulais que tous nos développeurs mobiles écrivent le même code. Dans une seule langue, sans différences de plate-forme entre iOS et Android. Nous avons donc pu accélérer de moitié le développement.
- Nouvel outil facile à apprendre. Ainsi, lors de l'expansion de l'équipe, nous n'avons pas de problèmes de recyclage ou d'embauche.
- Libérations rapides. Pour que nous puissions sortir non pas une fois par semaine, mais tous les jours.
- Mises à jour instantanées. Pour que tous les utilisateurs reçoivent immédiatement les mises à jour. Comme cela se produit actuellement dans le développement Web.
Après un bref examen, trois candidats sont apparus: React Native, Flutter, Kotlin / Native. Ni Flutter ni Kotlin Native ne peuvent être libérés rapidement. Et nous avons considéré que c'était peut-être le plus important. De plus, ces technologies étaient complètement brutes à l'époque. Nous nous sommes installés sur React Native - il peut être publié instantanément. De plus, la plupart de nos développeurs ont déjà utilisé React.
En général, j'étais négatif sur les outils multiplateformes - comme la plupart des développeurs mobiles natifs. Allez à n'importe quelle conférence mobile et parlez-en - vous serez immédiatement lapidé. J'adore cette chose moi-même :-) Par conséquent, afin de confirmer ou réfuter les craintes, nous avons mené notre enquête.
Avantages, risques et problèmes
Nous avons étudié des exemples d'utilisation de React Native dans différentes entreprises - réussies et moins bonnes. Avec Head of Dev, Borey Egorov a lu attentivement plus de trois douzaines d'articles et d'autres documents. Certains ont discuté de chaque paragraphe. À la fin de l'article - liens vers les plus intéressants. Nous avons noté les points qui peuvent nous accélérer, les risques possibles et les questions. Après cela, nous avons discuté avec des développeurs de trois sociétés. Dans chacun des gars, ils ont créé un produit de masse et travaillé avec React Native pendant au moins un an.
Avec les pros, tout était assez évident.
- Base de code générale.
- Over-the-Air, ou mise à jour par voie aérienne, contournant le magasin.
- Des deux premiers points, il s'ensuit que la vitesse de livraison des fonctionnalités aux utilisateurs augmentera.
- Les développeurs Web pourront écrire du code pour les applications mobiles. Si un développeur Web connaît bien React, il peut rapidement apprendre React Native. Et si le développeur mobile connaît déjà cette plate-forme, il peut entrer dans le développement Web relativement rapidement.
La liste des risques était plus longue :-)
Le premier risque . Au lieu d'une seule plate-forme, à long terme, nous sommes obligés d'en prendre en charge trois: Android, iOS et React Native.
Parfois, l'écran du développeur ressemble à ceci:
La réalité Un de nos interlocuteurs a injecté React Native dans le code existant. Oui, une troisième plate-forme à part entière apparaît, mais vous n'allez nulle part du développement natif. Son équipe a dû synchroniser l'état entre React Native et le code natif. Cela impliquait beaucoup de commutation entre différents morceaux de code / différents paradigmes et IDE. Par conséquent, ils ont décidé d'écrire un nouveau projet à partir de zéro, de créer un cadre sur React Native et d'y insérer déjà des éléments natifs là où ils sont nécessaires. Ça s'est amélioré.
Le deuxième risque. React Native Black Box - il arrive parfois qu'un développeur ne comprenne pas pourquoi un bogue est apparu. Vous devez rechercher partout: dans le code React Native, dans la partie native du produit ou dans la plateforme React Native elle-même.
La réalité Les gars avec qui nous avons parlé ont enveloppé l'application de journaux et d'outils divers: Crashlytics, Kibana et ainsi de suite. Des problèmes subsistent, mais il devient clair où ils surviennent.
Le troisième risque. Il a souvent été constaté dans des articles que React Native convient aux petits projets, mais pas aux grands produits dotés de fonctionnalités de plate-forme.
La réalité Nous avons cherché à savoir s'il existe de grandes entreprises sur le marché qui travaillent avec React Native. Il s'est avéré - il y en a des dizaines, sinon des centaines. Y compris Skype, Tesla, Walmart, Uber Eats et Kitchen dans la région.
Quatrième risque. Chaque fois que vous mettez à niveau votre système d'exploitation depuis Apple ou Google, le projet peut s'arrêter.
La réalité Nous avons décidé que le risque était parfaitement acceptable. Le même risque existe pour le développement natif. Lorsque le nouveau système d'exploitation pour iOS et Android sort, vous y adaptez votre application.
Le cinquième risque. Il n'y a pas de prise en charge du système 64 bits dans Android, et le problème est ouvert depuis 2015. Et depuis août 2019, Google Play n'a pas accepté les versions prenant en charge uniquement les systèmes 32 bits.
La réalité Nous avons examiné le problème sur lequel l'équipe React Native a travaillé à l'été 2018. Ils ont promis d'ajouter la prise en charge dans la prochaine version, bien qu'ils n'aient pas encore complètement pris en charge le système 64 bits. Cela a beaucoup bouleversé. La prise en charge a été ajoutée plus tard, mais certains appareils Android tombent après la transition. Comme nous l'avons découvert plus tard, le pourcentage est maigre, mais c'était quand même le point le plus douloureux pour moi.
Sixième risque. La probabilité que demain, Apple ou Google publie une nouvelle version de leur système d'exploitation et casse React Native. Ou une nouvelle technologie que Profi.ru, en principe, ne pourra pas supporter.
La réalité Il n'y a aucune garantie pour nous ou pour de nombreuses autres sociétés. Soit vous réalisez le risque et le faites, soit vous essayez autre chose. Nous avons décidé de le faire et de résoudre tous les problèmes dès qu'ils deviennent disponibles.
Septième risque. Nous ne pouvions pas dire à l'avance à quelle vitesse React Native sera comparé à l'application native et quelles performances il affichera.
La réalité La citation littérale d'un de nos interlocuteurs est "des listes d'éléments de hauteur variable lors du défilement ralenti". Nous avons décidé de vérifier dans la pratique. Un peu plus loin - au moment de la rédaction du premier prototype de l'application, nous ne voyions pas un tel problème, mais lorsque nous avons développé une application à part entière, il y avait beaucoup de questions sur les performances de React Native.
Huitième risque. On ne sait pas à quelle vitesse nous pouvons trouver des développeurs React Native. Sur HeadHunter, j'ai trouvé environ 300 CV, malgré le fait qu'il y avait plus de 150 000 développeurs pour iOS.
La réalité Ils ne sont pas allés très loin ici, car ils avaient embauché plus d'une fois des développeurs React et savaient quoi chercher. Nous avons décidé qu'en dernier recours, nous pouvons recycler les développeurs React dans React Native.
Il y avait également un risque que quelqu'un quitte l'équipe, car les développeurs mobiles n'aiment pas cette technologie. Au fait, j'avais raison. Quelqu'un est parti :-(
Je suis fatigué d'écrire React Native, donc ce qui suit est juste RN :-)
Ce que nous changeons et ce que nous ne changeons pas
Nous avons discuté des résultats de l'enquête avec les fondateurs de la société, Sergey Kuznetsov et Yegor Rudi, et obtenu le feu vert pour l'expérience.
Nous avons décidé de créer un nouveau produit à partir de zéro, et de ne pas l'insérer dans un produit existant. Et aussi - ne touchez pas à notre application client. C'était assez mature, et économiquement cela n'avait aucun sens de changer radicalement quelque chose. De plus, il était important pour nous que l'application cliente ait sa propre expérience native pour iOS et Android.
Mais nous voulions changer radicalement la demande de spécialistes. Contrairement au client, nous n'étions pas gênés que les spécialistes aient la même expérience d'interaction pour les applications iOS et Android. De plus, nous pensons que dans un produit pour spécialistes, nous pouvons nous passer d'animation et d'effets visuels. Mais avant que toute l'équipe ne passe à une nouvelle technologie, il fallait ressentir son fonctionnement.
Expérience en action
En décembre 2018, nous avons réuni une équipe de trois personnes. Deux développeurs React et un natif - moi. Je comprends le fonctionnement d'Android et je connais bien le développement iOS.
Dans le cadre de l'expérience, nous avons voulu vérifier les points suivants:
- comment fonctionnent les versions instantanées dans RN;
- comment est l'interaction entre les composants natifs et RN;
- pouvons-nous utiliser nos composants natifs;
- comment RN fonctionne avec la caméra, le push et le diplink;
- comment fonctionnent la navigation et la sauvegarde de l'état dans RN;
- autant que nous pouvons le faire avec RN pixel perfect;
- comment les tests automatiques fonctionnent dans RN;
- la rapidité avec laquelle le développeur natif ou React peut apprendre la technologie.
Nous avons obtenu les premiers résultats en un mois et demi après avoir plongé dans le développement.
- J'ai commencé à écrire du code sous RN après seulement deux semaines. Pour moi, la technologie était complètement simple. Un de nos développeurs React m'a beaucoup aidé - il a parlé de React / Redux et de JS en général. Il était nécessaire d'entrer dans les subtilités de React / Redux, mais après un certain temps, le «neurone a commencé à apprendre», comme on dit dans notre entreprise :-)
- J'ai été agréablement surpris que, sous une forme ou une autre, JS + Flow offre un typage fort. Pour JS, j'avais des attentes beaucoup plus faibles. En même temps, je préférerais certainement Swift et Kotlin: pour moi, ils sont beaucoup plus beaux et agréables que JS, mais ici les mots principaux sont «pour moi».
- Cela nous a aidés à comprendre que l'équipe comprenait des développeurs capables d'écrire du code pour iOS, Android et React. Chaque plate-forme a ses propres problèmes spécifiques. Pour les résoudre, l'équipe doit être interfonctionnelle.
- Les versions instantanées fonctionnent. Pour moi, c'est comme par magie. Pas besoin d'attendre les versions et les mises à niveau d'Apple. Recherché - pris et libéré.
- Très souvent, le projet a échoué. Ce n'est vraiment pas cool. Vous avez pris les modifications de la branche, vous essayez de courir - et tant pis. C'était très ennuyeux. À un moment donné, nous venons d'écrire un script qui nettoie complètement le projet. Cela ne veut pas dire qu'ils ont résolu le problème dans son ensemble, mais en ont terminé la majeure partie.
- Pourtant, nous devons travailler avec trois plates-formes, malgré le fait que nous écrivons principalement du code sur RN. Tous les développeurs avaient trois IDE: Xcode, Android Studio, WebStorm.
- Pushas, liens profonds, caméra, démarrage de la navigation. Mais elles commencent soit à l'aide de bibliothèques tierces, soit les bibliothèques dans le code natif doivent être écrites vous-même, puis connectées à RN.
À la fin de l'article, je veux revenir au titre. Le RN est-il donc une solution miracle pour tous les problèmes? Nous avons décidé par nous-mêmes que non. En même temps, ils ont obtenu ce qu'ils voulaient. Nous avons augmenté plusieurs fois la vitesse de livraison des fonctionnalités et nous pouvons désormais la proposer à tous les utilisateurs chaque jour. Il est également important que des équipes interfonctionnelles soient apparues dans l'entreprise, où chaque développeur écrit du code à la fois sur Android / iOS et sur le Web.
Et oui, les applications en magasin :-)
Articles utiles sur React Native
- Pourquoi Discord s'en tient à React Native - Fanghao (Robin) Chen
- Comment j'ai aimé et détesté réagissent les autochtones - Andrey Melikhov
- React Native du point de vue d'un développeur mobile - Andrey Konstantinov
- React Native sur Instagram - Instagram Engineering
- React Native: une rétrospective de l'équipe d'ingénierie mobile d'Udacity - Nate Ebel
- React Native: batailles factuelles en un acte - Samat Galimov
- Sunsetting React Native - Gabriel Peal