A criação e a exclusão contínuas de tabelas são um sinal de falha na arquitetura?

Recentemente, tive uma discussão com um desenvolvedor que mencionou que, durante o desenvolvimento do programa, eles rotineiramente criam e excluem tabelas e colunas regularmente, enquanto trabalham em novos recursos e justificam as coisas dizendo que isso é normal ao usar um processo de desenvolvimento ágil.

Como a maioria dos meus antecedentes está em um ambiente de desenvolvimento em cascata, pergunto-me se isso é realmente considerado adequado no desenvolvimento ágil ou se isso pode ser um sinal de um problema subjacente, seja na arquitetura do programa ou na sequência do processo ágil.

Está cada vez mais aparente para mim todos os dias que "ágil" está se tornando sinônimo de mal pensado, caótico, apressado e sem graça. E nenhuma dessas coisas é compatível com uma abordagem ágil como eu a entendo.

Ter um processo ágil eficaz e repetível não é fácil, e não acredito que ele reduz inerentemente a quantidade total de trabalho a ser realizado, embora possa muito bem levar a melhores produtos.

Se eles disseram que não têm tempo para "refatorar" o banco de dados, provavelmente também não têm tempo para configurar a versão e a migração para o banco de dados. Eles provavelmente não tiveram tempo para criar um conjunto de testes funcionais para ele. Todas essas coisas são o que penso quando penso em um processo Agile sólido que está se encaminhando para o sucesso.

No final, Agile é apenas uma palavra. O que você está fazendo no dia-a-dia determina se você será bem-sucedido ou não.

Embora não seja incomum criar e soltar tabelas à medida que o design evolui, pode haver alguma limpeza para garantir que o banco de dados esteja realmente usando todas essas tabelas.

Sim, o Agile tem tudo a ver com refatoração, mas se agora eles dizem que o sistema é grande demais para refatorar, eles pararam de usar o Agile e agora são apenas a programação do Cowboy. A equipe de desenvolvimento não vai gostar de ser chamada assim, mas é isso que eles estão fazendo. Montando o campo de tiro qualquer coisa que se move.

Um DBA ajudará, apenas certifique-se de obter um DBA que entenda o desenvolvimento e o desenvolvimento Agile. Sua equipe de desenvolvimento precisa ser controlada, não jogada na cadeia.

Em geral, geralmente criar novas tabelas e adicionar novas colunas é muito normal em um processo em que a programação e a administração do banco de dados não são estritamente separadas. Um novo recurso pode criar novos dados que devem ir a algum lugar. Tente estritamente evitar isso e você acaba com um modelo de plataforma interna .

Um software bem escrito dificilmente percebe esses novos objetos de banco de dados; portanto, nada é interrompido apenas por causa de uma nova coluna em alguma tabela.

Por outro lado, descartar regularmente colunas ou mesmo tabelas é suspeito. Um novo recurso nunca precisa de uma tabela removida; portanto, isso pode ser um sinal de pessoas trabalhando completamente sem planejamento.

Se seu banco de dados puder ser facilmente versionado e migrado e você tiver os testes para provar que mudar as coisas não quebrou as coisas, provavelmente você tem um processo bastante ágil.

À luz dos comentários - geralmente, para o efeito deles, há um bando de cowboys que se justificam como ágeis - gritam. Rápido. E publique tudo o que puder no thedailywtf.com para que todos possamos desfrutar do seu horror.

Como a maioria das respostas aqui no StackExchange, a resposta deve ser 'depende'. No desenvolvimento ágil, requisitos e especificações são descobertos durante a implementação.

No entanto, dado o desenvolvimento ágil, quando um modelo relacional é normalizado adequadamente, a adição de novos atributos às relações raramente deve ser uma necessidade, as novas entidades geralmente devem se referir às mais antigas, considerando um modelo adequado.

A maioria dos desenvolvedores não normaliza seus bancos de dados devido a restrições de tempo, preguiça, incompetência ou complexidade de consultas. A renormalização requer a transferência de dados existentes, a modificação dos DAO, etc. etc., o que gera um fator de risco.

Para responder sua pergunta, não, isso não é normal em um processo Agile.

O ponto em que parece resultar de uma atitude do Agile é o ciclo de design / desenvolvimento / teste do Agile de iteração curta e a ênfase do Agile em soluções leves que atendem aos requisitos conhecidos, mas são bem estruturadas para poder atender novos requisitos com o Agile. mudança mínima. Dadas essas duas coisas, você pode dizer que um desenvolvedor, sem saber o que pode acontecer, mas sabendo que sua mudança não deve afetar o banco de dados de uma maneira que não pode ser desfeita, simplesmente faz as alterações necessárias no esquema no maneira "mais leve" possível e, em intervalos, vários conjuntos de mudanças "leves" serão refatorados para algo mais permanente e estável.

Dito isso, ainda não trabalhei com um desenvolvedor que subscreveu a teoria e a metodologia Agile e também pensei que a criação e a exclusão rotineiras de tabelas no esquema eram necessárias por qualquer motivo. Agile não significa slap-dash ou bolt-on. Se você receber uma história que exija a adição de um novo campo de dados pertencente a um registro específico, adicione o campo à tabela. Se essa mudança quebra alguma coisa, você descobre o porquê e faz outras alterações necessárias (posso pensar em poucas coisas que quebrariam adicionando uma coluna a um banco de dados que está sendo consultado; se ela romper com esse tipo de alteração, você problemas maiores). A refatoração é normalmente limitada ao código; alterar o esquema geralmente é um processo mais envolvido do que alterar o código; portanto, quando mudanças no esquema precisam ocorrer, elas geralmente são feitas com mais cuidado, e pelo menos alguma atenção prestada ao conhecimento da direção futura do projeto. Ter que reestruturar parte ou todo o banco de dados indica uma falha fundamental no design; Ser ágil não significa que não exista um "plano mestre" de regras básicas de arquitetura e design a serem seguidas ao criar organicamente o programa e a estrutura de dados.

Agora, existem casos no Agile em que o que você "sabe" agora será contradito pelo que aprenderá mais tarde. Digamos que você tenha um requisito de que seu sistema deve ter um endereço para cada pessoa. Como esse é um relacionamento 1: 1 e os dados serão necessários na maioria dos casos, basta adicionar os campos Endereço à tabela Pessoa. Uma semana depois, você recebe um requisito de que uma Pessoa pode ter mais de um Endereço. Agora é um relacionamento 1: N e, para modelá-lo adequadamente, você deve desfazer as alterações anteriores, dividindo os campos em uma nova tabela de endereços. Isso não é rotina, especialmente entre os desenvolvedores seniores. Um desenvolvedor experiente verá que uma Pessoa tem um Endereço, considere-os como conceitualmente separados e criará uma tabela de Pessoa e uma tabela de Endereço, vinculando Pessoa a Endereço com uma referência FK a um AddressID. Um esquema como esse é mais fácil de alterar, caso a natureza do relacionamento mude; sem criar ou excluir tabelas de dados "amplas" inteiras, o relacionamento entre Pessoa e Endereço pode ser facilmente modificado de 1: 1 para 1: N para N: N.

Não há tanto foco no design inicial quando se trabalha com o Agile, então não vejo isso como um grande problema, certamente para o primeiro lançamento.

É difícil comentar sobre um sistema que possui 700 tabelas que eu não vi, pode precisar de todas elas, mas também pode ser que o banco de dados não tenha sido gerenciado o suficiente.

Mesmo sob agilidade, para um grande sistema, é bastante comum ainda ter alguém / equipe encarregado do esquema.

Se eles estão fazendo essas alterações com freqüência - principalmente descartando tabelas e colunas em aplicativos ao vivo - isso parece um sinal de inexperiência. Não tem nada a ver com o processo que eles pretendem seguir. 'Agile' não é uma desculpa para não se sentar e pensar nos dados que você precisa armazenar e como eles se relacionam antes de começar a digitar o código. Se eles acham que estão alterando mais de 10 a 20% da estrutura inicial, para mim isso é um indicador de que eles não estão pensando bem ou não têm muita experiência na análise de requisitos e no design de bancos de dados, e simplesmente ficam muito muita coisa errada no começo.

Embora pareça que sua equipe é simplesmente uma codificação de cowboy, realmente não deve haver nada de errado em refatorar o código OU os bancos de dados. Não é perda de trabalho - está se adaptando a uma realidade recém-aprendida.

Sugiro que a equipe precise é de uma caixa de areia para experimentar mudanças, fazer alguns testes, repassá-las aos usuários e decidir se elas fazem sentido. Nesse ponto, a integração das alterações que fazem sentido - com o teste de regressão adequado - em seu esquema deve estar correta.

Agile é sobre codificação, bancos de dados não são código. Alterar um banco de dados deve ser tratado como reformar uma casa. De alguma forma, as pessoas acreditam que agilidade significa agir agora, planeje mais tarde, o que é completamente falso. Mesmo sob métodos ágeis, é necessário tempo para o planejamento, especialmente para algo tão importante quanto o design do banco de dados.

Meu último trabalho foi em uma equipe como esta. Ao usar um processo ágil, os requisitos são alterados. Às vezes, as alterações significam que uma entidade existente precisa de um novo atributo, resultando em uma nova coluna em uma tabela existente ou é necessária uma entidade totalmente nova, resultando em uma nova tabela com relacionamentos com tabelas existentes. Esses tipos de alterações vêm com o território e não podem ser ignorados apenas porque você não deseja tocar no esquema. O sucesso é determinado pela manutenção da integridade de seus dados ao migrar de uma versão do banco de dados para o próximo e adequado teste de unidade.

Apenas tente não fazer alterações desnecessárias no seu esquema. Por exemplo, se um recurso exigir que uma nova tabela seja criada, verifique se você está satisfeito com a definição dessa tabela antes de fazer o check-in e implementá-la em seu ambiente de teste. Ter que desfazer uma alteração no esquema do banco de dados após a migração dos dados pode ser doloroso.