Existe alguma esperança para escrever um bom código em cima de um banco de dados horrivelmente projetado?

Aqui está a minha situação. Um dos vários programas que herdei recentemente é construído com um banco de dados horrível no back-end. Os estimados criadores aparentemente não apreciavam os conceitos relacionais. Uma tabela para cada cliente, nomeado como um ID de cliente exclusivo. Oitenta e três campos com criptografia. O código é todo processual com dezenas de instruções SQL em linha concatenadas.

Como não recebemos um aplicativo auxiliar importante que roda no mesmo banco de dados, fui encarregado de recriá-lo do zero. Sou um desenvolvedor único, que nem mesmo é minha responsabilidade principal, pois pelo menos metade do meu tempo é ocupada por coisas de operações. Há um prazo inevitável definido para daqui a 30 dias.

Apesar da minha inexperiência, tenho certeza de que poderia ter projetado esse banco de dados e aplicativo existente muito melhor do que eles, mas não acho que seja realista para mim alterar o banco de dados, ajustar o aplicativo existente e ter certeza de que não ' Não quebre nada enquanto precisar criar o aplicativo adicional tão rapidamente.

Então, vamos supor que estou preso ao terrível banco de dados. Precisando trabalhar com uma estrutura tão ruim, qualquer coisa que eu escreva que esteja em conformidade com ela apenas aumentaria a pilha de dívidas técnicas a ser arquivada até que algo quebre completamente ou seja necessária uma nova funcionalidade? Como eu poderia abordar essa situação e obter algo de bom além de um aplicativo que funcionaria?

edit: Caso alguém esteja interessado, acabamos descartando esse banco de dados horrível e o aplicativo que foi executado nele. Terceirizamos a criação do aplicativo auxiliar (eu não estava envolvido na configuração) para, no final das contas, dois contratados diferentes que acabaram caindo em cima de nós, sem realizar nada. Acabei tendo que fazer uma correção horrível e parcialmente funcional em três dias que ainda está em uso hoje.

Há esperança, mas é uma batalha difícil, especialmente se ninguém perceber que o design do banco de dados é horrível. Você pode tentar abstrair a maldade com camadas de abstração, mas é provável que não valha a pena a batalha.

Meu conselho seria criar abstrações suficientes no banco de dados para que o próprio aplicativo seja limpo e projetado adequadamente; Dessa forma, se você puder consertar o banco de dados, o aplicativo não será afetado, pois não importa como o banco de dados foi projetado.

Essa é a abordagem que normalmente uso ao lidar com um banco de dados existente e, mais frequentemente do que não, projetado com zero pensamento. Alguns aplicativos de escolha dos padrões Repositório ou Gateway, com algumas camadas de serviço para conversar com o gateway / repositório, devem ajudar a colocar em quarentena o design inadequado.

Crie uma camada de interface que lide com todo o material do banco de dados e grave seu aplicativo para fazer interface com isso. Caso o banco de dados seja "corrigido", basta substituir / atualizar sua "interface". Essa abordagem me salvou muito tempo ao lidar com um banco de dados ruim ou com um banco de dados que alimentava outros aplicativos e não podia ser mexido.

Você herdou uma bagunça de pesadelo, você tem 30 dias para torná-la utilizável para sua organização e metade do seu dia é ocupada com tarefas de operações?

Tenho certeza de que você poderia refatorar, mas certamente não nessa quantidade de tempo.

Para responder sua pergunta, acho que você não pode escrever um bom código em um design desse tipo. A dívida técnica já é demais. Se eu fosse você, invadiria os recursos que eu poderia e pressionaria para uma refatoração completa em uma data posterior, quando você tiver mais tempo e pessoas em sua equipe para resolvê-lo melhor.

Apenas tenha cuidado ao pressionar para refatorar. Às vezes, um superior decide tomar o código-fonte dos produtos e os direitos de propriedade e não quer pensar que desperdiçou completamente seu dinheiro com lixo. Esse foi o meu caso em um emprego que eu tinha. Infelizmente, os gerentes tomam decisões sobre a compra de software como esse e nunca obtêm envolvimento técnico para avaliar o que estão comprando e ver se é sustentável e possui uma grande quantidade de dívida técnica. Nesse caso, a má decisão é política e pressionar pela refatoração pode colocar seu trabalho em risco.

Os bancos de dados podem ser refatorados como qualquer outro código. Corrija a parte afetada pelo código que você precisa para escrever e escrever testes para garantir que nada mais ocorra. Faça um pouquinho de cada vez, como qualquer outra refatoração. Há um bom livro sobre refatoração de banco de dados que pode ajudá-lo a começar a limpar a bagunça. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

Existem outros também, mas eu pessoalmente li e trabalhei com as técnicas deste.

E não esqueça que você pode reestruturar a maneira como precisa consultar o banco de dados criando visualizações para realizar o trabalho desagradável de transformação para você em uma estrutura mais fácil de consultar.

Para obter o melhor retorno possível, crie visualizações atualizáveis ​​para restaurar parte da "relacionalidade" e fornecer nomes de coluna mais significativos.

Uma possibilidade seria configurar um segundo banco de dados estruturado (pelo menos mais próximo) de como você gostaria e configurar a replicação entre os dois bancos de dados. Em seguida, você pode escrever seu código no novo banco de dados e ainda manter intacto o banco de dados existente (e o aplicativo), para ser tratado quando tiver mais tempo.

Na verdade, ainda há muitas perguntas sobre se você pode fazer isso em ~ 15 dias de trabalho. Em particular, é provável que dependa se você precisa de replicação bidirecional (ou seja, seu novo aplicativo realmente atualiza os dados) ou apenas de uma maneira (seu novo aplicativo permite que as pessoas visualizem os dados). O último caso é (é claro) dramaticamente mais fácil de lidar.

Se você precisar de replicação bidirecional, é provável que não haja tempo suficiente para fazer o trabalho. Em particular, a replicação bidirecional que envolve a transformação substancial da estrutura nunca é trivial e as ferramentas disponíveis costumam suportá-la muito mal (por exemplo, ter que escrever manualmente todo o SQL para todas as transformações de dados nas duas direções).

Se você precisar apenas de mão única, é exatamente no ponto em que isso pode ser possível. Também vai depender um pouco se você pode gastar algum dinheiro ou não - existem alguns aplicativos de data warehousing destinados a exatamente esse tipo de tarefa que provavelmente o tornariam um pouco mais rápido e fácil gerenciar - mas a maioria deles não é barata.