Cómo deshabilitar el código: el interruptor de producción del desarrollador

La siguiente es una publicación invitada escrita por Carlos Schults.

Poder deshabilitar el código en producción es un poder que muchos desarrolladores desconocen. Y eso es una pena. La capacidad de desactivar algunas partes (o incluso funciones completas) del código base puede mejorar drásticamente el proceso de desarrollo de software al permitir mejores prácticas que pueden acortar los ciclos de retroalimentación y aumentar la calidad general.

Entonces, eso es lo que cubrirá esta publicación: los mecanismos que puede utilizar para realizar este apagado, por qué son útiles y cómo comenzar. Vamos a profundizar en.

¿Por qué querrías desactivar el código?

Antes de profundizar en los indicadores de funciones, explicando qué son y cómo se implementan, es posible que se pregunte: ¿Por qué la gente querría desactivar algunas partes de su código base? ¿Cuál es el beneficio de hacer eso?

Para responder a estas preguntas, debemos retroceder en el tiempo y observar cómo se desarrolló el software hace un par de décadas. ¡Es hora de una lección de historia!

La Edad Media: el infierno de la integración

Históricamente, la integración ha sido uno de los desafíos más difíciles para los equipos que intentan desarrollar software juntos.

Imagine varios equipos dentro de una organización, trabajando por separado durante varios meses, cada uno desarrollando su propia característica. Mientras los equipos trabajaban en completo aislamiento, sus versiones de la aplicación evolucionaban en diferentes direcciones. Ahora necesitan converger nuevamente en una versión única y no conflictiva. Ésta es una tarea hercúlea.

Eso es lo que significa el “ infierno de la integración ”: la lucha por fusionar versiones de la misma aplicación a las que se les ha permitido divergir durante demasiado tiempo.

Ingrese la solución: integración continua

“Si te duele, hazlo más a menudo”. Lo que este dicho significa es que hay problemas que posponemos resolver porque hacerlo es difícil. Lo que a menudo se descubre con este tipo de problemas es que resolverlos con mayor frecuencia, antes de que se acumulen, es mucho menos doloroso (o incluso trivial).

Entonces, ¿cómo se puede hacer que las integraciones sean menos dolorosas? Integre más a menudo.

Eso es, en pocas palabras, integración continua (CI): haga que sus desarrolladores integren su trabajo con un repositorio público compartido, al menos una vez al día. Haga que un servidor active una compilación y ejecute el conjunto de pruebas automatizadas cada vez que alguien integre su trabajo. De esa manera, si hay problemas, quedarán expuestos más temprano que tarde.

Cómo manejar funciones parcialmente completadas

Un desafío con el que luchan muchos equipos en CI es cómo lidiar con funciones que no están completas. Si los desarrolladores están fusionando su código con la línea principal, eso significa que cualquier desarrollo que tarde más de un día en completarse deberá dividirse en varias partes.

¿Cómo se puede evitar que el cliente acceda a funciones inacabadas? Hay algunos escenarios triviales con soluciones igualmente triviales, pero los escenarios más difíciles requieren un enfoque diferente: la capacidad de desactivar una parte del código por completo.

Banderas destacadas al rescate

Definición de indicadores de funciones

Hay muchos nombres para los mecanismos que permiten a los desarrolladores activar y desactivar una parte de su código. Algunos los llaman “alternadores de funciones” o “interruptores de apagado”. Pero “indicadores de funciones” es el nombre más popular, así que ese es el que usaremos durante el resto de esta publicación. Entonces, ¿qué son las banderas de características?

En pocas palabras, los indicadores de características son técnicas que permiten a los equipos cambiar el comportamiento de una aplicación sin modificar el código. En general, las banderas se utilizan para evitar que los usuarios accedan y utilicen los cambios introducidos por algún fragmento de código, porque aún no son adecuados para la producción por varias razones.

Deshabilitar código: ¿Cuáles son los casos de uso?

Ahora cubriremos algunos de los casos de uso más comunes para deshabilitar código en producción.

Desactivar funciones sin terminar

Como ha visto, uno de los principales casos de uso de las marcas de funciones es evitar que los usuarios accedan a funciones que aún no están listas para su uso.

De esa manera, los programadores que desarrollan funciones que son más complejas y tardan más en completarse no se ven impedidos de integrar su trabajo con frecuencia y beneficiarse de él.

Habilitar las pruebas A/B

La adopción de indicadores de características permite el uso de varias prácticas valiosas en el proceso de desarrollo de software, una de las cuales son las pruebas A/B .

El testing A/B es una técnica de investigación de la experiencia del usuario que consiste en comparar dos versiones de un sitio web o aplicación para decidir cuál conservar. Implica dividir aleatoriamente a los usuarios en dos grupos, A y B, y luego entregar una versión diferente de la aplicación a cada grupo. Un grupo podría recibir la versión de producción actual, que llamamos “control”, mientras que el segundo grupo recibiría la versión candidata para la nueva versión, llamada “tratamiento”.

Luego, los evaluadores monitorean el comportamiento de ambos grupos y determinan cuál de las versiones logró mejores resultados.

Los indicadores de funciones son una forma práctica de habilitar las pruebas A/B porque le permiten cambiar rápida y cómodamente entre las versiones de control y tratamiento de su aplicación.

Habilitación de versiones Canary

Si entrega la nueva versión de su aplicación a toda su base de usuarios a la vez, el 100 por ciento de sus usuarios se verán afectados si el lanzamiento es malo de alguna manera. ¿Qué pasaría si pudieras implementar gradualmente la nueva versión? Primero implementaría en un pequeño subconjunto de usuarios y monitorearía ese grupo para detectar problemas. Si algo saliera mal, podrías revertirlo. Si todo parecía bien, podrías lanzar gradualmente la versión para grupos más grandes. Esa es una versión canaria en pocas palabras. Es otra técnica poderosa con la que las banderas podrían ayudar.

Personalización de funciones según las preferencias de los usuarios

No es raro tener que personalizar su aplicación según las necesidades de usuarios específicos, y hay varias maneras en que los equipos de software pueden lograrlo: algunas más eficientes y otras menos (compañías que crean sucursales separadas o repositorios completos para cada cliente). se me ocurre).

Esta es otra área donde los indicadores de funciones podrían ayudar, permitiendo a los equipos cambiar dinámicamente entre diferentes versiones de la misma funcionalidad.

Deshabilitar código en producción 101

¿Cómo se deshabilita el código? Eso es lo que vamos a ver ahora, en tres fases cada vez más sofisticadas.

Primera etapa: el enfoque más básico

Comenzamos con un enfoque que es tan primitivo que tal vez no debería considerarse una característica en absoluto. Considere el pseudocódigo a continuación:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {  // return calculateAdditionalWorkHoursSameOldWay(employee, start, end);  return calculateAdditionalWorkHoursImproved(employee, start, end);}

En el código anterior, simplemente comentamos la versión anterior de algún método y la reemplazamos con una nueva versión. Cuando queremos que se utilice la versión anterior, simplemente hacemos lo contrario. (Bueno, dije que era primitivo). Este enfoque carece de una de las propiedades más fundamentales de un indicador de característica: la capacidad de cambiar el comportamiento de la aplicación sin cambiar su código.

Sin embargo, planta la semilla para enfoques más sofisticados.

Segunda etapa: sacar la decisión del código

El enfoque anterior no permitía a los desarrolladores seleccionar la versión deseada de la función sin cambiar el código. Afortunadamente, eso no es tan difícil de hacer. Primero, introducimos una variable lógica para determinar qué versión vamos a utilizar:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {  var result = useNewCalculation    ? calculateAdditionalWorkHoursImproved(employee, start, end)    : calculateAdditionalWorkHoursSameOldWay(employee, start, end);  return result;}

Luego, utilizamos algún mecanismo para poder asignar el valor a la variable desde una fuente externa. Podríamos usar un archivo de configuración:

var useNewCalculation = config[newCalculation];

Pasar argumentos a la aplicación podría ser otra opción. Lo que importa es que ahora tenemos la capacidad de modificar cómo se comporta la aplicación desde el exterior, lo cual es un gran paso hacia el marcado de funciones “verdaderas”.

Tenga en cuenta que los ejemplos de código que ve son todos pseudocódigo. Usando su lenguaje de programación favorito, no hay nada que le impida comenzar con este enfoque y llevarlo a un nivel superior. Podría, por ejemplo, utilizar clases para representar las características y patrones de diseño (por ejemplo, fábricas) para evitar declaraciones if.

Etapa 3: Gestión completa de indicadores de funciones

El enfoque anterior puede ser suficiente cuando su aplicación tiene solo una pequeña cantidad de indicadores. Pero a medida que ese número crece, las cosas empiezan a complicarse.

Primero, está el tema de la deuda técnica. Los indicadores de funciones implementados manualmente pueden crear flujos condicionales terriblemente confusos en su código base. Eso sólo empeora con la introducción de nuevas banderas cada día. Además, pueden hacer que el código sea más difícil de entender y navegar, especialmente para los desarrolladores más jóvenes, lo que es una invitación a la aparición de errores.

Otro problema es que a medida que crece el número de banderas, se vuelve cada vez más común olvidarse de eliminar las antiguas y obsoletas.

El principal problema de un enfoque propio es que no ofrece una forma sencilla de ver y gestionar todas las banderas a la vez. Es por eso que nuestra tercera y última etapa es un único consejo: en lugar de implementar su propio enfoque de indicadores de funciones, adopte un sistema de administración de indicadores de funciones de terceros .

Los indicadores de funciones son un habilitador de CI/CD

Hemos cubierto los mecanismos que los desarrolladores pueden usar para deshabilitar partes de su código base en producción sin tener que tocar el código. Esta capacidad es poderosa y permite técnicas como pruebas A/B y versiones canary, que son características distintivas de un proceso de desarrollo de software moderno y ágil.

Los nombres de las técnicas pueden variar: indicadores de funciones, alternancia de funciones, cambio de funciones, etc. La forma en que se implementan las técnicas también puede variar: desde una humilde declaración if hasta sofisticadas soluciones basadas en la nube.

Pero no importa cómo los llames, no se puede exagerar el beneficio que ofrecen estos mecanismos. Son un facilitador de la integración continua, que es esencial para cualquier organización de software moderna que quiera mantenerse a flote.