Por qué nombrar bien los flags
Un proyecto sin convención termina con flags como NEW_FLOW_2,
fix_thing y tmp_test_remove. Tres meses después nadie sabe qué
hacen. Nombrar con disciplina convierte cada flag en algo legible incluso cuando el autor
original ya no está.
Los cuatro tipos según Pete Hodgson
El framework más usado divide los flags en cuatro categorías: Release (esconden trabajo en progreso), Experiment (A/B testing), Ops (kill switches, throttling), Permission (acceso por plan o rol). Cada uno tiene ciclo de vida y criterios de eliminación distintos.
Estructura recomendada
<tipo>.<área>.<descripción-corta>. Ejemplos:
release.checkout.new-payment-flow,
experiment.search.relevance-v2,
ops.queue.disable-batching,
permission.billing.beta-pricing.
Convención de caso
dot.case es popular en LaunchDarkly y Flagsmith. kebab-case en archivos de config. SCREAMING_SNAKE_CASE es típico para flags como variables de entorno. camelCase aparece en configs en JS. La regla es: una sola convención por proyecto, sea cual sea.
Qué evitar
- Nombres en negativo:
disable_old_checkoutobliga a pensar al revés. - Nombres genéricos:
new_thing,fix. - Iniciales del autor:
jp_test. - Tickets:
JIRA-1234sólo. Quién lee el código no abre el ticket.
El plan de eliminación
Cada flag debería nacer con fecha de muerte. Release: se elimina tras rollout exitoso al 100%. Experiment: tras la decisión y publicación de resultados. Ops: pueden vivir indefinidamente. Permission: viven mientras la feature exista.
Auditoría con tags
Plataformas como LaunchDarkly y Unleash permiten taggear flags con responsable, equipo, ticket de creación y fecha esperada de baja. Una vez por trimestre, una auditoría lista flags con más de N días: o se eliminan o se documenta por qué siguen vivos.
Naming colisiones
Si tu producto tiene varios sub-equipos, prefijá con la unidad de negocio:
web.checkout.flow-v2, mobile.checkout.flow-v2. Los flags
compartidos entre frontend y backend deberían tener nombres idénticos para que el debug
cruzado sea trivial.