Descripción del mantenimiento de activación/desactivación de funcionalidad

Completado

La activación/desactivación de funcionalidad es simplemente código. Y para ser más concretos, código condicional. Agrega complejidad al código y aumenta la deuda técnica.

Tenga en cuenta esto al escribirlas y limpiarlas cuando ya no las necesite.

Aunque las marcas de característica pueden ser útiles, también pueden presentar muchos problemas propios.

La idea de un botón de alternancia es que es de corta duración y solo permanece en el software cuando es necesario publicarlo para los clientes.

Puede clasificar los distintos tipos de alternancias en función de dos dimensiones, como describe Martin Fowler.

Afirma que se puede examinar la dimensión de cuánto tiempo debe estar un botón de alternancia en el código base y, por otro lado, lo dinámico que debe ser.

Planificación de los ciclos de vida de las marcas de característica

A switch in the on position triggers a flag, if this, else that.

El aspecto más importante que recordar es que debe quitar los alternancias del software.

Si no lo hace, se convertirán en una forma de deuda técnica si las mantiene durante demasiado tiempo.

En cuanto se introduce una marca de característica, se agrega a la deuda técnica general.

Como sucede con otros casos de deuda técnica, son fáciles de agregar, pero cuanto más tiempo formen parte del código, mayor será la deuda técnica porque se ha agregado la lógica de scaffolding necesaria para la creación de ramas dentro del código.

La complejidad ciclomática del código sigue aumentando a medida que agrega más marcas de característica, a medida que aumenta el número de rutas posibles desde el código.

El uso de marcas de característica puede hacer que el código sea menos sólido y también puede agregar estos problemas:

  • El código es más difícil de probar de forma eficaz a medida que aumenta el número de combinaciones lógicas.
  • El código es más difícil de mantener porque es más complejo.
  • Es posible que el código sea incluso menos seguro.
  • Puede ser más difícil duplicar los problemas cuando se encuentran.

Un plan para administrar el ciclo de vida de las marcas de característica es fundamental. En cuanto agregue una marca, debe planear cuándo la va a quitar.

Las marcas de característica no se deben readaptar. Se han generado errores de alto perfil porque los equipos han decidido reutilizar una marca antigua que pensaban que ya no formaba parte del código para un nuevo propósito.

Herramientas para la administración de marcas de versión

La cantidad de esfuerzo necesario para administrar las marcas de característica no se debe infravalorar. Es esencial considerar el uso de herramientas que realicen el seguimiento de lo siguiente:

  • Qué marcas existen.
  • Qué marcas están habilitadas en qué entornos, situaciones o categorías de clientes de destino.
  • El plan para cuándo se usarán las marcas en producción.
  • El plan para cuándo se eliminarán las marcas.

El uso de un sistema de administración de marcas de característica le permite obtener las ventajas de las marcas de característica a la vez que minimiza el riesgo de aumentar en exceso la deuda técnica.

Azure App Configuration ofrece un administrador de características. Vea Administrador de características de Azure App Configuration.