Suponha que você deseje desenvolver um novo recurso, mas não tem certeza de que os usuários gostarão e precisa ter uma maneira de ocultá-lo sem problemas. Ou suponha que você esteja trabalhando em um novo grande recurso e deseje evitar o comprometimento de monstros. Ou você apenas deseja tornar o comportamento do site facilmente configurável. Como posso resolver todos esses problemas, leia sob o gato.
O problema
Imagine que os ciclos de desenvolvimento de sua equipe durem duas semanas e a implementação de um novo recurso exigirá 3 meses de desenvolvimento da equipe. À primeira vista, existem dois esquemas de ação possíveis:
- Crie uma ramificação separada e faça todo o trabalho nela por três meses, periodicamente fazendo pull da ramificação pai
- Use o conceito de integração contínua (integração contínua ou IC ): decomponha a tarefa e congele o código em pequenas porções
Ambas as abordagens têm vantagens e desvantagens óbvias:
Usando comutadores de recursos para resolver problemas
Esse problema é encontrado com frequência no desenvolvimento e existe uma solução elegante que permite tirar o melhor proveito das abordagens descritas acima -
alternância de recurso ou
comutador de recurso .
Essencialmente, um alternador de recursos é um sinalizador booleano armazenado no banco de dados e contém informações sobre se um recurso deve ser ativado ou não. O valor desse sinalizador pode ser recuperado do banco de dados por chave. A conveniência de usar comutadores de recursos é que eles podem ser facilmente alterados por um usuário corporativo durante o tempo de execução através do painel de administração sem a necessidade de reimplementar o aplicativo.
A seguir, é apresentado um exemplo do uso da alternância de recursos em Java:
if (configurationManager.getParameter("is.some.functionality.enabled")) {
No exemplo acima,
configurationManager é uma classe que permite recuperar o valor de um alternador de recursos específico do banco de dados por sua chave.
Além disso, com a ajuda dos comutadores de recursos, você pode exibir / ocultar certos elementos no frontend. Para fazer isso, você precisa colocar o valor do sinalizador no modelo e passá-lo para exibir, como mostrado abaixo:
@ModelAttribute("isSomeFunctionalityEnabled") public void isSomeFunctionalityEnabled() { return configurationManager.getParameter("is.some.functionality.enabled"); }
Em seguida, use o valor passado para renderizar este ou aquele código HTML:
<c:choose> <c:when test="${isSomeFunctionalityEnabled}"> <!-- Render some stuff --> </c:when> <c:otherwise> <!-- Render some other stuff --> </c:otherwise> </c:choose>
Tipos de comutadores de recursos
O conceito descrito de usar comutadores de recursos é apenas um caso de uso possível e esses comutadores de recursos são chamados de alternâncias de liberação. No total, são distinguidos três tipos diferentes de comutadores de recursos:
- alternância de liberação - permite ocultar recursos implementados de maneira incompleta durante o desenvolvimento
- alternância do experimento - interruptores para teste A / B
- alternância de permissão - recurso liga / desliga para vários grupos de usuários
Assim, usando comutadores de recursos, é possível criar duas versões diferentes do site na mesma base de código, usando bancos de dados diferentes e conjuntos diferentes de comutadores de recursos. Por exemplo, em um site europeu, faz sentido incluir todos os recursos relacionados ao GDPR, mas em um site russo você não pode fazer isso.
Problemas ao alternar recursos
Como trabalho em um projeto no qual as alternâncias de recursos são ativamente usadas, além das vantagens óbvias de usá-las, comecei a perceber problemas associados a elas:
- Testando a complexidade : quando uma nova versão é lançada, os engenheiros de controle de qualidade testam todos os recursos incluídos nela e também tentam ativá-los ou desativá-los usando comutadores de recursos. Isso requer muito tempo adicional, pois é aconselhável testar todos os tipos de combinações de sinalizadores
- A aparência do código morto : os valores de muitas alternâncias de recursos não são alterados por longos períodos de tempo ou não são alterados e, portanto, o código escrito para um valor de flag diferente se torna "morto"
- Avarias inesperadas no site : muitos dos comutadores de recursos desatualizados têm a infeliz propriedade de quebrar algo ao alterar seu valor (já que ninguém há muito verifica que eles funcionam). Como os comutadores de recursos são armazenados no banco de dados e podem ser facilmente alterados pelos usuários corporativos no painel do administrador, as quebras ocorrem frequentemente devido a uma alteração em seu valor. O desempenho dos comutadores de recursos por muito tempo não utilizados deve ser verificado primeiro em um ambiente de teste
Soluções para alguns dos problemas descritos
As seguintes ações podem ajudar a resolver os problemas acima:
- Documentação dos comutadores de recursos disponíveis: para entender qual o efeito de uma alternância de um determinado recurso e por qual chave procurá-lo no banco de dados, é necessário criar documentação detalhada com uma descrição de todos os comutadores de recursos.
- Revisão periódica dos comutadores de recursos: para evitar a aparência de código morto, remova periodicamente comutadores de recursos obsoletos e código associado
Sumário
O comutador de recursos é um mecanismo muito simples e ao mesmo tempo poderoso que permite evitar confirmações monstruosas, alterar facilmente comportamentos de aplicativos ou montar vários aplicativos diferentes na mesma base de código usando configurações de alternância de recursos diferentes.
No entanto, também vale lembrar que esse padrão de desenvolvimento tem algumas desvantagens que resultam em códigos difíceis de ler e de manter, portanto, deve-se evitar o uso excessivo desse padrão e documentar periodicamente os comutadores de recursos e as revisões para remover os não utilizados e, como resultado, limpe o projeto do código "morto".
Links úteis