Olá bem vindas e bem vindos. A nossa exploração de hoje.
Vamos falar de um conceito assim, bem importante na
engenharia de software Moderna. São as featur flags.
Já ouviu falar? Às vezes chamam de featur toggle
também. Isso mesmo, é um nome que
aparece bastante. E pra nossa conversa, a gente tá
se baseando num trecho do livro engenharia de software Moderna,
do Marco Túlio Valente. Ele explica direitinho como
funciona e porque é tão, tão útil, né?
É um ótimo material de referência, sim.
O nosso objetivo aqui é simples, entender o que são essas tais
flag, sabe? E como elas resolvem um
problemão do desenvolvimento ágil, principalmente com
deplemento contínuo, e também descobrir uns usos bem
interessantes Pra Elas. Preparados?
Então, tá, vamos começar a abrir essa caixa, vamos lá, imagina só
o cenário, equipes lançando software novo.
Não toda semana, mas todo dia, às vezes várias vezes no mesmo
dia. Isso é o tal do deployment
continuo, entrega constante. Mas aí, né, vem a pergunta, como
é que você lida com aquela funcionalidade que ainda está na
metade ou que não foi 100% testada ou que talvez pese no
desempenho? Como fazer isso sem travar todo
o fluxo de entrega para o usuário final?
É complicado. Exato.
Esse é o dilema. Antigamente, bom, a solução mais
comum era deixar essas partes incompletas em pranches
separado, sabe? Longe do código principal, o
Trump. Só que essa separação por muito
tempo acabava criando o que o pessoal chama de inferno da
integração, o integration hel. Ah, sim, aquele caos na hora de
juntar tudo de volta, né? Pois é.
Era um momento super propenso a erros, depois de semanas, às
vezes meses, com o código separado e as práticas modernas,
como integração contínua e o desenvolvimento baseado no trunk
quer dizer, integrar o código no principal o mais rápido
possível, nasceram justamente para evitar esse problemão.
E aí, nesse ponto exato que as featur flags entram como 11
luva, né? Uma solução bem elegante.
A ideia central é até que simples, você integra o código
novo no Trump, mesmo que ele não esteja pronto pra todo mundo
ver. Mas você mantém ele desligado na
produção. Por padrão, ele não roda na
prática. Como funciona?
O código novo fica dentro de uma condição, tipo um if, que checam
a variável. Essa variável é o flag.
Se o flag tá desligado, ou seja falso, o sistema simplesmente
pula aquele pedaço de código novo.
Ele tá lá no meio dos outros, mas inativo.
Pensa no interruptor de luz? Simples assim.
Enquanto a funcionalidade nova, sei lá, a busca avançada não tá
pronta para o público. O interruptor flag nova busca
fica desligado. O código tá lá integrado,
convivendo com o resto, mas não afeta ninguém na ponta.
Isso permite uma coisa chave, separar o diployment, que é
colocar o código no servidor do Elise.
Que é liberar a funcionalidade para o usuário.
São 2 coisas diferentes agora. Boa analogia do interruptor, o
livro que a gente tá usando. Ele traz um exemplo legal também
de uma página nova para um sistema.
A equipe tá refazendo uma página inteira.
Aí eles criam flag. Acho que era nova PAD no exemplo
por padrão desligado. Todo mundo vê a página antiga,
certo? Mas os desenvolvedores lá na
máquina deles ou num ambiente de teste, eles podem ligar o flag.
Quando o nova pag está ligado, o sistema carrega a versão nova
para eles poderem testar. Exato, e é importante notar uma
coisa, nesse exemplo da página, pode rolar uma duplicação de
código temporária. Ah, é?
Como assim? É, você vai ter a lógica da
página antiga e a lógica da nova convivendo ali no mesmo código
por um tempo. Mas assim, é uma duplicação
controlada, passageira. Assim que a página nova está ok,
validada, liberada para geral, aí o código antigo e o próprio
flag, novo página, são removidos.
É uma transição, sabe? Não vira dívida técnica se for
bem gerenciado. Entendi é um mal necessário e
temporário, então? Isso.
Se tiver disciplina para limpar depois isso.
Não é só teoria, né? O pessoal usa para valer.
O livro cita um estudo bem interessante, pesquisadores lá
do Canadá. Sim, de universidades
canadenses. Eles fizeram uma análise bem
profunda. Eles pegaram 39 versões do
Google Chrome num período de 5 anos 5 anos de desenvolvimento
do Chrome. É, e os números que eles acharam
são impressionantes, dão uma ideia da escala disso.
Nesses 5 anos, eles identificaram mais de 2400
feature flags diferentes no código do Chrome.
Nossa, mais de 2400 é? E a evolução é clara, a primeira
versão que eles olharam tinha 263 flags, a última já tinha
2409. Uau e o mais legal que você
comentou é a dinâmica disso, né? Exato.
O estudo mostrou que, em média, cada versão nova do Chrome
adicionavam uns 73 flags novos e removia outros 43.
Isso mostra que não é só acumular, né?
Tem um ciclo de vida, cria, usa, remove.
Com certeza esses números altos de adição e remoção eles não
indicam bagunça, pelo contrário, mostram um processo super ativo
adaptativo, novas ideias são testadas com flags validadas,
liberadas aos poucos e ponto crucial.
Os flags temporários são limpos depois?
Isso mostra maturidade na gestão, ainda mais num projeto
gigante e rápido como um navegador.
É a dá para imaginar a disciplina que precisa ter para
gerenciar isso tudo no Chrome? Mas a utilidade dos flags não
para só em esconder código em desenvolvimento, certo?
Não mesmo. Eles viram ferramentas
estratégicas importantes mesmo depois que a funcionalidade
está, digamos, pronta internamente.
Um uso muito comum nessa fase é o release Canário.
Release Canário, adoro esse nome.
Para quem não conhece, a história vem dos Mineiros, né?
Isso os Mineiros de carvão levavam canários para as Minas.
Os passarinhos são mais sensíveis a gases tóxicos.
Se tivesse algum vazamento perigoso, Canário passava mal
primeiro e alertava os Mineiros para saírem correndo a?
Analogia para o software é bem direta, você usa um featur flag
para liberar uma função nova que já está pronta, testada, mas só
para um grupo pequeno de usuários reais, tipo 1%, 2%,
talvez 5% do total. Esse grupinho funciona como o
nosso Canário. Ah, entendi se essa função nova.
Causar algum pepino inesperado, um bug que passou batido, um
consumo de memória absurdo, qualquer coisa.
O impacto fica só naquele grupo pequeno.
Você detecta o gás tóxico antes de afetar todo mundo.
É isso? Exatamente.
E o melhor, se tudo correr bem com esse grupo inicial, se a
função se mostrar estável, você usa o mesmo flag para ir
aumentando. A exposição passa para 10%,
depois 25%, 50%, sempre monitorando claro, vendas
métricas, o feedback. Até chegar em 100% é um jeito
muito mais seguro de fazer lançamento, reduz muito o risco.
Faz todo sentido, dá uma tranquilidade bem maior para
colocar coisa nova no ar, né? Com certeza.
E tem mais um uso estratégico bem forte, os testes AB.
A gente já falou deles aqui antes, mas vale conectar com os
flex. A ideia do teste AB é mostrar 2
ou mais versões de algo. Sei lá, a versão AEAB ao mesmo
tempo para grupos diferentes de usuários.
Tipo, um grupo vê o botão de comprar verde e outro grupo vê o
mesmo botão azul b pra ver qual converte mais.
Exatamente esse tipo de coisa. E os featur flag são um motor
por trás disso, eles que permitem direcionar o usuário
pra um grupo A, ou BE garantir que ele veja sempre a mesma
versão. Aí você coleta dados reais.
Quem clicou mais, quem comprou mais, quem passou mais tempo e
decide qual versão a ou b é melhor com base em dados, não só
em achismo. Entendi os flags são a
infraestrutura para poder fazer esses experimentos de forma
controlada. Isso tomar decisão baseada em
evidência. Os flags viabilizam isso em
larga escala. Bom, com tanto uso, esconder
código release Canário, teste AB.
E vendo o caso do Chrome, o número de flags pode ficar
gigante. Isso me faz pensar, como é que
as equipes gerenciam isso? Dezenas, centenas, talvez
milhares de flags? Não vira uma bagunça.
Ótimo ponto. Conforme o uso cresce, o
gerenciamento vira fundamental. O livro até menciona usar
estruturas de dados, tipo mapas ou tabelas, para guardar o
estado de cada flag ligado ou desligado e as regras.
Imagino, tipo, um lugar central onde o sistema vai lá e
pergunta, e aí, o flag, novo carrinho compras, está ativo pra
esse usuário aqui antes de rodar o código?
Serviços SAS mesmo só para gerenciar o ficture flex são
ferramentas bem sofisticadas, elas permitem segmentar o
usuário tipo. Ligar um flag só para quem está
no Brasil ou só para quem é cliente premium permitem agendar
ativação? Tem.
Painéis de controle a. Agilidade é muito maior.
A principal vantagem é poder mudar o estado de um flag
remotamente, muitas vezes por uma interface web, sem precisar
mexer no código fonte, compilar, testar, fazer deploy de tudo de
novo. OPA, isso é interessante.
Deu um problema grave com uma função nova em produção, você
entra num Painel e, pá, desliga o flag na hora ou tá fazendo um
Canário e quer aumentar de 5% pra 10?
Muda lá na hora. O teste AB acabou e a versão b
ganhou. Liga o flag da b pra 100%.
Tudo isso sem tocar no código que tá rodando.
Nossa, isso muda o jogo mesmo esse controle externo e dinâmico
é poderoso. Mas com tanto flag, a gestão
continua sendo crítica, né? Quais os riscos se o pessoal não
cuidar disso direito? Sem dúvida, o maior risco é
acumular o que chamam de dívida técnica de flags.
Se aqueles flags que eram para ser temporários de release de
experimento não são removidos depois, o código fica cheio de i
felse velho fica mais difícil de ler, de testar, de dar
manutenção e a própria lógica para decidir se um flag está
ativo ou não para alguém. Pode ficar super complexa, cheia
de regras cruzadas e virar fonte de bug.
Também precisa ter disciplina para limpar a casa.
Faz sentido. Tem que ter um processo para o
ciclo de vida do flag também, não só da funcionalidade.
O livro fala de mais algum tipo diferente de flag.
Sim, tem uma distinção útil que ele faz a maioria dos que a
gente falou, esconder. Código Canário AB são os releas
e flags, geralmente temporários para controlar o lançamento.
Mas tem outra categoria importante, os Business flags,
os flags de negócio. Flags de negócio Hum, qual a
diferença principal deles para os de release?
A diferença chave é que os Business flags normalmente não
são temporários. Eles são pensados para ser parte
mais permanente da arquitetura. São usados para gerenciar
versões diferentes do produto ou níveis de acesso ou pacotes de
função. Sabe?
Baseado em regra de negócio. O exemplo clássico é um software
com plano grátis e plano pago. Hã, tá?
As funções que só tem no plano pago podem ser controladas por
um Business flag. Exatamente a mesma base de
código serve pros 2 tipos de usuário, mas os flags ligam ou
desligam recursos, dependendo da conta do cliente.
Que interessante. Isso simplifica muito as coisas,
né? Não precisa ter 2 códigos
diferentes pra manter. Precisamente, você mantém um
código só, o que facilita a manutenção, a evolução.
Mas consegue oferecer produtos diferentes para clientes
diferentes. É a mesma técnica do if, mas com
o objetivo de negócio de longo prazo.
Entendi nossa quanta coisa dá para fazer com esses flags.
Então resumindo nossa conversa feature flag são bem mais que um
if simples no código, né? São uma ferramenta estratégica
mesmo na engenharia de software atual, permitem integrar código
direto no trunk, mesmo incompleto, separando o deploy
do release. Exato.
E além disso, como a gente viu, possibilitam lançamentos mais
seguros com o release Canário, reduzindo o risco e são a base
para experimentar e otimizar com testes AB, usando dados para
decidir. E ainda tem os Business flags
para gerenciar versões diferentes do produto com o
mesmo código. É realmente bem versátil.
Com certeza dão uma mistura de agilidade, controle e segurança
para o ciclo de vida do software.
Permitem inovar mais rápido, mas com mais confiança.
São assim fundamentais hoje em dia para quem quer entregar
software de qualidade nesse ritmo acelerado.
Bom, esperamos que essa nossa exploração sobre featurflex,
baseada lá no livro engenharia de software Moderna, tenha sido
útil, tenha esclarecido as coisas.
Foi um prazer conversar sobre isso.
Igualmente é um tópico bem relevante.
Obrigada por nos acompanhar nessa exploração, até a próxima.
Até lá?