5 formas probadas de usar "feature flags" en tu app
5 formas probadas de usar "feature flags" en tu app
...y como ha sido frecuente, más updates.
📅 El próximo martes 11 de Abril voy a ahondar en un libro que marcará pautas en los siguientes años.
En “Deep Work”, Cal Newport escribió la tesis de que el trabajo con concentración extendida será un diferenciador para los puestos de “economía del conocimiento” (por ejemplo el desarrollo de software).
Junto a Fabián Acuña vamos a desmenuzar las partes más relevantes de este libro. Puedes encontrar más información en la comunidad Gumroad del “Nerd From Chile”.
Una herramienta que ha ganado popularidad recientemente son los “feature flags”, una potente técnica que permite a los developers activar y desactivar características sin desplegar código nuevo.
Una de las principales ventajas es probar nuevas funciones en tiempo real y por otro lado reducir riesgos. Al activar y desactivar “feature flags”, equipos pueden minimizar el impacto de los errores y otros problemas en la experiencia del usuario. Además, los “feature flags” pueden ayudar a los equipos a aumentar la participación de los usuarios proporcionándoles una experiencia personalizada basada en sus preferencias.
Si eres completamente nuevo con este término, hay varios servicios que entregan este “super poder” y por ende, no tienes que construirlo desde 0. Te puedo recomendar Firebase, LaunchDarkly y Split, por si quieres empezar a probar.
Yo personalmente las he usado, y me han servido muchísimo para crear estrategias de lanzamiento de nueva funcionalidad, y en otros casos realizar migración de APIs donde existen cambios en el modelo, que versiones anteriores ya no soportan.
Esta semana quiero contarte de 5 estrategias probadas en que he usado “feature flags” y como me han ayudado a proporcionar flexibilidad a mi equipo.
Controlar el lanzamiento de una funcionalidad
Probar nueva funcionalidad es una de las formas más directas y obvias de usar “feature flags” en tu app. Una de los puntos de discusión que se generan aquí es como posicionar el “flag” para controlar el feature. Acá dependerá mucho de como el código esté estructurado para saber donde irá el punto de decisión.
Asumiendo que lo anterior está solucionado, probar nueva funcionalidad podría tener las siguientes metas:
Reemplazo de una experiencia de funcionalidad antigua por una nueva (más rápida, más sencilla, más potente, etc).
Obtener feedback de forma ágil de clientes o usuarios.
Limitar o expandir la experiencia a un set de usuarios debido a su ubicación o contexto cultural.
En el fondo, esta primera estrategia permite a los equipos iterar rápidamente y obtener comentarios de los usuarios que pueden ayudar incluso, a mejorar la calidad del código. Además, pueden utilizarse para probar nuevas funciones con o porcentaje mínimo de usuarios a fin de minimizar el riesgo de errores y otros problemas.
Controlar el lanzamiento de una nueva librería interna
Un caso común de apps que empiezan a escalar es el reemplazo de una librería que es reemplazada por otra mejor o una solución “in-house”. Aquí es imprescindible medir el impacto que tiene ese cambio, por ejemplo a través de la performance, tiempo carga de una vista o llamadas API.
Un prototipo en el que trabajé fue el reemplazo de una librería que se encargaba de cachear imágenes para así no usar tanto ancho de banda en la conexión a internet.
Si bien el “feature flag” te va a ayudar, ten en cuenta que para este caso de uso es bueno hacer el deploy de forma progresiva, hasta llegar a un porcentaje donde estés seguro que el reemplazo no impactó la experiencia de usuario. El loop “medir y analizar” es esencial.
Probar distintas versiones de una funcionalidad (o A/B testing)
Si has desarrollado para web, quizás hayas escuchado el término “A/B testing”. Es la técnica para presentar distintas versiones de algo al usuario final.
Con el “feature flag” es similar. Lo usarás para continuamente obtener resultados sobre una nueva sección o contenido que aún no quieres lanzar formalmente. Este técnica es de especial gusto para los equipos de marketing o producto, que quieren lanzar ágil y rápido. El feedback que obtienen será decisivo para invertir más en diseño o programación.
Un caso famoso acá es como Twitter utilizó “feature flags” para probar una nueva función que permitía a los usuarios seguir temas de la plataforma. Al activar esto para un subconjunto de usuarios, pudieron recopilar datos y determinar si la experiencia satisfacía las necesidades de los usuarios y los requisitos de rendimiento antes de ponerla a disposición de todos los usuarios.
Mejorar el rendimiento de la app
Otra forma probada de optimizar tu app usando “feature flags” es para mejorar su rendimiento. Por ejemplo para:
Desactivar funciones que consumen muchos recursos
Animaciones o algoritmos complejos
Usuarios con dispositivos de gama baja
Este enfoque puede ayudar a mejorar el rendimiento general de la app y reducir el riesgo de bloqueos. Además, los “feature flags” pueden utilizarse para probar en tiempo real nuevas funciones relacionadas con el rendimiento, como el almacenamiento en caché o la carga diferida, para garantizar que cumplen los requisitos de rendimiento.
Otra forma de optimizar es para controlar la cantidad de datos que se envían al cliente. Al desactivar data innecesaria, se mejora el rendimiento de la app al tener menos data que procesar, y se podrían ver beneficiados procesos como la sincronización de datos en tiempo real o la compresión de estos.
Preferir “continuous deployment”
Este es mi uso favorito de las “feature flags”. Cuando hagas uso de ellos de forma transversal en tus equipos, los branches en tu código del tipo “feature” o “develop” tenderán a desaparecer.
¿La razón? Los equipos ya no deben estar pensando si un feature debe ir o no en un lanzamiento o actualización. Más fácil aún, podrá ser controlado de forma remota y dinámica por el backend del servicio que estés usando.
O sea, vas a desacoplar el “deploy” del “release”.
En mi experiencia, esta estrategia remueve muchos dolores de cabeza en especial para los “product managers” que carecen de conocimiento sobre las dependencias y complejidades técnicas del código. Por el lado de los devs, la revisión será mucha más expedita y existirán menos conflictos al momento de mezclar con el brach “main/master”.
Los “features flags” son una poderosa herramienta que puede ayudar a los equipos a optimizar su aplicación de varias maneras, incluyendo la mejora del rendimiento de la aplicación, el aumento de la flexibilidad, la prueba de nuevas características y la personalización de la experiencia del usuario.
Lo mejor de todo, puedes empezar de a poco con solo una de estas formas, probar que tal funcionan y escalar a medida que tu app se haga más compleja.
En conclusión, si estás buscando entregar una experiencia de usuario única, los “features flags” serán tu mejor aliado.
Me encantaría saber que piensas sobre está técnica o si tienes una experiencia para discutir. 👇🏻
Nuevo podcast
¡Hay nuevo podcast esta semana! "Nico Capital” se unió conmigo en una conversación sobre web 3.0, política e historia. También hablamos de los riesgos de las redes sociales centralizadas y como nuevos protocolos, como Lens, van a cambiar la economía de la creación de contenido.
Quote de la semana
Otros updates
Hace unas semanas atrás, hice una encuesta en Substack, Twitter y LinkedIn sobre el tema que más te gustaría escuchar en un curso. El ganador fue “Skills comunicacionales para devs”. Ya estoy muy motivado trabajando en el.
Mañana viernes 7 y para el podcast, voy a conversar con una DevRel latina que trabaja en Github. ¿Te gustaría preguntarle algo?
Espero que esta edición te haya ayudado.
Cualquier cosa estoy acá.
Un abrazo.
Felipe
Cuéntame que te pareció esta edición: