Bogarting a camada de acesso a dados

9

Situação: O dba é um contratado externo que mantém todo o código DAL verificado no TFS. Seria bom, como desenvolvedor de front-end, poder adicionar colunas, ajustar os processos e outros enfeites, sem precisar esperar que esse cara responda aos seus e-mails para fazer o trabalho.

Pergunta: Qual seria uma solução / processo recomendado que permitiria um desenvolvimento mais rápido / ágil, mantendo a integridade dos dados, bem como o amor e a felicidade da paz entre a equipe?

— spaghetticowboy
fonte

Estou preocupado aqui sobre por que você precisou adicionar uma coluna e quais regras de negócios estão associadas a essa coluna. Você pode encontrar maneiras de contornar isso e, eventualmente, adicionar a coluna, mas e se você usasse o tipo de dados errado, configurações nulas, definição de índice, pior e se a coluna não pertencesse à tabela ou se você estiver com uma tabela de interseção em falta? Acho que alguém deve ser responsável pelo impacto comercial da definição de novos dados e também alguém pelo impacto de uma alteração no banco de dados no código (que não seja o DBA). Os 2 papéis podem ser desempenhados pela mesma pessoa.

— precisa saber é o seguinte

Exigir que o DBA trabalhe em seu próprio ramo. Não conceda a eles direitos de pagamento para o principal ramo de desenvolvimento. Como alternativa, crie seu próprio ramo de desenvolvimento e mescle suas alterações conforme necessário.

— precisa saber é o seguinte

11

Martin Fowler e Pramod Sadalage escreveram um excelente artigo sobre esse assunto.

Todo desenvolvedor tem seu próprio banco de dados no qual as alterações podem ser feitas. Essas alterações são então comunicadas de volta (como um conjunto de alterações) ao DBA que as implementa no banco de dados mestre, para que ele ainda esteja envolvido no processo, ele provavelmente sabe melhor sobre as estruturas e necessidades do banco de dados. Eu acho que essa é a melhor abordagem, pois é satisfatória para todas as pessoas envolvidas no processo e também é muito ágil.

Você pode alterar o DAL de maneira semelhante. Basta fazer as alterações e fornecer um conjunto de alterações para o DBA quando você concluir, para que ele possa revisá-lo e mesclá-lo ao mestre dele.

— Falcão
fonte

11

oooh eu gosto ... este é o meu primeiro Q aqui, então ainda não posso votar, mas você tem um com certeza ... talvez / provavelmente a resposta também, mas eu gosto de esperar um pouco para ver o que as outras pessoas dizem

— spaghetticowboy

O problema disso é que o desenvolvedor faz todo o seu trabalho assumindo que o dba aprovará.

— HLGEM 14/09/11

@HLEGM: Na minha experiência, esse raramente é um caso, na maioria das vezes o DBA o aprova ou o altera apenas um pouco. Ainda é melhor do que ter desenvolvedores ociosos sentados. Além disso, provavelmente levará à melhor solução se o DBA e o desenvolvedor forem pessoas razoáveis.

— Falcon

+1 por explicar por que este é um excelente artigo, em vez de apenas postar um link.

— JeffO 14/09

@HLGEM - Eu acho que exige que ambas as partes justifiquem o que estão fazendo. O DBA deve obter o benefício da dúvida em questões de banco de dados, mas ambos precisam responder a outra pessoa que tenha a decisão final.

— JeffO 14/09

3

Bem, quando estou fazendo o DBA, sou conhecido por trancar tudo, para que os malditos programadores sujos não consigam mexer com isso. Todo mundo pensa que sabe como fazê-lo melhor, e "ajusta" as coisas para torná-las mais fáceis para si, e isso causa uma bagunça profana.

A outra alternativa é abri-lo e deixar que os programadores se envolvam nele por um tempo, depois pule e imponha a ordem à medida que as coisas terminarem ... Isso é certamente mais "ágil", mas pode ser um pesadelo real, dependendo do que deve ser cortado ou alterado ... Os DBAs geralmente entendem melhor o projeto como um todo e algumas mudanças que parecem inócuas podem ser problemáticas.

Se ele for o único gatekeeper, ele precisa ter uma especificação fixa ou ser capaz de "vender" sua visão para o resto dos desenvolvedores.

— Satanicpuppy
fonte

estamos muito sujo dum raio ... e às vezes estamos muito impaciente maldito bem e precisa obter o material feito a nós mesmos

— spaghetticowboy

@spaghetti: Sim ... provavelmente sou pior do que a maioria porque fiz muito trabalho com DBA, então tenho o dobro do "sei fazer melhor!" do que a maioria dos programadores. Eu direi o seguinte: com bancos de dados, é muito mais importante acertar logo ... Se você continuar adicionando até o final do projeto, quase certamente causará problemas.

— Satanicpuppy

3

Há um grande problema que supera qualquer outro problema:

Por que o contratante sempre verifica o código?

Por que ele está autorizado a fazer isso? Ninguém deve fazer check-out de um arquivo, a menos que esteja fazendo edições ativamente. Deve haver uma política de equipe sobre check-out.

O contratado (gostando ou não) trabalha como parte de uma equipe e, às vezes, outros membros da equipe podem precisar fazer alterações. Este é um problema de comunicação. Infelizmente, não há uma maneira automatizada de corrigir esse problema de comunicação.

— George Stocker
fonte

1

Em vez de camadas horizontais, prefiro trabalhar no silo através das camadas.

Dessa forma, nenhuma pessoa / equipe pode bloquear dessa maneira.

Isso também significa que você é um desenvolvedor com habilidades múltiplas e é capaz de mover recursos com muito mais facilidade.

Obviamente, existem seções (design da interface do usuário e design do banco de dados) que podem precisar de mais trabalhos especializados, mas você entendeu.

— ozz
fonte

1

Simples, se você ainda não possui, deve ter 3 ambientes:

Ambiente de desenvolvimento
Ambiente de controle de qualidade
Ambiente de produção

O ambiente de desenvolvimento deve ser administrado por seus desenvolvedores.

Você também pode querer adicionar um ambiente de RC.

Outra resposta: se vários ambientes não forem possíveis, você poderá desenvolver um repositório com zombaria ... Dessa forma, você cria seus modelos e, em seguida, seu contratante é responsável por fazer com que seus modelos correspondam ao banco de dados. De certa forma, isso é melhor, pois libera seus desenvolvedores de se preocupar com o banco de dados.

— AJC
fonte

11

O OP está falando sobre o código que foi retirado. Ambientes diferentes não teriam impacto.

— NotMe

1

Seu problema me parece ser de mão-de-obra. É apropriado e necessário que todas as possíveis alterações da base de dados sejam aprovadas por um especialista em banco de dados. Se a pessoa atual não puder acompanhar o trabalho em tempo hábil, você precisará de mais especialistas em banco de dados.

— HLGEM
fonte

+1: isso também pode ser a causa do problema. Muitas empresas têm muito poucos DBAs.

— Falcon

1

Esta é uma questão de gerenciamento, tanto quanto técnica.

Certamente, existem razões válidas para um DBA (independentemente de estar no local ou não, contratado ou funcionário) para manter os desenvolvedores longe de fazer qualquer tipo de alteração no banco de dados.

No entanto, o principal problema que você definiu é o de disponibilidade. O seu gerente sabe que é desperdiçado tempo / dinheiro esperando esta pessoa? Caso contrário, você pode mostrar como todos estão sentados.

— Eu não
fonte