¿Cómo podrían los DBA ser más 'programadores amigables'?

46

Las respuestas y comentarios sobre la versión dba.se y la versión programmers.se de la pregunta "¿Cuáles son los argumentos en contra o para poner la lógica de la aplicación en la capa de la base de datos?" son muy reveladores sobre la división entre DBA y programadores en algunos lugares de trabajo.

¿Qué podrían hacer los DBA de manera diferente para trabajar mejor con los programadores en temas como este?

Deberíamos:

  • ¿Estudiar las herramientas y los lenguajes que utilizan nuestros programadores para comprender las dificultades que enfrentan, especialmente cuando trabajan con bases de datos bien diseñadas?
  • ¿Alienta a los programadores a estar mejor informados sobre las bases de datos y las ventajas de tener una lógica empresarial a nivel de base de datos?
  • ¿Cambiar la forma en que definimos las interfaces para nuestros datos, como mediante el uso de API transaccionales más amigables para el programador (por ejemplo, para problemas como la compatibilidad con versiones anteriores)?
Jack Douglas
fuente

Respuestas:

27

Desde el punto de vista del programador, diría que lo que más queremos son estándares consistentes, bien definidos e implementados sobre cómo se diseñará y construirá la capa de datos. Estoy dispuesto a jugar como quieras en tu sandbox, solo necesitas decirme lo que quieres y no cambiar las reglas todo el tiempo. Debe implementarse de la misma manera para todos, incluso superprogrammergod. Si haces excepciones para él, entonces quieres que lo apoye y lo cambie, pero lo vuelvas a implementar de la manera correcta que no funciona para mí.

Y por favor no me digas que no lo haga de esa manera y que me vaya. Trabaja conmigo para mostrarme lo que quieres y por qué tu camino es mejor. Si entiendo, cumpliré siempre. Cuando no lo entiendo, entonces es más difícil de cumplir. No quiero ser un DBA. Me encanta programar, no quiero tu trabajo y si eres un buen DBA, seré tu mayor fan.

Chad
fuente
63

He sido un DBA MySQL durante los últimos 6.5 años. También pasé unos 16 años como desarrollador y he interactuado con muchos DBA. Muchos de ellos pragmáticos. Algunos de ellos desagradables. Algunos no tienen idea de lo que significa ser un DBA.

He llegado a esta conclusión:

Técnicamente hablando, los DBA que tienen una o más de las siguientes cualidades son los mejores para trabajar:

  1. Pasé años como desarrolladores mismos
  2. Conocer la teoría de la base de datos.
  3. Comprender bien cómo funciona internamente el RDBMS
  4. Tener un conocimiento superior del sistema operativo.

Los DBA muy disciplinados y conocedores tienen mucho que compartir y ofrecer. Pueden ver el rendimiento de la base de datos desde una perspectiva que los desarrolladores no consideran realmente. Los desarrolladores saben lo que quieren de la base de datos. Los DBA saben cómo ser "educados" con la base de datos.

En cuanto a las personalidades, siempre habrá conflictos, mezquindad y tal vez incluso envidia. Una cosa es segura: sin ningún orden en particular, los DBA y los desarrolladores son como esposos y esposas (he estado felizmente casado durante 16 años con proyectos en curso [4 hijos]).

Independientemente de quién es visto como el esposo y quién es visto como la esposa, se aplican estos principios:

  1. uno debe consultar al otro
  2. uno debe valorar la perspectiva del otro
  3. uno debe tomar decisiones por el bien de ambas partes
  4. uno debe apoyar, y no sabotear, la decisión tomada
  5. uno no debe denigrar al otro si las decisiones resultan en malas consecuencias
  6. uno debe alegrarse por la contribución de ambas partes al éxito de las decisiones
  7. uno debe consultar a una autoridad superior (HA) si una decisión no puede ser acordada mutuamente

Estos siete (7) principios se aplican tanto en el lugar de trabajo, especialmente en el ámbito de TI.

Al comunicar cada paso del camino, todos deberían:

  1. diseñar sus expectativas
  2. engendrar respeto por la capacidad de la otra parte de hacer su parte en función del desempeño pasado
  3. tener confianza en que la otra parte puede completar su tarea
  4. estar a la altura de nuestras propias expectativas
  5. adquirir bajo la dirección de la HA (ver principio # 7)

No hay espacio para la microgestión en esto. Los DBA NO DEBEN DECIRLE a los desarrolladores cómo pensar como DBA. Los desarrolladores NO DEBEN DECIRles a los DBA cómo ser Desarrolladores. Las decisiones finales sobre el rendimiento y el uso de la base de datos deben descansar en los DBA . Las decisiones finales sobre las necesidades de aplicación deben descansar con los desarrolladores . Esta simbiosis debe mantenerse siempre.

PENSAMIENTOS FINALES

El Principio # 7 requiere la participación activa y la supervisión de la ALTA AUTORIDAD (HA), es decir, el gerente de proyecto, el líder del equipo, el desarrollador principal. Su HA sabe mejor cómo ambas partes trabajan individualmente y cómo ambas partes deberían trabajar juntas. Si la HA no establece reglas básicas para ambas partes, o si la HA no guía a las partes individualmente y juntas, los proyectos siempre se detendrán en algún momento y pondrán en peligro la existencia (empleo) del Desarrollador, el DBA, o incluso el HA.

RolandoMySQLDBA
fuente
28

Tener equipos sentados en diferentes secciones / pisos de alguna manera parece alentar la mentalidad de "nosotros contra ellos".

Sentar un DBA justo en el medio del equipo de desarrollo es una excelente manera de derribar el muro del programador / DBA. Tanto el DBA como los programadores se beneficiarán de esto, si permanecen abiertos y dejan de lado sus egos.

La comunicación cara a cara, especialmente cuando se comparten ideas, es mucho más efectiva que el correo electrónico y tiene menos posibilidades de causar resentimientos debido a malentendidos.

datagod
fuente
20

Este tipo de cosas varía enormemente de un lugar a otro. En mi sitio actual, la línea entre los desarrolladores y los DBA es muy borrosa: nosotros (los DBA) también escribimos PL / SQL y ellos (los desarrolladores) analizan los planes de consulta. Todos nos vemos como pares, simplemente con diferentes habilidades y responsabilidades. Esto es muy divertido: recientemente, la compañía se subió al carro de DevOps . La comunidad de la base de datos no entiende esto en absoluto; Siempre hemos trabajado así. No hace falta decir que somos enormemente productivos trabajando así: el nivel de base de datos es, con mucho,la parte más confiable de la pila de tecnología de la compañía, es fácil de operar (ya que tenemos las habilidades en el equipo de DBA para comprender la aplicación a un nivel profundo, y los desarrolladores tienen la exposición de DBA para comprender las operaciones 24/7/365 y cómo para estructurar sus aplicaciones para ello).

Pero sé a qué te refieres cuando hablas del desarrollador "equivocado". Es autodidacta, lo que en sí mismo es algo noble, pero en el camino ha desconfiado de cualquier tipo de instrucciones formales. Él no sabe lo que no sabe , y él se resiente cualquiera que trate de iluminarlo, lo ve como un insulto a sus habilidades de auto-aprendizaje. Aprendió el estilo imperativo de la programación, porque puedes aprenderlo sin ninguna de esas teorías sobre las que los tipos de CS siempre están parloteando (bueno, mal; todo el mundo necesita saber big-Oy partes similares de teoría). También aprendió un poco de OO, solo porque tiene que usar Java. Pero un buen profesional de bases de datos, desarrollador o DBA, debe sentirse cómodo pensando en un estilo declarativo, pensando en la teoría de conjuntos, las formas normales, incluso siendo capaz de comprender el álgebra relacional y el cálculo. Es muy, muy difícil comunicarse con estas personas, porque son activamente hostiles a cualquier cosa que pueda sacarlos de su zona de confort, que en general se limita a cómo formatear algo en una página web. Si piensan en las bases de datos, piensan que una tabla es como una clase y que una fila es como un objeto. Estos tipos literalmente simplemente harán, SELECT * FROM TABLEfiltrarán y ordenarán los resultados en su propio código. Realmente, realmente no entienden por qué una base de datos es mejor que un archivo plano (y no creen tan secretamente que cualquiera que use una base de datos relacional es un idiota).

Permítanme darles un ejemplo real: recientemente estaba hablando con uno de estos tipos sobre los problemas involucrados en la reversión de un lanzamiento de nuestro software después de que entró en producción, si un problema había pasado el control de calidad. Le expliqué que si bien podríamos revertir su aplicación (una de las muchas que acceden a la base de datos), necesitaría poder operar con la base de datos aún implementada. Me preguntó por qué, y le dije, bueno, en esas nuevas tablas y columnas, habrá datos reales de los clientes. Luego dijo, así que simplemente cópielo en una tabla temporal, cuál es el problema. Lo miré incrédulo: cuando un cliente llama y dice, mi dinero ha desaparecido de mi cuenta, ¿qué le decimos, que está bien, está en una mesa temporal? Simplemente no entendió que cuando se trata del dinero de otras personas, debe actuar como un adulto responsable. Por lo que sé, todavía no lo hace; Él ya no está con nosotros.

El campamento de MySQL estuvo así durante mucho tiempo; dirían que no necesita transacciones, claves foráneas, etc., si pensara que lo hizo fue solo porque no tenía idea de lo que estaba haciendo, etc., etc. (cuando crecieron, los agregaron en silencio). Estos son los tipos de personas para las que se desarrollaron ORM como ActiveRecord o Hibernate, para que puedan escribir aplicaciones de bases de datos sin necesidad de tocar SQL. Uso de estas tecnologías que considero una señal de alerta: esta no es una empresa que valora las habilidades de DBA. Lo que realmente quieren es una niñera ...

Gayo
fuente
18

Como programador, comprender mejor la base de datos me convirtió en un mejor programador. Cuando me convertí en administrador de la base de datos, esto se volvió aún más importante, por lo tanto, creo que la educación es la clave.

Los DBA deben guiar pacientemente a los desarrolladores para tratarlos como profesionales competentes. Pocos programadores cuando se les muestra la diferencia entre una operación establecida y una operación fila por fila en el lado del cliente se negarán a la idea. Compartimos algunos de los mismos objetivos: velocidad de la aplicación, seguridad de los datos, mantenibilidad, etc. Esto se aplica no solo a la pregunta lógica de la aplicación, sino también a todos los aspectos de la interacción de la base de datos. Los programadores quieren usar mejor sus herramientas y cuanto más el DBA pueda mostrarles cómo usar mejor la herramienta de base de datos, más se beneficiarán ambos.

Leigh Riffel
fuente
12

No importa qué infraestructura admitamos, tenemos que apoyar a los usuarios de la misma. Muchos usuarios son desarrolladores, por lo que apoyamos a los desarrolladores para que puedan hacer el mejor uso posible de esa infraestructura. Para poder hacer esto, necesitamos entendernos, teniendo en cuenta las diferentes ideas y puntos de vista. Tener una visión de las opiniones de ambas partes ayuda a mejorar las cosas para el negocio y ese es nuestro objetivo combinado. Haga que el soporte de TI del negocio sea lo más efectivo posible

En muchas organizaciones vemos algunos tipos de dba ejecutándose en modo dios. La mayoría de las veces, estos no son los que obtienen un puntaje muy bueno si se mide la competencia ..... A menudo simplemente ocultan su - falta de - conocimiento detrás de un muro de palabras.

En mi opinión, no tiene nada que ver con ser 'amigable con los programadores' más con ser profesional. Para una dba, significa que debemos ser capaces de explicar por qué hacemos las cosas que hacemos y estar preparados para reconsiderar la decisión de arrendamiento si eso ayuda, sin perder los objetivos normales como disponibilidad, escalabilidad, recuperación y rendimiento. Para el programador significa que tiene que comunicarse con el dba, a veces para enseñar el dba, a veces para aprender del dba. Mi lema sobre esto es: que el primer día que no sepa nada sea el día en que el ataúd cierre por encima de mi cabeza. La colaboración normal, al haber combinado equipos con desarrolladores y dba, ciertamente ayuda a facilitar las cosas.

ik_zelf
fuente
9

Creo que parte del problema es la perspectiva. Dbas y los analistas de datos y los desarrolladores de bases de datos tienen que lidiar con los datos a lo largo del tiempo. Los desarrolladores de aplicaciones se preocupan por cómo hacer que las cosas funcionen cuando lo envían a producción. No se preocupan tanto por cómo se verán los datos en seis meses, siempre que no haya errores cuando se implementen.

Pero las personas de datos tienen que vivir con los resultados de decisiones miopes que hacen que los datos pierdan integridad o que se inserten registros duplicados y luego tratar de explicar por qué los datos son malos. Los DBA son los que tienen que lidiar con el problema de rendimiento del proceso que funcionó bien cuando solo había mil registros, pero ahora lleva horas con 100,000,000 registros.

Las bases de datos son más difíciles de refactorizar, por lo que los DBA se preocupan por hacerlo bien la primera vez. Los desarrolladores no ven ningún problema en refactorizar en el futuro.

Los desarrolladores no ven ningún problema en hacer que la base de datos actúe como si estuviera orientada a objetos, la gente de la base de datos sabe que esa no es la forma más efectiva o eficiente de almacenar u obtener los datos.

Los desarrolladores de aplicaciones a menudo solo tratan con un pequeño subconjunto de registros, pero no con grandes importaciones / exportaciones de datos o informes. Las cosas que funcionan bien para ingresar un registro, no funcionan cuando se habla de importar un millón. La lógica empresarial en la aplicación (que a menudo no es accesible para la aplicación de informes) no ayuda al redactor de informes a obtener los mismos resultados para un millón de registros que lo que se muestra en la pantalla de un registro a la vez.

Otra parte del problema es la falta de respeto en ambos lados. He conocido a más de unos pocos desarrolladores de aplicaciones que piensan que el trabajo de datos no es difícil o interesante y que creen que solo harías este trabajo si no puedes hackearlo en su mundo. Las personas tienden a no reaccionar bien al ser tratadas como si fueran estúpidas e inútiles. Algunos DBA, por otro lado, tienden a tratar a los desarrolladores de aplicaciones con falta de respeto y tienden a poner sus tareas de revisión de lo que los desarrolladores están haciendo a la base de datos como de baja prioridad (que cuando tiene grandes bases de datos de producción complejas, puede ser). Pueden negarse a escuchar o responder. ¿Quién quiere suspender todo su proyecto hasta que el DBA lo revise dos semanas después? ¿Y luego te dice que es inaceptable y que tienes que reescribir todo?

HLGEM
fuente
8

Durante los muchos años transcurridos desde que comencé con SQL Server (1998), muchos desarrolladores me han dicho cómo hacer mi trabajo. Es interesante que todos sepan más que yo, además de ser excelentes desarrolladores de .net. De hecho, también son arquitectos y deberían estar haciendo cosas más grandes que el código monkeying.

Tal vez esa es la actitud equivocada de mi parte, pero es una actitud de desarrollador bastante común en muchas tiendas. También se lo hacen el uno al otro, recuerda: mira cómo comienzan las peleas cuando sugieres reseñas de pares.

Dejaré las soluciones a otras respuestas (estoy de acuerdo al 100% con las 2 hasta ahora), pero agrego que la administración y la cultura de la tienda también deben apoyar y fomentar la colaboración.

gbn
fuente
8

Como desarrollador, todo lo que necesito de ti es saber cómo quieres que te comunique lo que necesito. Si estoy pidiendo algo ridículo, necesito que me lo digas, y si me lo dices, lo creeré porque tienes un historial de integridad. Si no comprende lo que estoy pidiendo, tómese el tiempo para explicarme lo que cree que quiero decir, y me tomaré el tiempo para escucharlo.

... Tema común, correcto ... Comunicación ... comunicación ... comunicación.

Realmente no hay mejor manera de decirlo. Los desarrolladores se molestan porque "ese DBA me dijo que no se podía hacer, seguro que demostré que estaba equivocado la última vez". Los DBA se marcan porque, "ese desarrollador no entiende lo que tengo que hacer cada vez que cambia sus especificaciones".

Los desarrolladores y los DBA, como dijo @Rolando, deben entenderse entre sí. Cuando todo se reduce a eso, los dos hablamos "Unos y ceros", pensarías que sería una buena combinación. Tenemos 2 ámbitos de responsabilidad: los DBA tienen datos, los desarrolladores obtienen el resto de la computadora. Pero sin datos, los programadores realmente no tendrían mucho que hacer.

No tenemos un DBA y a veces es doloroso. Esa parte de mí que quería ser un DBA hace una década se encogerá cuando vea algunas de las cosas que hacemos. Si contratáramos un DBA mañana, creo que besaría el terreno sobre el que él / ella caminó.

IAbstracto
fuente
7

En algunas compañías, quizás en muchas, el desarrollo de productos tiende a ignorar a cualquiera que no escriba en un lenguaje compilado. En el momento del lanzamiento, hay resistencia porque los administradores de red, los DBA, los administradores del sistema, el soporte al usuario, etc., cada uno tiene su diligencia debida para completar. A menudo hay dolores de cabeza porque no se consideraron aspectos clave del medio ambiente. Esto naturalmente causa tensiones entre los equipos.

¿Quién tiene la culpa aquí? Sra. Comunicación.

Los desarrolladores deben comprender el código de entorno en el que se implementará. Las personas deben recibir una advertencia justa para adaptarse. Cuando el entorno no puede adaptarse por cualquier razón (seguridad, equipo, política), el software debe adaptarse. Si esto sucede durante el proceso de diseño e implementación, todos están felices. Si no comienza hasta el momento del despliegue, es un mundo de dolor.

Sí, los equipos necesitan hablar (y escuchar) entre sí, pero el gerente de proyecto / producto necesita crear un entorno en el que esto pueda suceder.

He tenido suerte, en la mayoría de los lugares donde he trabajado, el respeto mutuo y la comunicación han sido parte de la cultura.

Phil Lello
fuente
6

Una cosa que un buen DBA tiene que entender es la política de datos. Enseñé programación y diseño de bases de datos a programadores experimentados y algunos DBA redactados durante algunos años. Una pregunta que surgía regularmente era esta: ¿cómo es que todas las bases de datos en mi tienda son tan políticas?

Aquí estaba mi respuesta estándar: si la base de datos es útil, entonces está compartiendo datos. Si está compartiendo datos, entonces está compartiendo poder. Cuando se comparte el poder, sucede la política.

No importa si amas la política o la odias. Si va a hacer un buen trabajo de base de datos, acostúmbrese a ello.

Por cierto, algunos de ustedes solo han trabajado en un entorno de desarrollo. Hay DBA que trabajan en el lado de producción de la cerca y tienen poca interacción con los desarrolladores. Se podría pensar que hay menos política en la producción. Hay más. Las grandes bases de datos de producción tienden a ser de toda la empresa y de misión crítica.

Walter Mitty
fuente
3

Un poco de humildad podría ayudar a algunos de ustedes. ;)

Obviamente, hay argumentos válidos para cualquier enfoque, le sugiero que comience por reconocerlo. El desarrollo de software se trata de hacer las compensaciones correctas. Si se trata de una calle de doble sentido, quizás los DBA también deberían tener una mente abierta.

eevar
fuente