Feature flags resolvem um problema real: desacoplar deploy de release, de forma que uma mudança possa ficar em produção, escondida, até alguém decidir que está pronta pros usuários. Isso é uma melhoria genuína sobre "faz merge na main e reza". A parte que fica de fora do discurso de venda é o que acontece com a flag depois que a funcionalidade vai ao ar.
A flag que nunca teve data pra sair
Uma flag é criada com um propósito claro e, implicitamente, uma expiração clara: uma vez que a funcionalidade esteja totalmente liberada e estável, a flag e o caminho de código antigo que ela protege deveriam desaparecer os dois. Na prática, essa etapa de remoção compete por prioridade com tudo mais no backlog, e geralmente perde — a funcionalidade funciona, o ticket é fechado, e a flag silenciosamente vira permanente. Ninguém decidiu isso de propósito. É só o que acontece quando "remover a flag" não é trabalho de ninguém em particular.
O custo não é a flag, são as combinações
Uma flag é um único if. O custo real aparece conforme mais delas se acumulam: cada flag adicional dobra o número de caminhos de código que uma mudança poderia teoricamente atingir, e quase ninguém testa todas as combinações. Um bug que só reproduz com a flag A ligada e a flag B desligada é um bug funcionalmente invisível até que um cliente específico, com aquela combinação específica, esbarre nele em produção — e nessa altura, o engenheiro que escreveu qualquer uma das duas flags pode nem lembrar mais que elas interagem.
Trate a flag como empréstimo, não como compra
Os times que mantêm isso sob controle costumam fazer uma coisa pouco glamorosa: anexam um ponto esperado de remoção à flag no momento em que ela é criada, não depois. Pode ser uma data, um limiar de porcentagem de rollout, ou um ticket vinculado que faz parte do mesmo bloco de trabalho da funcionalidade — não uma tarefa de limpeza "algum dia". Uma flag sem dono e sem expiração deixa de ser rede de segurança; vira uma segunda versão escondida do seu código que ninguém se ofereceu pra manter.
A lição
Uma feature flag é dívida com juros — cada dia extra que ela vive além do seu propósito útil é mais um dia em que alguém precisa segurar dois caminhos de código na cabeça pra raciocinar corretamente sobre o sistema. A flag em si não é a parte arriscada. Esquecer que ela existe, é.
Vamos conversar?
Tem um projeto, uma vaga ou só quer trocar uma ideia sobre o assunto? Envie uma mensagem.
Entrar em contato