Como compartilhar uma base de código entre mais de 10 projetos e minimizar a dor?

Eu tenho vários aplicativos que compartilham os mesmos dados no mesmo banco de dados. Para tentar minimizar a redundância de código, a camada de acesso a dados é um projeto compartilhado. Isso impede que cada projeto precise codificar novamente seu próprio acesso a dados, mas isso também cria um grande problema. Quando uma equipe precisa atualizar a camada de dados, todas as outras equipes precisam extrair e testar as alterações para garantir que não quebraram nada, e esse é um processo lento e doloroso.

Pensei na idéia de remover a camada de dados compartilhada e apenas fazer com que cada equipe gerencie sua própria camada de dados, mas o problema é que todas as equipes ainda acessam o mesmo banco de dados. atualize seu código relevante.

Portanto, minha pergunta é: como eu poderia projetar nossos dados e acessar a camada de modo que muitos projetos fossem expulsos da mesma fonte de dados e minimizar a necessidade de fazer alterações no banco de dados ou na camada de acesso?

A camada de dados compartilhados parece uma boa ideia. A solução para minimizar a dor é:

1. faça módulos de teste que geram exceção (como: tudo para de funcionar, não apenas uma mensagem) quando algum teste falha.
2. Coloque TODOS os módulos de teste na pasta compartilhada. Quero dizer, todos os módulos de teste de mais de 10 projetos devem estar na mesma pasta (ou um caminho fácil de entender).
3. Se um programador deseja editar a camada crítica, ele deve executar todos os testes nessa pasta; se algo não funcionar, ele não poderá confirmar o código.

Dessa forma, se eu criar um código, estou motivado a escrever uma boa classe de teste, como uma classe de teste real, porque se minha classe de teste explodir com alguma modificação, significa que essas modificações quebrarão meu código. Portanto, todo programador é forçado a escrever um bom teste (se não o fizer, meu código poderá quebrar de tempos em tempos). Executar todos os testes dos projetos sem erros significa: "ok, você pode confirmar", quando algo der errado, significa "não, essas modificações quebrariam o sistema em alguma linha x"

Este é um bom ponto, porque o material de teste é frequentemente deixado para trás em um projeto ... é claro que manter o código de teste requer algum esforço adicional.

Eu experimentei esse problema em primeira mão. É difícil, e eu estava integrando apenas cinco aplicativos. Eu posso oferecer algumas dicas:

1. Desacoplar o banco de dados usando os serviços RESTful para o maior número possível de coisas. Isso permite criar facilmente várias versões da interface, se necessário, e facilita muito as migrações de banco de dados.
2. Se o acesso ao banco de dados para alguns dos aplicativos for somente leitura, crie visualizações de banco de dados dos dados necessários. Se você precisar executar um processo em lote para calcular valores, faça-o em uma visão materializada.
3. Pense com cuidado no design. Qualquer alteração no banco de dados provavelmente interromperá outros aplicativos. Todos os aplicativos realmente precisam de acesso total ao banco de dados? Caso contrário, divida-os para usar um serviço. Desacoplar qualquer acesso ao banco de dados de qualquer lógica.

A resposta curta é que você precisa dedicar muito tempo ao seu código compartilhado para torná-lo o mais robusto / sólido / confiável possível.

Como você está descobrindo, não pode mudar o código da sua biblioteca com muita frequência.

Pode ser necessário dividir sua camada de dados em duas partes - uma parte de baixo nível que faz coisas muito simples, mas nunca muda (ou seja, o código compartilhado) e uma parte de alto nível que pode ter que ser exclusiva para cada aplicativo.

Para a parte compartilhada de baixo nível, você precisa pensar como um desenvolvedor de bibliotecas e não como desenvolvedor de aplicativos. Isso significa muitos testes de unidade, uma interface de aplicativo muito clara e completamente definida, documentação correta, completa e útil e muito código defensivo - todas as entradas são inválidas até prova em contrário.

O código compartilhado deve ser escrito para atender às necessidades dos aplicativos que você possui hoje e que usarão o código, mas convém dedicar um tempo extra para considerar como esse código funcionará para as próximas dezenas de aplicativos que não foram proposto ainda. Em outras palavras, o código compartilhado resolve o problema geral de expor os dados de maneira significativa para seus consumidores. Se bem feito, novos consumidores podem usar essa biblioteca sem alterações.