Hardcodear feature flags: lo simple suele ser lo correcto

Fuentes: It's OK to hardcode feature flags

Hardcodear feature flags, es decir, controlar la visibilidad de funcionalidades nuevas directamente en el código mediante un archivo JSON que la aplicación lee al arrancar, es la forma más sencilla, fiable y segura de gestionar esos interruptores, y por aburrida, la mejor. Frente al bombo marketing alrededor del software de gestión de feature flags, este artículo defiende que la mayoría de equipos no necesitan plataformas especializadas para unas pocas decenas de flags.

El texto describe los problemas reales de los sistemas avanzados de feature flags. Desde el punto de vista arquitectónico, son poco más que instrucciones condicionales ejecutadas en un proceso separado, con su propia infraestructura, hosting y monitorización. Desde el ciclo de desarrollo, introducen comportamiento no determinista que dificulta razonar sobre el código; los flags longevos generan deuda técnica que endurece la base de código. Desde la seguridad, amplían la superficie de ataque y de vulnerabilidad.

Añadir más piezas móviles a un sistema de software siempre merece un escrutinio para comprobar si es realmente necesario. Los flags hardcodeados eliminan buena parte de estos problemas: son simples, fiables y seguros. Basta con un archivo JSON, leído al arrancar la aplicación, revisado, probado y desplegado por el proceso habitual de desarrollo. Si un flag vive demasiado, lo correcto es convertirlo en el comportamiento por defecto y eliminarlo. Cuando un equipo necesite de verdad cambiar una funcionalidad en caliente a escala, lo sabrá, igual que ocurre con la gestión de estado en las SPAs. Optimizar de forma prematura es mala ingeniería: solo sirve para el autocomplaciente palmaditas en la espalda en una conferencia cuando un vendedor pregunta quién los usa.