Como os DBAs podem ser mais "amigáveis ​​para programadores"?

46

As respostas e comentários sobre a versão dba.se e a versão programmers.se da pergunta "Quais são os argumentos contra ou para colocar a lógica do aplicativo na camada do banco de dados?" são muito reveladores sobre a divisão entre DBAs e programadores em alguns locais de trabalho.

O que os DBAs poderiam fazer de diferente para funcionar melhor com programadores em questões como essa?

Nós deveríamos:

  • Estude as ferramentas e os idiomas que nossos programadores estão usando para entender as dificuldades que enfrentam, principalmente ao trabalhar com bancos de dados bem projetados?
  • Incentivar os programadores a serem melhor informados sobre os bancos de dados e as vantagens de ter lógica de negócios no nível do banco de dados?
  • Mude a maneira como definimos interfaces para nossos dados - como usar APIs transacionais mais amigáveis ​​ao programador (por exemplo, para problemas como compatibilidade com versões anteriores)?
Jack Douglas
fonte

Respostas:

27

Do ponto de vista do programador, eu diria que o que mais queremos são padrões consistentes, bem definidos e implementados de como a camada de dados será projetada e construída. Estou disposto a jogar da maneira que você deseja na sua caixa de areia, você só precisa me dizer o que deseja e não alterar as regras o tempo todo. Deve ser implementado da mesma forma para todos, até mesmo para o superprogramador. Se você faz exceções para ele, deseja que eu o apoie e mude, mas reimplemente da maneira certa que não funciona para mim.

E, por favor, não me diga para não fazer dessa maneira e vá embora. Trabalhe comigo para me mostrar o que você quer e por que seu caminho é melhor. Se eu entender, vou cumprir o tempo todo. Quando não entendo, é mais difícil cumprir. Eu não quero ser um DBA. Adoro programar, não quero seu emprego e, se você é um bom DBA, serei seu maior fã.

Chade
fonte
63

Eu tenho um DBA MySQL nos últimos 6,5 anos. Também passei 16 anos como desenvolvedor e interagi com muitos DBAs. Muitos deles pragmáticos. Alguns deles desagradáveis. Alguns não têm idéia do que significa ser um DBA.

Eu cheguei a esta conclusão:

Tecnicamente falando, os DBAs que possuem uma ou mais das seguintes qualidades são os melhores para trabalhar:

  1. Passou anos como desenvolvedores
  2. Tenha uma noção da teoria do banco de dados
  3. Compreenda como o RDBMS funciona internamente
  4. Ter conhecimento superior do sistema operacional

DBAs muito disciplinados e conhecedores têm muito a compartilhar e oferecer. Eles podem ver o desempenho do banco de dados de uma perspectiva realmente não considerada pelos desenvolvedores. Os desenvolvedores sabem o que querem do banco de dados. Os DBAs sabem ser "educados" com o banco de dados.

No que diz respeito às personalidades, sempre haverá conflitos, mesquinhas e talvez até inveja. Uma coisa é certa: em nenhuma ordem específica, os DBAs e os Desenvolvedores são como maridos e esposas (eu sou casado há 16 anos com projetos em andamento [4 filhos]).

Independentemente de quem é visto como marido e quem é visto como esposa, esses princípios se aplicam:

  1. um deve consultar o outro
  2. um deve valorizar a perspectiva do outro
  3. é preciso tomar decisões para o bem de ambas as partes
  4. é preciso apoiar, e não sabatoge, a decisão tomada
  5. um não deve denegrir o outro se as decisões resultarem em más consequências
  6. é preciso regozijar-se na contribuição de ambas as partes para o sucesso das decisões
  7. é preciso consultar uma autoridade superior (HA) se uma decisão não puder ser mutuamente acordada

Esses sete (7) princípios se aplicam da mesma forma no local de trabalho, especialmente no campo da TI.

Ao comunicar todas as etapas, todos devem:

  1. traçar suas expectativas
  2. gerar respeito pela capacidade da outra parte de fazer sua parte com base no desempenho passado
  3. ter confiança e confiança de que a outra parte pode concluir sua tarefa
  4. corresponder às nossas próprias expectativas
  5. aquiescer sob a orientação do HA (ver princípio nº 7)

Não há espaço para microgerenciamento nisso. Os DBAs NÃO DEVEM DIZER aos desenvolvedores como pensar como DBAs. Os desenvolvedores não devem dizer aos DBAs como devem ser desenvolvedores. As decisões finais sobre desempenho e uso do banco de dados devem pertencer aos DBAs . As decisões finais sobre as necessidades do aplicativo devem ser dos Desenvolvedores . Essa simbiose deve ser mantida sempre.

PENSAMENTOS FINAIS

O princípio nº 7 requer participação ativa e supervisão da ALTA AUTORIDADE (HA), ou seja, gerente de projeto, líder de equipe, desenvolvedor líder. Seu HA sabe melhor como as duas partes trabalham individualmente e como as duas devem trabalhar juntas. Se o HA não estabelecer regras básicas para ambas as partes, ou se o HA falhar em guiar as partes individualmente e em conjunto, os projetos sempre pararão em algum momento e colocarão em risco a própria existência (emprego) do Desenvolvedor, o DBA, ou até o HA.

RolandoMySQLDBA
fonte
28

Ter equipes sentadas em diferentes seções / andares de alguma forma parece encorajar a mentalidade "nós contra eles".

Sentar um DBA bem no meio da equipe de desenvolvimento é uma ótima maneira de derrubar a parede do programador / DBA. Tanto o DBA quanto os programadores se beneficiarão disso, se permanecerem de mente aberta e colocarem seus egos de lado.

A comunicação cara a cara, especialmente ao compartilhar idéias, é muito mais eficaz que o e-mail e tem menos chance de causar ressentimentos devido a mal-entendidos.

datagod
fonte
20

Esse tipo de coisa varia enormemente de um lugar para outro. No meu site atual, a linha entre os desenvolvedores e os DBAs é muito turva - nós (os DBAs) também escrevemos PL / SQL e eles (os desenvolvedores) dissecam os planos de consulta. Todos nós nos vemos como colegas, apenas com diferentes habilidades e responsabilidades. Isso é muito divertido: recentemente, a empresa entrou na onda do DevOps . A comunidade do banco de dados não entende nada disso; nós sempre trabalhamos assim. Escusado será dizer que somos extremamente produtivos trabalhando assim: o nível do banco de dados é de longea parte mais confiável da pilha de tecnologia da empresa, é fácil de operar (já que possuímos as habilidades da equipe do DBA para entender o aplicativo em um nível profundo, e os desenvolvedores têm a exposição do DBA para entender as operações 24/7/365 e como para estruturar seus aplicativos).

Mas eu sei o que você quer dizer quando fala sobre o tipo "errado" de desenvolvedor. Ele é autodidata, o que por si só é uma coisa nobre, mas ao longo do caminho ele desconfia de qualquer tipo de instrução formal. Ele não sabe o que não sabe e se ressente de alguém tentando esclarecê-lo, ele vê isso como um insulto às suas habilidades de auto-aprendizado. Ele aprendeu o estilo imperativo da programação, porque você pode aprender sem nenhuma dessas teorias sobre as quais os tipos de CS estão sempre tagarelando (bem, mal; todo mundo precisa saber muito bem)e pedaços de teoria semelhantes). Ele também aprendeu um pouco de OO, apenas porque precisa usar Java. Mas um bom profissional de banco de dados - desenvolvedor ou DBA - precisa se sentir confortável pensando em um estilo declarativo, pensando em teoria dos conjuntos, em formas normais e até mesmo sendo capaz de entender a álgebra relacional e o cálculo. É muito, muito difícil se comunicar com essas pessoas, porque elas são ativamente hostis a qualquer coisa que possa tirá-las de sua zona de conforto, o que geralmente se limita a como formatar algo em uma página da web. Se eles pensam em bancos de dados, pensam que uma tabela é como uma classe e uma linha é como um objeto. Esses caras literalmente fazem, SELECT * FROM TABLEfiltram e classificam os resultados em seu próprio código. Eles realmente, realmente não entendem por que um banco de dados é melhor que um arquivo simples (e eles não pensam tão secretamente que qualquer pessoa que use um banco de dados relacional é um idiota).

Deixe-me dar um exemplo real: recentemente, eu estava conversando com um desses tipos sobre os problemas envolvidos na reversão de uma versão do nosso software após a entrada em produção, se um problema tivesse passado pelo controle de qualidade. Expliquei que, embora possamos reverter seu aplicativo (um dos muitos que acessam o banco de dados), seria necessário poder operar com o banco de dados ainda implantado. Ele perguntou por que, e eu disse, bem, nessas novas tabelas e colunas, haverá dados reais do cliente. Ele então disse, então copie-o em uma tabela temporária, qual é o problema. Eu o encarei, incrédula: quando um cliente liga e diz: meu dinheiro desapareceu da minha conta, o que dizemos a ele, que está tudo bem, está em uma mesa temporária? Ele simplesmente não entendeu que, quando você lida com o dinheiro de outras pessoas, precisa agir como um adulto responsável. Pelo que sei, ele ainda não sabe; ele não está mais conosco.

O campo MySQL ficou assim por um longo tempo; eles diriam que você não precisava de transações, chaves estrangeiras, etc., se você pensou que era, apenas porque você não tinha ideia do que estava fazendo, etc., etc. (então, quando eles cresceram, eles os adicionaram silenciosamente). Esses são os tipos de pessoas para as quais os ORMs, como ActiveRecord ou Hibernate, foram desenvolvidos, para que eles possam escrever aplicativos de banco de dados sem precisar tocar no SQL. Uso dessas tecnologias que considero uma bandeira vermelha - essa não é uma empresa que valoriza as habilidades de DBA. O que eles realmente querem é uma babá ...

Gaius
fonte
18

Como programador, entender melhor o banco de dados me tornou um programador melhor. Quando me tornei administrador de banco de dados, isso se tornou ainda mais importante, portanto, acredito que a educação é a chave.

Os DBAs devem orientar pacientemente os desenvolvedores, tratando-os como profissionais competentes. Poucos programadores, quando mostrados, a diferença entre uma operação definida e uma operação linha por linha no lado do cliente, rejeitam a ideia. Compartilhamos alguns dos mesmos objetivos - velocidade do aplicativo, segurança dos dados, capacidade de manutenção etc. Isso se aplica não apenas à questão da lógica do aplicativo, mas também a todos os aspectos da interação do banco de dados. Os programadores desejam usar melhor suas ferramentas e quanto mais o DBA puder mostrar a eles como usar melhor a ferramenta de banco de dados, mais eles se beneficiarão.

Leigh Riffel
fonte
12

Independentemente da infraestrutura que suportamos, precisamos oferecer suporte aos usuários dela. Muitos usuários são desenvolvedores, por isso apoiamos os desenvolvedores a permitir que eles façam o melhor uso possível dessa infraestrutura. Para poder fazer isso, precisamos nos entender, com as diferentes idéias e pontos de vista em mente. Ter conhecimento das visões de ambos os lados ajuda a melhorar as coisas para os negócios e esse é o nosso objetivo combinado. Torne o suporte de TI o negócio o mais eficaz possível.

Em muitas organizações, vemos alguns tipos de dba sendo executados no modo god. Na maioria das vezes, esses não são os que obtêm uma pontuação muito boa se a competência é medida ..... Freqüentemente eles apenas escondem seu - falta de - conhecimento por trás de uma parede de palavras.

Na minha opinião, isso não tem nada a ver com ser "amigável para programadores", mais com ser profissional. Para um dba, significa que precisamos ser capazes de explicar por que fazemos as coisas que fazemos e estar preparados para conceder uma reconsideração da decisão, se isso ajudar, sem perder os objetivos normais, como disponibilidade, escalabilidade, capacidade de recuperação e desempenho. Para o programador, significa que ele precisa se comunicar com o dba, às vezes para ensinar o dba, às vezes para aprender com o dba. Meu lema é: deixe o primeiro dia em que não aprendo nada no dia em que o caixão fechar acima da minha cabeça. Colaboração normal, ter equipes combinadas com desenvolvedores e dba certamente ajuda a facilitar as coisas.

ik_zelf
fonte
9

Eu acho que parte do problema é perspectiva. Dbas e analistas de dados e desenvolvedores de banco de dados precisam lidar com os dados ao longo do tempo. Os desenvolvedores de aplicativos se preocupam com como fazer as coisas funcionarem quando o enviam para produção. Eles não se preocupam tanto com a aparência dos dados em seis meses, desde que não haja erros quando forem implantados.

Mas as pessoas de dados precisam conviver com os resultados de decisões míopes que fazem com que os dados percam a integridade ou fazem com que registros duplicados sejam inseridos e depois tentam explicar por que os dados são ruins. DBAs são aqueles que precisam lidar com o problema de desempenho do processo que funcionou bem quando havia apenas mil registros, mas agora leva horas com 100.000.000 de registros.

Os bancos de dados são mais difíceis de refatorar; portanto, os DBAs estão preocupados em acertar na primeira vez. Os desenvolvedores não vêem nenhum problema em refatorar no futuro.

Os desenvolvedores não veem nenhum problema em fazer o banco de dados agir como se fosse orientado a objetos; as pessoas do banco de dados sabem que essa não é a maneira mais eficaz ou eficiente de armazenar ou obter os dados.

Os desenvolvedores de aplicativos geralmente lidam apenas com um pequeno subconjunto de registros, mas não com grandes importações / exportações ou relatórios de dados. Coisas que funcionam bem para inserir um registro, não funcionam quando se trata de importar um milhão. A lógica comercial no aplicativo (que geralmente não é acessível ao aplicativo de relatórios) não ajuda o redator de relatórios a obter os mesmos resultados para um milhão de registros do que é mostrado na tela, um registro por vez.

Outra parte do problema é o desrespeito pelos dois lados. Eu conheci mais do que alguns desenvolvedores de aplicativos que pensam que o trabalho com dados não é difícil ou interessante e que acreditam que você só faria esse trabalho se não pudesse invadir o mundo deles. As pessoas tendem a não reagir bem ao serem tratadas como se fossem estúpidas e inúteis. Alguns DBAs, por outro lado, tendem a tratar os desenvolvedores de aplicativos com desrespeito e tendem a colocar suas tarefas de revisar o que os desenvolvedores estão fazendo no banco de dados como uma baixa prioridade (que, quando você tem grandes bancos de dados de produção complexos, pode ser). Eles podem se recusar a ouvir ou responder. Quem quer que todo o seu projeto seja suspenso até que o DBA o revise duas semanas depois? E então ele diz que é inaceitável e você tem que reescrever a coisa toda?

HLGEM
fonte
8

Ao longo dos muitos anos desde que comecei com o SQL Server (1998), muitos desenvolvedores me disseram como fazer meu trabalho. É interessante que todos saibam mais do que eu, além de serem excelentes desenvolvedores de .net. De fato, eles também são arquitetos e deveriam estar fazendo coisas maiores do que o monitoramento de códigos.

Talvez essa seja a minha atitude errada: mas é uma atitude de desenvolvedor bastante comum em muitas lojas. Eles fazem isso um com o outro também, lembre-se: assista as lutas começarem quando você sugerir avaliações por pares.

Deixarei as correções com outras respostas (concordo 100% com as 2 até agora), mas acrescento que a cultura de gerenciamento e de loja também deve apoiar e fomentar a colaboração.

gbn
fonte
8

Como desenvolvedor, tudo o que preciso de você é saber como deseja que eu comunique o que preciso. Se estou pedindo algo ridículo, preciso que você me diga - e se você me disser, acreditarei nisso porque você tem um histórico de integridade. Se você não entender o que estou pedindo, reserve um tempo para me explicar o que você pensa que eu quero dizer - e eu vou ter tempo para ouvir.

... Tema comum, certo ... Comunicação ... comunicação ... comunicação.

Realmente não há maneira melhor de colocá-lo. Os desenvolvedores são afetados porque "que o DBA me disse que isso não podia ser feito - com certeza provei que ele estava errado da última vez". Os DBAs são marcados porque "esse desenvolvedor não entende o que tenho que fazer toda vez que ele altera suas especificações".

Desenvolvedores e DBAs, como afirmou @Rolando, precisam se entender. Quando tudo se resume a isso, nós dois falamos "Uns e Zeros" - você acha que seria uma boa combinação. Temos dois domínios de responsabilidade: os DBAs têm dados, os desenvolvedores recebem o restante do computador. Mas sem dados, os programadores realmente não teriam muito o que fazer.

Não temos um DBA e às vezes é doloroso. Aquele pedaço de mim que queria ser um DBA há uma década atrás vai se encolher quando vejo algumas das coisas que fazemos. Se contratássemos um DBA amanhã, acho que beijaria o chão em que ele / ela andou.

IAbstract
fonte
7

Em algumas empresas, talvez em muitas, o desenvolvimento de produtos tende a ignorar quem não escreve em uma linguagem compilada. Chegando a hora do lançamento, há resistência porque os administradores de rede, DBAs, administradores de sistema, suporte ao usuário, etc. têm sua devida diligência para concluir. Muitas vezes há dores de cabeça porque os principais aspectos do ambiente não foram considerados. Isso naturalmente causa tensões entre as equipes.

Quem é o culpado aqui? Ms. Comunicação.

Os desenvolvedores precisam entender o código do ambiente em que serão implantados. As pessoas precisam receber um aviso justo para se adaptar. Onde o ambiente não pode se adaptar por qualquer motivo (segurança, equipamento, política), o software precisa se adaptar. Se isso acontecer durante o processo de design e implementação, todos estarão felizes. Se não iniciar até o momento da implantação, é um mundo de mágoas.

Sim, as equipes precisam conversar (e ouvir) umas com as outras, mas o gerente de projeto / produto precisa criar um ambiente no qual isso possa acontecer.

Eu tive sorte, na maioria dos lugares em que trabalhei, o respeito mútuo e a comunicação fizeram parte da cultura.

Phil Lello
fonte
6

Uma coisa que um bom DBA precisa entender é a política de dados. Ensinei programação e design de banco de dados a programadores experientes e alguns DBAs redigidos por alguns anos. Uma pergunta que surgia regularmente era a seguinte: como todos os bancos de dados da minha loja são tão políticos?

Aqui estava minha resposta padrão: se o banco de dados for útil, você estará compartilhando dados. Se você estiver compartilhando dados, estará compartilhando poder. Quando o poder é compartilhado, a política acontece.

Não importa se você ama política ou odeia política. Se você deseja fazer um bom trabalho no banco de dados, acostume-se a isso.

Aliás, alguns de vocês trabalharam apenas em um ambiente de desenvolvimento. Existem DBAs que trabalham no lado da produção e têm pouca interação com os desenvolvedores. Você pode pensar que há menos política na produção. Tem mais. Os grandes bancos de dados de produção tendem a ser corporativos e de missão crítica.

Walter Mitty
fonte
3

Um pouco de humildade pode ajudar alguns de vocês. ;)

Obviamente, existem argumentos válidos para qualquer uma das abordagens. Sugiro que você comece reconhecendo isso. O desenvolvimento de software tem tudo a ver com as compensações corretas. Se for uma via de mão dupla, talvez os DBAs também devam manter a mente aberta.

eevar
fonte