“Relativity”, M.C. Escher, 1953

Adaptando el proceso de desarrollo de software al mundo multiplataforma

En la realidad moderna estamos acostumbrados a un mundo tecnológico que abarca más de un dispositivo personal.

Recientemente leí un estudio que realizó Google (The New Multi-Screen World Study) acerca del cambio drástico de comportamiento que los consumidores de información digital hemos tenido ahora que contamos con más de una pantalla (dispositivo). Anteriormente todo nuestro trabajo se hacía en una sóla computadora personal, pero ahora que todos tenemos smartphones podemos continuar e inclusive complementar simultáneamente estas actividades con las nuevas posibilidades que ofrecen nuestros teléfonos, tablets, e inclusive televisiones.

Cada dispositivo que tenemos puede tener un propósito específico, sin embargo lo importante a observar es que todos ellos comparten la misma información. Nosotros podemos revisar nuestro correo electrónico, cuentas de banco, documentos, o redes sociales en teléfonos y también en tablets o laptops, y para lograrlo cada uno de ellos necesita una pieza de software diferente. Esto quiere decir que los desarrolladores de software ahora no sólo necesitan poner atención a una computadora personal sino también a todo lo demás, necesidad que ha terminado por exigir nuevas prácticas a la industria de desarrollo de software.

La industria no se ha terminado de adaptar a esta realidad

La mayoría de las empresas de desarrollo de software que he visto en mi carrera todavía consideran que desarrollar un producto pensando en una sola plataforma primero todavía es una buena estrategia. Vamos a analizar por qué esto es una mala idea.

Pongamos el ejemplo de una compañía de software que es contratada para desarrollar el website de un noticiero. Como naturalmente el cliente siempre tiene un presupuesto bajo para el proyecto, los ingenieros deciden concentrarse en una solución sencilla que funcione bien y minimice el tiempo de desarrollo para aumentar sus utilidades. Deciden construir todo sobre un stack simple de web server con base de datos (digamos Django/Python sobre Apache/MySQL), con mecanismos para que editores suban y editen contenido, y con el código JavaScript/HTML/CSS necesario para desplegar las noticias dinámicamente en cualquier browser. Como este stack no contempla otras plataformas, los ingenieros se dan el lujo de incluir queries de SQL a la base de datos directamente en Python y crear sus tablas pensando sólo en configuraciones para web.

Pensar en la solución más sencilla y económica para un proyecto ciertamente no tiene nada de malo, sin embargo, seguir un proceso de desarrollo similar a este corre el peligro de producir monolithic software: un sistema en el que código de interfaz de usuario y acceso a bases de datos está combinado y que además sólo considera las necesidades de una sola plataforma. Aunque se tiene la ventaja de que se termina antes el proyecto con el mínimo uso de recursos, se sacrifica completamente la flexibilidad y mantenibilidad del software hacia el futuro.

Cada plataforma tiene necesidades distintas y sigue reglas muy diferentes.

¿Qué pasa el día que el cliente, satisfecho con su website, hace la petición de un app móvil que lo complemente y le permita a sus lectores consumir noticias en sus teléfonos Android y iOS? Al evaluar lo que hay que modificar para hacer esto posible, los ingenieros de la compañía se dan cuenta que va a ser un enorme problema. Va a haber que cambiar mucha lógica de la base de datos por ser originalmente exclusiva para web, reescribir las SQL queries en Java y Objective-C/Swift porque las que ahorita funcionan están muy dentro de los componentes de Python, agregar nuevos componentes que pueden causar regresiones en web, entre muchas otras cosas. Como esto naturalmente saldrá mucho más caro de lo previsto, el cliente no está contento y es entonces cuando comienza la mutilación de features para que quepa todo en el presupuesto, deteriorando la experiencia final y el beneficio que el app traerá a los lectores. ¿Suena familiar?

Modelo old school de software monolítico a partir de una plataforma base. Cada unidad tiene un full stack y es interdependiente o repite mucha lógica que se pudiera abstraer en una capa común. Cualquier cambio o mejora en la base de datos o en web requiere una actualización en todas las plataformas.

Diversidad de plataformas

Cada plataforma tiene necesidades distintas y sigue reglas muy diferentes. Aspectos como la conectividad, ubicación geográfica, necesidades de seguridad, capacidad gráfica, poder de procesamiento, consumo de energía, disponibilidad de actualizaciones, etc. se manifiestan de formas totalmente distintas entre ellas. Por dar algunos ejemplos, un desarrollador web puede muchas veces ignorar por completo del consumo de energía de su website ya que las laptops/desktops tienen en promedio una vida de batería muy larga o un cargador accesible, sin embargo, un buen desarrollador de iOS/Android siempre debe tener la eficiencia de energía de su aplicación como una de sus principales prioridades dado que un teléfono móvil tiene vida de batería mucho menor. En web también se puede actualizar una página en el servidor y tenerla reflejada inmediatamente en todo el planeta, cuando en iOS/Android actualizar un app es mucho más tardado y depende de que usuarios bajen la nueva versión.

Es ilógico, por lo tanto, pensar que un proceso de desarrollo que funciona para una plataforma puede funcionar para otra simplemente agregando algunos nuevos elementos o adaptando componentes. Regresando a nuestro ejemplo de la compañía y el noticiero, ya es un poco más obvio que construir un app móvil a partir de un stack diseñado para web es una mala idea.

¿Cómo entonces pudieron haber modificado su proceso de desarrollo para el mundo multiplataforma?

El paso más importante es alterar el paradigma del lado invisible y muchas veces el más abstracto de nuestro software stack: el back end. El back end se sigue definiendo como la capa de acceso y almacenamiento de datos, sin embargo ahora le debemos agregar un grado de agnosticidad de las plataformas de consumo. Esto en pocas palabras significa que, en lugar de estar entrelazada con una plataforma base, ahora se enfocará en servir datos en un formato neutral que pueda ser entendido por cualquier dispositivo que quiera desplegarlos, es decir, hay que convertirla en un API.

Anteriormente, desarrollar para plataformas alternativas a web era considerado un lujo y para los usuarios un privilegio. Ahora es una necesidad.

En términos prácticos, esto implica que a los back end developers les deja de interesar cómo y bajo qué circunstancias se van a desplegar los datos que están sirviendo. Su trabajo ahora sólo consiste en almacenarlos, organizarlos, y servirlos a los clientes lo más rápido posible. Bajo esta mentalidad, se liberan también de cualquier idiosincrasia específica a una u otra plataforma que introduce lógica propensa a errores y degrada la pureza del API.

El back end se va a encargar entonces de ejecutar absolutamente todas las consultas a la base de datos (independientemente del sabor y tecnología en la que estén) y codificar los resultados en un formato que pueda ser transmitido por Internet hacia cualquier plataforma que los necesite. Se convierte también en un lugar óptimo para realizar tareas complejas de data processing (inventarios, organización, machine learning, etc.) que pueden ser aprovechadas por todas las plataformas, ya que naturalmente un data center es mucho más poderoso que un web browser o una aplicación ejecutándose en los dispositivos de los usuarios.

Para la comunicación de datos entre el API y las plataformas existen muchos formatos que facilitan el entendimiento universal. XML era el más popular hace algunos años, pero ahora ha sido sustituido por otros mucho más eficientes y robustos como JSON y Protocol Buffers de Google (mi favorito) que son apoyados por incontables librerías open source que codifican y decodifican sus mensajes entre cualquier plataforma.

Modelo de software moderno utilizando un API. Cada plataforma es independiente y utiliza los datos del API para aprovechar lo mejor de cada dispositivo.

¿Cómo afecta esto a las plataformas?

Ya habiendo definido bien el API, el client side (que abarca ahora todas las plataformas relevantes: web, iOS, Android, etc.) se puede desarrollar de forma independiente. Como ya se definió un formato estándar de comunicación de datos, se vuelve trivial leerlos e inclusive simularlos para todo tipo de pruebas. Esta separación también ayuda a modularizar equipos de desarrollo porque se elimina casi por completo la dependencia entre cada plataforma y los ingenieros se pueden enfocar en perfeccionar su producto y aprovechar su dispositivo al máximo para dar la mejor experiencia al usuario.

Pensamientos finales

Regresando a la compañía, ¿cómo iban a saber los ingenieros que les iban a pedir un app? ¿Todavía tendría sentido hacer un API para un proyecto de una sola plataforma? La respuesta es . A final de cuentas, mantener un API siempre será más sencillo y económico a largo plazo porque toda la lógica que ya discutimos estará modularizada y podrá ser actualizada por ingenieros de back end sin necesidad de tener mucho contexto de qué proyecto se está sirviendo. Los ingenieros de back end también pueden enfocarse en implementar herramientas de monitoreo constante en todos sus APIs para detectar y corregir cualquier problema en tiempo real, lo cual ayuda enormemente a la robustez y calidad de servicio en todos los productos que ofrezcan a sus clientes.

En Hacker School Monterrey tenemos como principal misión el transmitir las prácticas de desarrollo de software más relevantes para el estado de la industria el día de hoy y hacia el futuro. Por lo tanto, los planes que tenemos para nuestras generaciones de estudiantes tendrán siempre en su núcleo esta tendencia multiplataforma.

Anteriormente, desarrollar para plataformas alternativas a web era considerado un lujo y para los usuarios un privilegio. Ahora es una necesidad.

— 
Rafael Cárdenas es iOS Software Engineer en Google en el equipo de Google Maps y forma parte del consejo de la Hacker School Monterrey.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.