Hasta hace poco, Dropbox tenía una estrategia técnica para usar código C ++ común para aplicaciones móviles iOS y Android. La idea es clara: escriba el código una vez en C ++ en lugar de duplicarlo por separado en Java y el Objetivo C. Adoptamos esta estrategia en 2013, cuando el grupo de ingenieros de desarrollo móvil era relativamente pequeño y tuvo que desarrollar rápidamente el producto. Tal solución permitió producir una gran cantidad de código tanto en Android como en iOS por las fuerzas de un pequeño equipo.
Ahora hemos abandonado por completo esta estrategia en favor de los idiomas nativos de cada plataforma (principalmente Swift y Kotlin, que no existían cuando comenzamos). La solución implica los (no tan) costos ocultos de compartir código.
Todos los problemas se derivan de lo principal: la
sobrecarga resultó ser algo más que escribir el código dos veces .
Antes de analizar los diversos tipos de gastos generales, me gustaría aclarar que nunca llegamos al punto en que la mayor parte del código base estaba en C ++. Los costos en realidad nos impidieron movernos en esa dirección.
También vale la pena señalar que compañías mucho más grandes como Google y Facebook han estado desarrollando soluciones escalables de intercambio de código durante varios años. Tales soluciones no son muy comunes. Aunque los sistemas de terceros como React Native o Flutter evitan algunos de los gastos generales, quedan algunos costos (al menos hasta que una de estas tecnologías se vuelva popular y lo suficientemente madura). Por ejemplo,
Airbnb se negó a usar React Native por muchas de las mismas razones que se describen en este artículo.
Todos los costos se pueden agrupar en cuatro categorías principales.
Sobrecarga de marcos y bibliotecas personalizadas
La forma más fácil de predecir los costos de crear marcos y bibliotecas. Se dividen aproximadamente en dos subcategorías:
- Marcos que le permiten interactuar con el entorno del host para crear una aplicación móvil completa. Por ejemplo:
- Djinni , una herramienta para crear declaraciones entre idiomas de tipos de conexión e interfaces
- Un marco para realizar tareas en segundo plano contra el hilo principal (trivialmente en los idiomas nativos de la plataforma)
- Bibliotecas para reemplazar estándares de idiomas o soluciones de código abierto que podrían usarse en idiomas nativos, por ejemplo:
- json11 para (des) serializar JSON
- nn punteros no nulos para C ++
Nada de esto es necesario si permanece en los idiomas nativos de la plataforma. Y nuestra participación en proyectos de código abierto en idiomas nativos probablemente sería más beneficiosa para los desarrolladores. En la comunidad de C ++, la cultura de código abierto era (¿y no es así?) No tan desarrollada como en la comunidad de desarrolladores de dispositivos móviles, sobre todo porque la comunidad de
dispositivos móviles de C ++ prácticamente no existe.
Tenga en cuenta que estos costos son especialmente altos para C ++ (a diferencia de otros posibles lenguajes no nativos como Python o C #), porque no hay una biblioteca estándar completamente funcional. Sin embargo, solo C / C ++ tiene un compilador compatible con Google y Apple, por lo que cambiar a otro idioma causa otros problemas.
Entorno de desarrollo personalizado de gran tamaño
Existen muchas herramientas en el ecosistema móvil para mejorar la eficiencia del desarrollo. Los IDE móviles son muy funcionales, y Google y Apple han invertido muchos recursos para hacerlos ideales en sus plataformas. Alejándonos de los valores predeterminados, renunciamos a algunas ventajas. En primer lugar, la depuración del idioma nativo generalmente supera a la depuración de C ++ en el IDE de forma predeterminada.
Recuerdo especialmente un error que causó un bloqueo de la estructura de transmisión en segundo plano, lo que provocó bloqueos accidentales de la aplicación. Dichos errores son difíciles de rastrear incluso con una pila simple y estándar. Dado que el problema implicó la depuración de código de subprocesos múltiples que se ejecuta entre C ++ y Java, ¡tardó semanas en rastrearse!
Además de perder las herramientas estándar, tuve que invertir tiempo en crear mis propias herramientas para admitir código C ++ común. Lo que es más importante, se requería un sistema de compilación personalizado para crear bibliotecas que contuvieran código C ++, así como shells Java y Objective-C. Debería generar objetivos que tanto Xcodebuild como Gradle entiendan. La creación de un sistema de este tipo nos llevó muchos recursos, ya que tenía que actualizarse constantemente para admitir cambios en los dos sistemas de compilación.
Anulación de plataforma para diferencias de plataforma
Aunque iOS y Android son "aplicaciones móviles" que generalmente proporcionan las mismas funciones, existen algunas diferencias en las plataformas que afectan la implementación. Por ejemplo, cómo una aplicación realiza tareas en segundo plano. Incluso cosas similares pueden comenzar a diferir mucho con el tiempo (por ejemplo, interactuar con la cámara).
Como resultado, no puede simplemente escribir código una vez y ejecutarlo en otra plataforma. ¡Necesita pasar mucho tiempo integrando y codificando una plataforma específica, y a veces este código termina justo en el nivel C ++!
Los ahorros teóricos de escribir código solo una vez no se corresponden con la realidad, lo que inmediatamente reduce en gran medida la efectividad de este enfoque.Gastos generales para contratar, capacitar y retener desarrolladores
Por último, pero no menos importante, es el costo de capacitar y / o contratar desarrolladores para trabajar con nuestra pila muy peculiar. Cuando Dropbox comenzó a usar esta estrategia móvil, teníamos un grupo central de desarrolladores experimentados de C ++. Este grupo lanzó el proyecto C ++ y capacitó a otros desarrolladores móviles.
Con el tiempo, estos desarrolladores fueron a otros equipos y otras compañías. El resto no tenía suficiente experiencia para llenar el vacío en el liderazgo técnico, y se hizo cada vez más difícil encontrar ingenieros experimentados con experiencia relevante en C ++ que estén interesados en desarrollar dispositivos móviles.
Como resultado, nos enfrentamos a una falta real de conocimiento crítico para mantener la base del código C ++. Solo quedaban dos opciones, y cada una requería esfuerzos significativos:
- Encuentre y contrate candidatos con un conjunto de habilidades muy específico (lo intentamos sin éxito durante un año).
- Capacite a sus propios desarrolladores móviles (o C ++), lo cual es casi imposible de hacer en ausencia de personas mayores con el conjunto adecuado de habilidades para completar la capacitación. Incluso cuando el grupo principal aún no se había dispersado, los desarrolladores móviles generalmente no estaban interesados en C ++, por lo que encontrar personas para aprender también era un gran problema.
Además de la contratación, el lanzamiento de su propia pila de tecnología creó un problema de retención: los desarrolladores móviles simplemente no querían trabajar en un proyecto C ++. Esto provocó que muchos ingenieros talentosos abandonaran el proyecto en lugar de seguir sufriendo con una pila personalizada mal mantenida. En general, la comunidad de desarrolladores móviles es muy dinámica: las nuevas tecnologías y modelos aparecen con frecuencia y se implementan rápidamente. Los mejores ingenieros adoran mantener sus habilidades actualizadas.
Un producto maduro con una pila estándar no es fácil de mantener actualizado. Sacrificas la novedad por la estabilidad. Este problema aumenta significativamente si te encierras en una pila personalizada fuera del ecosistema móvil más amplio.
Conclusión
Una vez, escribir código una vez para diferentes plataformas parecía una gran oferta, pero los costos involucrados superaron sus ventajas (que en cualquier caso fueron menores de lo esperado). Al final, ya no usamos una base de código común a través de C ++ (o cualquier otra forma no estándar), sino que escribimos código en nuestros idiomas nativos para cada plataforma.
Además, queremos que nuestros ingenieros se sientan bien y puedan contribuir a la comunidad. Es por eso que hemos decidido alinear nuestra práctica con los estándares de la industria.