3. Feature Flag

E mais uma vez: o que diabos é isso, Sergião? Você já deve ter implementado um sistema de controle de permissões, certo? Digamos que tenhamos dois tipos de perfis: um administrador, que vê todas as funções, e um usuário comum, que tem um menu mais enxuto no frontend e algumas validações adicionais no backend ao executar determinadas requisições, correto?

A Flag de Funcionalidade é basicamente isso: criar um código dinâmico que nos permite ativar ou desativar uma funcionalidade para um público ou contexto específico.

Martin Fowler, conhecido como o pai da refatoração, escreveu um artigo muito interessante em seu blog sobre "feature toggle" (que é a mesma coisa que "feature flag"). Lá, ele usou uma imagem interessante para mostrar os vários tipos de toggles em um software.

‍

Ele menciona um tipo específico de toggle que quero destacar aqui, chamado de "Release Toggles" (Toggles de Lançamento). Fowler afirma que esse tipo de toggle pode durar dias ou até semanas e geralmente só muda com uma nova implantação ou ao modificar alguma configuração em tempo de execução. Ele começa sua explicação com a seguinte introdução, que traduzi aqui para vocês:

"Essas são flags de funcionalidade usadas para permitir o desenvolvimento baseado em troncos para equipes que praticam a Entrega Contínua. Elas permitem que recursos em andamento sejam verificados em um branch de integração compartilhado (por exemplo, master ou trunk) enquanto ainda permitem que esse branch seja implantado na produção a qualquer momento. Os Toggles de Lançamento permitem que trechos de código incompletos e não testados sejam enviados para a produção como código latente, que pode nunca ser ativado."

O "papai" Fowler (o equivalente ao "papai" LeBron James, mas para programadores) resume exatamente o ponto ao qual quero chegar: as flags de funcionalidade são usadas para habilitar o desenvolvimento baseado em troncos, a fim de alcançar a entrega contínua.

Mas, Sergião, não entendi como aplicar isso na prática. Como fazemos?
‍

‍Como aplicar a Feature Flag na prática?
‍

Existem várias maneiras de usar isso, algumas das quais você pode já estar fazendo sem perceber.

Por exemplo, quando começamos a criar uma nova rota no frontend que só pode ser acessada por quem conhece a URL, isso pode ser uma saída para a sua equipe. No backend, é a mesma coisa: criar uma nova rota para testar e validar, e depois, ou lançar uma nova versão ou substituir a rota quando tudo estiver realmente homologado.

Para os desenvolvedores mais experientes, adicionar uma verificação de ambiente pode ser uma saída - aquele belo "if"!

Você também pode usar algo mais sofisticado, como o Redis na Upstash, ou o módulo de Experimentação da Optimizely, que é gratuito e usado pela Matchbox.

Percebeu como existem várias maneiras de colocar código em produção e no branch principal, sem afetar seu cliente final?

Claro que há cenários mais críticos a serem considerados, como infraestrutura e alterações em bancos de dados, mas a ideia principal é sempre pensar em como desbloquear sua equipe para que ela possa entregar software em produção.

Inclusive, no Tech Lead Program do IFTL, eu costumo analisar caso a caso dos alunos para indicar como vencer esse bloqueio na equipe de acordo com o contexto do negócio. Além desse tema, também abordo na aula sobre Metodologias para entrega de software com qualidade:

• Metodologias ágeis
• Code review
• Shape Up
• Como escolher uma metodologia

    4. Realização de testes

Compreendo que a cultura da revisão de código pode ser algo novo para muitas pessoas. Passei vários anos sem praticá-la, e inúmeros problemas surgiram no decorrer desse período, problemas que podem estar ocorrendo também no seu ambiente de trabalho devido à falta de conhecimento sobre essas práticas. Até mesmo porque há um tempo atrás, raramente se discutia sobre esse assunto.

Da mesma forma, por muito tempo, eu mesmo negligenciei os testes. Não estou aqui para criticar ninguém, mas, como líder da equipe da Matchbox nos últimos dois anos, enfrentei uma situação em que tínhamos pouquíssimos testes, quase nenhum. À medida que nossa base de código cresceu, conseguimos alcançar um nível aceitável de cobertura de testes em alguns projetos há apenas alguns meses. Convencer as pessoas da importância dos testes e de uma revisão de código sólida é uma tarefa árdua.

No entanto, essa mudança tem feito diferença em nosso cotidiano. Recentemente, Otávio Lemos compartilhou uma postagem impactante no LinkedIn:

Concordo plenamente com essa afirmação, pois, se desejamos impactar o negócio com entregas contínuas diariamente, como podemos garantir a qualidade das mudanças que estamos fazendo sem alguma forma de suporte?

Os testes estão diretamente relacionados à revisão de código, não apenas os testes automatizados, sejam eles unitários, de integração ou end-to-end. Estou me referindo também a testar o Pull Request (PR) de maneira efetiva: baixar o branch localmente, realizar as ações propostas pelo PR e avaliar os resultados reais. Falaremos mais sobre isso posteriormente, quando discutirmos o papel do revisor Tanto os testes automatizados quanto os testes manuais desempenham papéis fundamentais no sucesso das entregas.

É crucial compreender o quão crítica é a tarefa que você está desenvolvendo e reconhecer a importância de testes automatizados que garantam os resultados esperados. Por isso, incluí este item como uma etapa anterior à revisão. Deve ser um item obrigatório na lista de verificações do revisor e estar presente na mente de todos da equipe como um elemento fundamental para o sucesso das entregas.

Conclusão

Como você deve ter notado, busquei focar nesse primeiro artigo sobre Code Review em pontos que são primordiais para ajudar a diminuir o impacto das revisões e melhorar também a percepção do time de forma geral, tanto em velocidade quanto de resultado de negócio.

Ao estabelecer esse processo,  você vai notar que conseguirá realizar experimentações mais rápidas, além de mudanças, porque processos burocráticos e as famosas subidas críticas irão diminuir ou acabar.
‍
Continuem acompanhando o Tech Hub, no próximo artigo irei falar sobre o papel do autor no Code Review. 

Esse é um tema que sempre enfatizo aos alunos do Tech Lead Program. Um líder de tecnologia só consegue crescer dentro da empresa, se conseguir delegar suas tarefas a outras pessoas, desenvolvendo as mesmas.

Confira quais são os temas que abordo no Tech Lead Program do IFTL sobre Autogestão e Produtividade:

• Gestão de tempo 
• Evitando microgerenciamento
• Autonomia com responsabilidade