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.
Um comentário no banco de dados, a última vez que foi verificado, existem mais de 700 tabelas e ouvi outras pessoas dizerem que "não há tempo suficiente para refatorá-lo".
700 mesas e pouco tempo para refatorar? Sinto o cheiro do fracasso por aqui.
700 mesas USADAS ou 700, muitas das quais órfãs?
@AdamCrossland Sério ... Ooh That Smell de Lynyrd Skynyrd vem à mente. Mas, falando sério, as tabelas desnormalizadas às vezes são uma boa opção de design em leitura pesada ou bancos de dados que têm uma carga pesada de relatórios.
@maple_shaft Claro, qualquer tecnologia pode ser abusada, como qualquer outra coisa que você precise pesar os prós / contras e testar, testar, testar. As visualizações materializadas podem, no entanto, oferecer uma saída, se você estiver desnormalizando suas tabelas. Acho que seu argumento é apenas mais um motivo para ter um DBA ou pelo menos um desenvolvedor com forte DB-fu na equipe para puxar as rédeas de volta quando todo mundo está cobrando com um design claramente ruim. Meu melhor trabalho não veio durante a codificação ou o design, mas a impedir que outras pessoas tomam decisões horríveis e horríveis.
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.
Ter um processo Agile eficaz deve significar mais trabalho inicial, devido ao foco repetido em fornecer apenas software funcional após cada sprint. Se bem feito, leva a uma melhor chance de sucesso. O Waterfall é realmente muito mais eficiente se você assumir que os requisitos são estáticos e os recursos do projeto não cometerem erros. Isso é fantasia na maioria das situações.
@maple_shaft, apenas isso. Ser ágil não remove o trabalho duro da construção de produtos.
Tenho a sensação de que se essa equipe estivesse usando uma abordagem em cascata, seria igualmente caótico e qualquer solicitação de mudança seria um desastre.
Bem dito, Jeff 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.
A criação de novas tabelas e colunas não me incomoda quando justificado, mas foi apontado que a remoção de tabelas (e colunas) geralmente significa que algum trabalho foi perdido devido a alguém planejar inadequadamente ou alguém decidir que afinal, o recurso não era necessário. Da mesma forma, o número de cisalhamento de tabelas é uma preocupação devido à falta de normalização nelas.
Exatamente. Não se preocupe com o grande número de tabelas, a maioria delas não é utilizada de qualquer maneira e talvez elas sejam descartadas em breve. SCNR
Bem, o problema é que todos eles devem ser usados, mesmo que seja apenas para um único registro.
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.
O triste é que o banco de dados não é facilmente versionado, migrado e há testes limitados no máximo. Os desenvolvedores freqüentemente substituem as alterações feitas por outros desenvolvedores.
Definitivamente programação Cowboy então. Se você tem uma equipe de gerenciamento por trás desse esforço "Agile", certifique-se de classificar essa equipe para eles que eles estão abusando do Agile e apenas ficando loucos.
O @RobZ Agile não é uma desculpa para uma cobertura ruim de teste de unidade e um design de banco de dados ruim. Isso soa como uma bagunça quente.
ugh! não versionado !!! Não é à toa que está uma bagunça. Estremeço ao pensar como é o código do aplicativo.
— 29412
Basicamente, essa equipe não está fazendo nada ágil, é apenas uma equipe AdHoc. Se houver uma estrutura de gerenciamento em vigor, você poderá anonimamente ou pessoalmente levantar preocupações na cadeia. Diga a eles que você está vendo um grande desastre no banco de dados, falta de testes e práticas inadequadas sendo usadas para gerenciar o código. Esta equipe está indo para uma enorme falha.
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.
— Dibbeke
Em que momento do processo ágil o modelo adequado para todas as futuras solicitações de mudança aparece magicamente?
Depois de estudar corretamente o domínio. Há um número limitado de propriedades que definem completamente uma entidade. Alguns exemplos (cada vez mais complexos): um ponto 2D é completamente definido por duas coordenadas, um endereço é completamente definido por um país, uma versão de campos e uma realização de um conjunto de campos de endereços definidos por outra entidade (usando um ID de país, uma versão e restrições).
@Dibbeke: E então você tem problemas de negócios, como tratar a UE (27 países) como um único país nos casos X, Y e Z. Ou tratar os estados dos EUA como países. Ou a percepção comercial de que algumas entradas do banco de dados têm 2 representações de endereço para um único endereço.
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.
Os bancos de dados não são código, mas o esquema é e deve ser tratado como tal. Deve ser versionado e controlado pela fonte também. Quero diminuir o voto disso, mas concordo muito com o restante de sua resposta.
Agile não é sobre codificação. É sobre o processo de desenvolvimento de software, que definitivamente inclui bancos de dados se o software em funcionamento depende do banco de dados. Dito isto, concordo com a sua afirmação de que Agile não significa "agir agora planeje depois".
@maple_shaft apenas porque um esquema db é tratado como código, não o torna código. animais de estimação são tratados como pessoas, mas não torná-los pessoas
Seja algo código ou não, ele precisa ser planejado. A alteração de um banco de dados deve ser tratada como a alteração do código, juntamente com considerações para os dados existentes. Na verdade, é preciso mais reflexão e planejamento.
— 21412 JeffO:
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.