Bogarting la capa de acceso a datos

9

Situación: el dba es un contratista externo que mantiene todo el código DAL desprotegido en TFS. Sería bueno que el desarrollador front-end pueda agregar columnas y ajustar los procesos y demás, sin tener que esperar a que este tipo responda a sus correos electrónicos para hacer el trabajo.

Pregunta: ¿Cuál sería una solución / proceso recomendado que permitiría un desarrollo más rápido / ágil, mientras se mantiene la integridad de los datos, así como la paz, el amor y la felicidad entre el equipo?

— spaghetticowboy
fuente

Aquí me preocupa por qué necesita agregar una columna y qué reglas comerciales están asociadas con esta columna. Puede encontrar formas de evitarlo y eventualmente agregar la columna, pero ¿qué sucede si usó el tipo de datos incorrecto, la configuración nula, la definición del índice, peor aún, si la columna no debe pertenecer a la tabla o si le falta una tabla de intersección por completo? Creo que alguien debe ser responsable del impacto comercial de definir nuevos datos y también alguien debe ser responsable del impacto de un cambio de base de datos en el código (que no sea el DBA). Los 2 roles pueden ser desempeñados por la misma persona.

— NoChance

Requerir que el DBA trabaje en su propia sucursal. No les dé derechos de pago a la rama principal de desarrollo. Cree alternativamente su propia rama de desarrollo y combine sus cambios según sea necesario.

— SoylentGray

11

Martin Fowler y Pramod Sadalage han escrito un excelente artículo sobre este tema.

Cada desarrollador tiene su propia base de datos en la que se pueden realizar cambios. Estos cambios luego se comunican (como un conjunto de cambios) al DBA que los implementa en la base de datos maestra, por lo que todavía está involucrado en el proceso, de todos modos probablemente sepa mejor sobre las estructuras y las necesidades de la base de datos. Creo que ese es el mejor enfoque, ya que es satisfactorio para todas las personas involucradas en el proceso y también es muy ágil.

Puede cambiar el DAL de manera similar. Simplemente haga sus cambios y proporcione un conjunto de cambios para el DBA cuando crea que ha terminado, para que pueda revisarlo y fusionarlo con su maestro.

— Halcón
fuente

1

oooh me gusta ... esta es mi primera Q aquí, así que aún no puedo votar, pero seguro que recibiste uno ... tal vez / probablemente la respuesta también, pero me gusta esperar un poco para ver lo que dicen otras personas

— spaghetticowboy

El problema con esto es que el desarrollador hace todo su trabajo asumiendo que el dba lo aprobará.

— HLGEM

@HLEGM: En mi experiencia, este es un caso raro, la mayoría de las veces el DBA lo aprobará o lo cambiará solo un poco. Todavía es mejor que tener desarrolladores inactivos sentados. Además, probablemente conducirá a la mejor solución si el DBA y el desarrollador son personas razonables.

— Falcon

+1 por explicar por qué este es un excelente artículo en lugar de simplemente publicar un enlace.

— JeffO

@HLGEM - Creo que requiere que ambas partes justifiquen lo que están haciendo. El DBA debería obtener un beneficio de la duda en materia de db, pero ambos deben responder a otra persona que tenga la decisión final.

— JeffO

3

Bien, cuando estoy haciendo lo de DBA, se me conoce por bloquear todo para que los malditos programadores sucios no puedan entenderlo. Todos piensan que saben cómo hacerlo mejor, y "modifican" las cosas para que sean más fáciles para ellos mismos, y esto causa un desastre profano.

La otra alternativa es abrirlo de par en par y dejar que los programadores peleen durante un tiempo, luego saltar e imponer orden a medida que las cosas comienzan a cerrarse ... Esto es ciertamente más "ágil", pero puede ser una verdadera pesadilla dependiendo de lo que se debe cortar o cambiar ... Los DBA a menudo tienen una mejor comprensión del proyecto en su conjunto, y algunos cambios que parecen inocuos pueden ser problemáticos.

Si va a ser el único portero, debe tener una especificación fija o ser capaz de "vender" su visión al resto de los desarrolladores.

— Satanicpuppy
fuente

estamos muy muy sucia ... y, a veces somos muy muy impaciente, así y necesidad de conseguir cosas a nosotros mismos hace

— spaghetticowboy

@spaghetti: Sí ... probablemente soy peor que la mayoría porque he trabajado mucho en DBA, así que tengo el doble de "¡Sé cómo hacerlo mejor!" que la mayoría de los programadores. Diré esto: con las bases de datos, es mucho más importante hacerlo bien temprano ... Si sigues agregando hasta el final del proyecto, es muy probable que cause problemas.

— Satanicpuppy

3

Hay un problema importante que supera cualquier otro problema:

¿Por qué el contratista siempre verifica el código?

¿Por qué se le permite hacer esto? Nadie debe tener un archivo desprotegido a menos que estén haciendo modificaciones de forma activa. Debe haber una política de equipo sobre los pagos.

El contratista (les guste o no) trabaja como parte de un equipo y, a veces, otros miembros del equipo pueden necesitar hacer cambios. Este es un problema de comunicación. Desafortunadamente, no hay una forma automática de solucionar este problema de comunicación.

— George Stocker
fuente

1

En lugar de capas horizontales, prefiero trabajar en silo a través de capas.

De esa manera, ninguna persona / equipo puede bloquear de esta manera.

También significa que sus desarrolladores tienen múltiples habilidades y pueden moverse por las funciones con mucha más facilidad.

Por supuesto, hay secciones (diseño de interfaz de usuario y diseño de base de datos) que pueden necesitar más trabajo especializado, pero se entiende la idea.

— ozz
fuente

1

Simple, si aún no lo hace, debe tener 3 entornos:

Entorno de desarrollo
QA Environment
Entorno de producción

El entorno de desarrollo debe ser administrado por sus desarrolladores.

También es posible que desee agregar un entorno RC.

Otra respuesta, si no es posible múltiples entornos, podría desarrollar un repositorio simulado ... De esta manera, construye sus modelos y luego su contratista es responsable de hacer que sus modelos coincidan con la base de datos. En cierto modo, esto es mejor ya que libera a sus desarrolladores de preocuparse por la base de datos.

— AJC
fuente

1

El OP está hablando del código que está desprotegido. Diferentes ambientes no tendrían un impacto.

— NotMe

1

Tu problema me parece ser de mano de obra. Es apropiado y necesario que todos los cambios potenciales en la base de datos sean aprobados por un especialista en bases de datos. Si la persona actual no puede seguir el trabajo de manera oportuna, necesita más especialistas en bases de datos.

— HLGEM
fuente

+1: Esto también puede ser una causa del problema. Muchas compañías tienen muy pocos DBA.

— Falcon

1

Este es un problema de gestión tanto como técnico.

Ciertamente, existen razones válidas para que un DBA (independientemente de si está en el sitio o fuera, contratista o empleado) para evitar que los desarrolladores realicen ningún tipo de cambio en la base de datos.

Sin embargo, el problema principal que definió es uno de disponibilidad. ¿Sabe su gerente que se pierde tiempo / dinero esperando a esta persona? Si no, es posible que desee mencionar cómo están sentados todos.

— Yo no
fuente