Práticas de arquitetura / aplicação para proteger contra 'quebrar alterações'

5

Temos um aplicativo em que o cliente mudou de ideia sobre uma grande área de funcionalidade e essa área exige uma grande quantidade de retrabalho.

Embora o retrabalho em si não seja um problema, ele introduziu uma situação em que o impacto das mudanças é amplo, incluindo:

  • Dados
  • Lógica de consulta / estrutura da tabela
  • Lógica de negócios
  • Exibição / apresentação

Idealmente, gostaríamos de incorporar essas mudanças ao mesmo tempo que vários outros fluxos de desenvolvimento, mas estamos preocupados que o impacto das alterações tenha um impacto negativo na frequência com que podemos fornecer. Podemos atender a isso através de ramificações, mas isso me fez imaginar quais são as possibilidades de se proteger contra esse tipo de coisa, do ponto de vista da arquitetura de aplicativo ou da prática de desenvolvimento.

Coisas que fazemos atualmente:

  • Resumo da lógica de consulta nos repositórios - Isso é ótimo para pequenas alterações, mas quando a lógica geral em uma área muda, por exemplo, Em vez de obter uma lista de usuários que atendem a um determinado critério, precisamos agora obter uma lista de organizações que se juntaram a locais.
  • Resumo da lógica de negócios nos serviços - Isso é exatamente o mesmo que os repositórios em que não podemos realmente proteger contra mudanças lógicas inteiras, mas pequenas mudanças podem ser acomodadas com impacto limitado.
  • Certifique-se de que a configuração seja mantida fora do código que precisa ser reimplantada, uma combinação de linhas do banco de dados ou valores web.config.
  • Outros padrões que promovem aspectos de flexibilidade, como fábricas, quando apropriado, etc.
  • Sinalização de recursos para seleção de funcionalidade, caso duas abordagens tenham sido desenvolvidas originalmente. etc

Existem outras práticas recomendadas atuais para proteger contra alterações, sem incorporar ramificações, etc.?

    
por dougajmcdonald 21.01.2015 / 15:06
fonte

2 respostas

4

A única coisa que você pode fazer para ajudar a reduzir o impacto de uma mudança é dividir seu projeto geral em muitos componentes, de modo que, embora uma grande mudança tenha impacto em vários deles, muitos não serão afetados.

por exemplo, se o cliente decidir que precisa de um novo botão que envie dados por meio do intermediário para ser armazenado em uma nova coluna no banco de dados, você terá que alterar todas as camadas do sistema. No entanto, se o sistema também for dividido "horizontalmente", o impacto na interface afetará apenas parte da camada da interface do usuário, o restante não será alterado. Da mesma forma, se você tiver muitos serviços em sua camada intermediária em que cada processo processa determinadas partes dos dados, você só terá que alterar um deles - o restante não será afetado. o banco de dados também pode ser particionado em esquemas independentes.

Por exemplo, você precisa obter uma lista de usuários para ter um serviço que gerencia os dados do usuário. Quando você precisa obter uma lista de organizações também, você adiciona um novo serviço que lida com isso e mescla os dados juntos na interface do usuário (por exemplo), o que significa que você não teve que alterar seu código de acesso de usuário. Acho que esse tipo de abordagem é chamado de microservices , embora obviamente 'micro' não precise significar minúsculo, apenas logicamente separado .

Eu não tentaria introduzir abstrações, pois tudo o que acontecerá é que elas unirão suas camadas (por exemplo, uma alteração no banco de dados ainda exigirá a alteração da tabela subjacente, mas agora a camada DAL também precisará ser alterada e ter um DAL não vai necessariamente deixar você dividir o DB em seções, a menos que você tenha muito mais complexidade).

    
por 21.01.2015 / 15:32
fonte
-1

Testes de unidade e testes de integração podem ser usados para proteger sua lógica de alterações de código.

  1. Se atualmente você tem uma boa cobertura de código e precisa refazer uma seção, a abordagem seria mais fácil, você pode alterar seus testes para refletir o resultado após o retrabalho e depois de ter Depois de fazer a alteração, você poderá executar novamente os casos de teste, para garantir que tudo esteja funcionando. (Na prática, seria uma boa ideia usar um servidor de integração contínua para executar testes após cada confirmação e, com isso, você pode fazer alterações menores de cada vez e garantir que toda a lógica esteja intacta com o status do servidor de IC)

  2. Se você não tiver testes, seria uma boa ideia criar alguns. Se você estiver com um prazo apertado, pode começar com testes de integração em que os testes verificarão a saída da entrada fornecida a partir do nível de apresentação. Para cada lugar em que a mudança é necessária, você pode começar a criar testes para a saída esperada após as alterações e fazer as alterações de forma que os testes fiquem verdes.

por 22.01.2015 / 04:47
fonte