intive Argentina Blog

Lo que nos dejó la Swiftable 2019: Escalabilidad y Accesibilidad de proyectos

Los eventos sobre tecnología no son ninguna novedad para quienes estamos escribiendo código. Sin embargo, pocos han tenido la oportunidad de asistir a Swiftable, cuya ambición la llevó a venderse como la conferencia de Swift y desarrollo iOS más importante y de mayor escala en nuestro país.  

El evento, de dos días, contó con oradores renombrados tales como Félix Krause (creador de la herramienta Fastlane), Haiyan Ma (creadora de Undercover ^^) y Sally Sheppard (desarrolladora y consultora de accesibilidad), entre otros referentes del área. Aunque se expusieron muchos temas (algunos anecdóticos, unos técnicos y otros de naturaleza más filosófica), a continuación, hablaremos solamente sobre los que más nos llamaron a la reflexión. 

Organicemos y escalemos el proyecto 

Nos encontramos con distintos oradores, de distintas empresas, de incluso distintos países. Entre ellos identificamos un hilo común: escalabilidad y organización de proyectos grandes. 

Cuando nos referimos a proyectos grandes no hacemos hincapié a equipos de entre 10 y 15 integrantes, sino más bien a aquellos de más de 70 miembros repartidos en grupos y, muchas veces separados por grandes distancias geográficas. Todos están aportando código a la misma app, con sus respectivos procesos de code review y unit testing, entre otras cosas.  

Hoy en día, en nuestros equipos de 2-3 personas, si el commit de alguien rompe la funcionalidad de otro, no es catastróficamente grave, se puede arreglar y estar atento. Pero cuando tenés decenas de personas en el mismo proyecto, el problema toma una escala mucho mayor. ¿La solución recomendada? Fragmentar el proyecto en piezas individuales e independientes.  

Veremos algunas variables de esta propuesta, sobre las cuales, la problemática es la misma, el espíritu de la solución es igual, pero los acercamientos pueden variar. Lo que sucede es que nunca tenemos “el mejor martillo”, se trata de un proceso de mejora continua en el que las soluciones se superan unas a otras. Veamos: 

1) Dividir la app en múltiples proyectos – Con este enfoque, cada sección del proyecto se puede compilar individualmente, por lo que el tiempo de compilación se puede reducir sustancialmente. ¿A cuántos de nosotros nos pasó que Xcode tarde más de 5 minutos en compilar porque tiene que volver a indexar todo? Imagínense cómo debe ser para una app con un code base de miles de líneas. Además, al separar la app en módulos, se reducen los riegos de irrumpir el código de otras partes de la app.  

2) Pods – Esto, a nuestro parecer, es una forma aún más avanzada y compleja del ítem anterior. La app no solo está dividida en proyectos, sino que también esta divida en dependencias. No solamente hace que el código esté desacoplado, sino que también vuelve a sus componentes versionables. Supongamos que un commit daña seriamente el funcionamiento de un componente de la aplicación y se tiene que revertir de forma urgente, para no bloquear al resto del equipo. Con solo bajar el número de versión de ese componente en el pod file, se hace el revert de forma instantánea sin tener que hacer malabares con reverts de git. 

3) Feature Flags – Esta filosofía consiste en que todas las funcionalidades de la aplicación deberían poder ser remotamente desactivadas. Esto refuerza la idea de componentes independientes y de que, de haber un problema en producción, se pueda suprimir de forma inmediata hasta re-subir un arreglo.  

Lo cierto es que, todos los enfoques que vimos anteriormente aportan mayor complejidad y overhead, sin mencionar más dificultad a la hora de ingresar a nuevos desarrolladores. Por este motivo, únicamente sería beneficioso aplicarlos para empresas o proyectos titánicos, en los que la app tiene cientos de funciones y flujos y, un pequeño ejército de programadores detrás de ella.  

Lo interesante de este tipo de proyectos es que, si bien no comienzan implementando estos procesos y herramientas, van evolucionando y probando hasta alcanzar el método más apropiado para cumplir sus objetivos.  

Hagámoslo accesible 

La accesibilidad es un “issue” que como programadores solemos dejar en segundo plano. Ante este asunto, la oradora Sally Sheppard expuso sobre “The accesibility API”. 

A la hora de estimar e incluso diseñar nuestras funcionalidades, es primordial considerar cómo serán utilizadas por personas con discapacidades visuales o motrices. Teniendo esto en cuenta tempranamente en el proceso de desarrollo, resulta más económico en tiempo y esfuerzo en comparación a agregarlo posteriormente. Las herramientas de inclusión de Apple no son complicadas de entender y, con un poco de esfuerzo, pueden hacer una gran diferencia para alguien que lo necesite. 

Sally explicó cuál es el funcionamiento de VoiceOver de iOS, la herramienta de Apple que está orientada a personas no videntes o con visión reducida. Para poder configurar este método de accesibilidad a los componentes necesarios, cada uno de ellos dispone de propiedades que son editables. Al activar VoiceOver, automáticamente se leen estas propiedades para saber con exactitud para qué son cada una de ellas. Las propiedades indican, entre otras cosas:  

  • Qué tipo de elemento es (por ejemplo, un botón). 
  • Qué acción realiza (si es que hace alguna). 
  • Una descripción. 

Sheppard resaltó la importancia de utilizar accesibilidad en todas nuestras aplicaciones. Nosotros, como desarrolladores, tenemos que hacer hincapié en este punto e intentar que nuestros clientes lo incluyan. Es importante poder integrar a la mayor cantidad de personas para cada uno de nuestros productos. Si logramos esto, todos salimos beneficiados. 

Para cerrar, la T del desarrollador 

Haiyan Ma, quien originalmente proviene del ámbito de la física, nos contó cómo al moverse fuera de lo académico, se encontró con que su conocimiento no era aplicable de forma práctica en casi ningún otro campo profesional, así que tuvo que formase de vuelta en otras materias más allá de su especialización original.  

De allí viene el concepto de la T del desarrollador, que representa los conocimientos que se ramifican más allá del aprendizaje base de un tema principal. La T hace referencia a no centrarse únicamente en un área sino a estar abierto a nuevos conocimientos que pueden provenir de ramas muy diferentes.  

Cuando aprendemos desarrollo, solemos centrarnos en una única tecnología, nos cerramos a aprender múltiples posibilidades y esto nos lleva por un camino muy estructurado. En cambio, si uno investiga sobre otros temas, no solamente técnicos, eso nos brinda la posibilidad de tener otros puntos de vista y experiencias que serían imposibles de obtener de otra manera. 

Desarrollar es, en parte, mantenerse actualizado de forma constante y en equilibrio entre los conocimientos duros y blandos.  Lo importante es buscar soluciones al día a día. Animarse a crear herramientas personalizadas para facilitar el testing, reducir tiempos de compilación, evitar acoplamiento de funcionalidades, buscar consenso entre el equipo sobre arquitectura y escalabilidad y fomentar la mejor productividad, ya que solo nosotros podemos y sabemos cómo solucionar los tiempos muertos y perdidos. 

En fin, la respuesta está en animarse a salir de la zona de confort, generar comunidad y vínculos con la mayor red de desarrolladores, para dar mejores soluciones al mundo del programador y enriquecer así el desarrollo IT. 

Agustín Palmeira

Agustín Palmeira es desarrollador iOS en intive desde noviembre del 2015. Estudiante de Ingeniería en Informática en la Universidad de Buenos Aires (UBA), hace una década que trabaja en el sector IT. Amante de los viajes que le permiten conocer nuevos lugares y culturas, Agustín tiene entre sus principales hobbies practicar volley, ir al cine, estudiar alemán y jugar al Pokémon Go con sus compañeros de la compañía.

Daniel Antoriano Takagaki

Daniel Antoriano Takagaki es desarrollador de software en intive desde Octubre 2012. Taka es Técnico en desarrollo de videojuegos, egresado de la Escuela Multimedial Leonardo Da Vinci. Además de desarrollarlos, también los juega, dado que el gaming es uno de sus hobbies. En la compañía, integra la brigada IOS.  

Ezequiel González

Ezequiel Gonzalez es programador de IOS en intive desde Agosto 2011. Desarrollador de videojuegos de la Escuela de Arte Multimedial Da Vinci, trabajó dos años como QA tester y un año como desarrollador de prototipos de juegos en Flash. Los hobbies de Eze son dibujar, leer y jugar videojuegos. Sumado a esto va a yoga una vez por semana y también practica ejercicio aeróbico en su casa. 

Deja un comentario