Domando o código rebelde: Feature Flags em projetos Kotlin

Prefácio: Por que as funcionalidades quebram os releases?

Todo desenvolvedor já se encontrou pelo menos uma vez em uma situação onde uma nova e brilhante funcionalidade já está pronta, mas não pode ser lançada. Seja porque não passou pelo QA completo, porque o marketing ainda não preparou os banners, ou simplesmente porque dá medo apertar o botão "Deploy" numa sexta-feira à noite. Nesse momento, geralmente começamos a escrever if, alternar BuildConfig ou, pior ainda, comentar o código.

Familiar? Bem-vindo ao mundo dos feature flags (ou feature toggles). Isso não é apenas "mais uma coisa arquitetural". É o seu salva-vidas, que permite enviar código para produção, mas ativá-lo apenas para alguns selecionados. Neste artigo, vamos abordar como implementar feature flags em projetos Kotlin — desde soluções simples até sistemas avançados. E sim, terá muito código.

O que é um Feature Flag e por que você precisa dele?

Feature Flag (também conhecido como feature toggle) é um interruptor de software que permite ativar ou desativar uma funcionalidade sem alterar o código e sem um novo deploy. Imagine que você pode enviar um novo algoritmo de recomendações para produção, mas ativá-lo apenas para 5% dos usuários. Ou ativá-lo apenas para funcionários da empresa para testes internos. Legal, né?

Aqui estão alguns cenários onde os feature flags são indispensáveis:

• Canary releases: Você lança uma nova funcionalidade em 1% dos servidores, monitora erros e aumenta gradualmente a porcentagem.
• Testes A/B: Você verifica qual versão da UI converte melhor, sem copiar todo o projeto.
• Kill switch: Se a nova funcionalidade começar a "consumir" memória ou causar um bug, você simplesmente a desativa com um movimento (ou uma requisição de API).
• Separação de release e deploy: O código é enviado, mas a funcionalidade "dorme" até a data X.

Em Kotlin, que é ativamente usado tanto para backend (Ktor, Spring Boot) quanto para aplicativos móveis (Android), os feature flags se tornam especialmente relevantes devido à tipagem forte e aos requisitos de limpeza de código.

Arquitetura: Como não transformar as flags em espaguete

O maior erro dos iniciantes é espalhar if (flag.isEnabled()) { ... } else { ... } por todo o projeto. Isso faz com que, depois de um mês, você não consiga entender quais ramos de código estão vivos e quais estão mortos. Precisamos de gerenciamento de funcionalidades, não de interruptores caóticos.

Uma boa arquitetura é construída com base no princípio da inversão de dependências. Seu código de negócios não precisa saber de onde vem o valor da flag (de um arquivo, banco de dados ou serviço externo). Ele simplesmente pergunta: "Ei, FeatureFlagService, a funcionalidade new_checkout está ativada?"

Vamos considerar duas abordagens: simples (para projetos pequenos) e avançada (para microsserviços e Kubernetes).

1. Abordagem simples: Configuração e Enum

Se você precisa começar rapidamente e não está construindo um sistema com um milhão de requisições por segundo, pode usar um simples enum class e um arquivo de configuração (por exemplo, application.conf para Ktor ou application.yml para Spring).

Vamos criar um enum de todas as funcionalidades:

enum class Feature(val key: String) {    NEW_PAYMENT_FLOW("feature.new-payment-flow"),    DARK_MODE("feature.dark-mode"),    SMART_SEARCH("feature.smart-search")}

Agora, o serviço que lê a configuração:

class FeatureFlagService(private val config: Map<String, Boolean>) {

    fun isEnabled(feature: Feature): Boolean {        return config.getOrDefault(feature.key, false)    }

    // Para testes A/B, podemos adicionar randomização    fun isEnabledForUser(feature: Feature, userId: String): Boolean {        if (!isEnabled(feature)) return false        // Hash simples para dividir em grupos        val group = userId.hashCode() % 100        return group < 50 // 50% dos usuár