Construire pour tous : Reconstruction d’application avec React Native
Par DeHub Team — 2021-07-02
Au troisième trimestre 2021, nous avons commencé à reconstruire l'application DeHub à partir de zéro dans React Native.
Décider de réécrire une demande de travail n'est pas une décision que tout le monde apprécie. La bêta était en ligne, il y avait des utilisateurs, et chaque semaine consacrée à la reconstruction était une semaine non consacrée aux fonctionnalités que les utilisateurs demandaient. Nous l'avons fait de toute façon, et c'est l'un des rares appels importants de cette période que nous n'avons jamais revisités.
Ce qui n’allait pas avec la première application
La version bêta a été conçue pour répondre à une question — les gens l'utiliseront-ils du tout — et elle y a répondu. Ce qu'il ne pouvait pas faire, c'était grandir. Expédier sur deux plates-formes signifiait maintenir deux bases de code, ce qui signifiait en pratique qu'une plate-forme prenait tranquillement du retard, et que chaque fonctionnalité coûtait environ le double de ce qu'elle devrait.
Pour une équipe de notre taille, ce n'est pas un inconvénient technique. C'est une limite à la vitesse à laquelle le produit peut évoluer.
Pourquoi React Native
La raison honnête est l'effet de levier de l'équipe. React Native permet à un petit groupe d'expédier vers iOS et Android à partir d'une base de code sans être entièrement natif deux fois, et sans les compromis d'une vue Web encapsulée — ce qui, pour une application construite autour de la vidéo et du contenu en direct, aurait été fatal.
Cela signifiait également que l'application mobile et l'application Web pouvaient partager un modèle mental, un vocabulaire de composants et, dans de nombreux cas, une logique réelle. Quatre ans plus tard, DeHub exploite une application Web React et une application mobile React Native maintenues en parallèle, et les fonctionnalités se croisent à un rythme qui ne serait pas possible si la réponse en 2021 avait été deux réécritures natives.
Les pièces qui étaient plus dures que prévu
Personne ne devrait lire ceci comme un choix sans friction :
- La vidéo est l'endroit où l'abstraction fuit. La lecture, l'audio en arrière-plan et le streaming en direct sont exactement les domaines dans lesquels vous vous retrouvez dans des modules natifs, quelles que soient les promesses du framework.
- L'intégration du portefeuille était la taxe en cours. La connexion au portefeuille mobile a été résolue plus de fois que toute autre partie de l'application, et reste l'endroit le plus courant où les nouveaux utilisateurs décrochent.
- Les réécritures prennent toujours plus de temps. La liste des choses que l'ancienne application a faites et que personne n'avait écrites le duvet n'est découvert qu'en les retirant.
Pourquoi c'était toujours juste
La reconstruction est la raison pour laquelle l'application a survécu à tout ce qui a suivi. Lorsque l 'arcade a été lancée au premier trimestre 2022, lorsque l' application de streaming est arrivée cet été-là, lorsque tout l'écosystème a été tiré en un seul d'app en 2023 — aucun de ces cas n'était un cas de boulonnage sur la version bêta. Ils ont atterri sur une fondation délibérément construite pour prendre du poids.
La leçon que nous en avons tirée n'est pas « réécrire tôt ». C'est que dès que vous pouvez nommer le plafond spécifique que votre architecture impose à l'équipe, vous payez déjà pour la réécriture que vous ayez commencé ou non.
Comment survivre à un
Deux choses ont fait que cette réécriture a fini plutôt que de décrocher, et les deux valent la peine d'être énoncées parce que la plupart des réécritures décrochent.
L'ancienne application continuait de fonctionner. Nous n'avons pas cessé d'expédier aux utilisateurs existants pendant la construction du remplacement. Cela prolonge la chronologie et supprime la pression qui produit une coupure précipitée, c'est là que les réécritures meurent généralement.
La portée était l'architecture, pas le produit. Chaque demande d'amélioration d'une fonctionnalité lors de sa reconstruction a été refusée. Une réécriture qui est simultanément une refonte a deux façons d'échouer et aucun moyen de dire laquelle se produit. Le travail d'interface a attendu jusqu'en 2024, date à laquelle il a été expédié correctement en tant que révision complète avec une amélioration du backend de 200 %.