Jusqu'à récemment, Dropbox avait une stratégie technique pour utiliser du code C ++ commun pour les applications mobiles iOS et Android. L'idée est claire: écrire du code une fois en C ++ au lieu de le dupliquer séparément en Java et Objective C.Nous avons adopté cette stratégie en 2013, lorsque le groupe d'ingénieurs de développement mobile était relativement petit et devait développer rapidement le produit. Une telle solution a permis de produire une grande quantité de code sur Android et iOS par les forces d'une petite équipe.

Nous avons maintenant complètement abandonné cette stratégie au profit des langues natives de chaque plateforme (principalement Swift et Kotlin, qui n'existaient pas au départ). La solution implique les coûts cachés (pas si) du partage de code.

Tous les problèmes proviennent de l'essentiel: la surcharge s'est avérée être plus qu'une simple écriture du code deux fois .

Avant d'analyser les différents types de surcharge, je voudrais préciser que nous ne sommes jamais arrivés au point où la majeure partie de la base de code était en C ++. Les coûts nous ont en fait empêchés d'aller dans cette direction.

Il convient également de noter que des entreprises beaucoup plus grandes telles que Google et Facebook développent depuis plusieurs années des solutions de partage de code évolutives. De telles solutions ne sont pas très courantes. Bien que les systèmes tiers tels que React Native ou Flutter évitent une partie des frais généraux, certains coûts demeurent (au moins jusqu'à ce qu'une de ces technologies devienne populaire et suffisamment mature). Par exemple, Airbnb a refusé d'utiliser React Native pour plusieurs des mêmes raisons que celles décrites dans cet article.

Tous les coûts peuvent être regroupés en quatre catégories principales.

Frais généraux des cadres et bibliothèques personnalisés

Le moyen le plus simple de prévoir les coûts de création de frameworks et de bibliothèques. Ils sont grossièrement divisés en deux sous-catégories:

• Cadres qui vous permettent d'interagir avec l'environnement hôte pour créer une application mobile à part entière. Par exemple:
  
  • Djinni , un outil de création de déclarations interlangues de types de connexion et d'interfaces
    
  • Un cadre pour effectuer des tâches en arrière-plan par rapport au thread principal (trivialement dans les langues natives de la plateforme)
  
  
• Bibliothèques pour remplacer les standards de langue ou les solutions open source pouvant être utilisées dans les langues natives, par exemple:
  
  • json11 pour (dé) sérialiser JSON
    
  • nn pointeurs non nuls pour C ++

Rien de tout cela n'est nécessaire si vous restez dans les langues maternelles de la plateforme. Et notre participation à des projets open source en langues natives serait probablement plus bénéfique pour les développeurs. Dans la communauté C ++, la culture open source n'était pas (et n'est-ce pas?) Pas aussi développée que dans la communauté des développeurs mobiles, d'autant plus que la communauté mobile C ++ n'existe pratiquement pas.

Veuillez noter que ces frais généraux sont particulièrement élevés pour C ++ (contrairement à d'autres langages non natifs possibles tels que Python ou C #), car il n'y a pas de bibliothèque standard entièrement fonctionnelle. Cependant, seul C / C ++ possède un compilateur pris en charge par Google et Apple, donc le passage à une autre langue entraîne un certain nombre d'autres problèmes.

Environnement de développement personnalisé surdimensionné

Il existe de nombreux outils dans l'écosystème mobile pour améliorer l'efficacité du développement. Les IDE mobiles sont très fonctionnels, et Google et Apple ont investi beaucoup de ressources pour les rendre idéales sur leurs plateformes. En nous éloignant des valeurs par défaut, nous renonçons à certains avantages. Tout d'abord, le débogage en langue native surpasse généralement le débogage C ++ dans l'EDI par défaut.

Je me souviens surtout d'une erreur qui a provoqué un blocage de la structure de diffusion en arrière-plan, ce qui a entraîné des plantages accidentels d'application. De telles erreurs sont difficiles à suivre même avec une pile simple et standard. Étant donné que le problème impliquait le débogage de code multi-thread s'exécutant entre C ++ et Java, il a fallu des semaines pour le suivre!

En plus de perdre les outils standard, j'ai dû investir du temps dans la création de mes propres outils pour supporter le code C ++ commun. Plus important encore, un système de construction personnalisé était nécessaire pour créer des bibliothèques contenant du code C ++, ainsi que des shells Java et Objective-C. Il devrait générer des objectifs que Xcodebuild et Gradle comprennent. La création d'un tel système nous a pris beaucoup de ressources, car il devait être constamment mis à jour pour prendre en charge les modifications des deux systèmes de génération.

Remplacement de plate-forme pour les différences de plate-forme

Bien qu'iOS et Android soient des «applications mobiles» qui fournissent généralement les mêmes fonctionnalités, il existe certaines différences dans les plates-formes elles-mêmes qui affectent la mise en œuvre. Par exemple, comment une application effectue des tâches en arrière-plan. Même des choses similaires peuvent commencer à différer considérablement au fil du temps (par exemple, interagir avec l'appareil photo).

Par conséquent, vous ne pouvez pas simplement écrire du code une fois et l'exécuter sur une autre plate-forme. Vous devez passer beaucoup de temps à intégrer et à coder pour une plate-forme spécifique, et parfois ce code se termine juste au niveau C ++!

Les économies théoriques résultant de l'écriture d'une seule fois du code ne correspondent pas à la réalité, ce qui réduit immédiatement considérablement l'efficacité de cette approche.

Frais généraux pour l'embauche, la formation et la fidélisation des développeurs

Le dernier, mais non le moindre, est le coût de la formation et / ou de l'embauche de développeurs pour travailler avec notre pile très particulière. Lorsque Dropbox a commencé à utiliser cette stratégie mobile, nous avions un noyau de développeurs C ++ expérimentés. Ce groupe a lancé le projet C ++ et formé d'autres développeurs mobiles.

Au fil du temps, ces développeurs ont rejoint d'autres équipes et d'autres sociétés. Les autres n'avaient pas suffisamment d'expérience pour combler le vide en matière de leadership technique, et il est devenu de plus en plus difficile de trouver des ingénieurs expérimentés possédant l'expérience C ++ appropriée et intéressés à développer pour les appareils mobiles.

En conséquence, nous avons été confrontés à un réel manque de connaissances critiques pour maintenir la base de code C ++. Il ne restait que deux options et chacune nécessitait des efforts importants:

1. Trouvez et embauchez des candidats avec un ensemble de compétences très spécifique (nous avons essayé sans succès pendant un an).
   
2. Formez vos propres développeurs mobiles (ou C ++), ce qui est presque impossible à faire en l'absence de personnes âgées possédant le bon ensemble de compétences pour terminer la formation. Même lorsque le groupe principal ne s'était pas encore dispersé, les développeurs mobiles n'étaient généralement pas intéressés par le C ++, donc trouver des gens pour apprendre était également un gros problème.

En plus du recrutement, la sortie de sa propre pile technologique a créé un problème de rétention - les développeurs mobiles ne voulaient tout simplement pas travailler sur un projet C ++. Cela a amené de nombreux ingénieurs talentueux à quitter le projet au lieu de continuer à souffrir avec une pile personnalisée mal entretenue. En général, la communauté des développeurs mobiles est très dynamique - les nouvelles technologies et les nouveaux modèles apparaissent fréquemment et sont mis en œuvre rapidement. Les meilleurs ingénieurs aiment garder leurs compétences à jour.

Un produit mature avec une pile standard n'est pas facile à tenir à jour. Vous sacrifiez la nouveauté pour la stabilité. Ce problème augmente considérablement si vous vous enfermez dans une pile personnalisée en dehors de l'écosystème mobile plus large.

Conclusion

Une fois, écrire du code une fois pour différentes plates-formes semblait beaucoup, mais les coûts qui y étaient associés l'emportaient sur ses avantages (qui en tout cas étaient inférieurs aux attentes). En fin de compte, nous n'utilisons plus une base de code commune via C ++ (ou toute autre méthode non standard), mais écrivons du code dans nos langues natives pour chaque plate-forme.

De plus, nous voulons que nos ingénieurs se sentent bien et puissent contribuer à la communauté. C'est pourquoi nous avons décidé de mettre notre pratique en conformité avec les normes de l'industrie.