¿La creación y eliminación continua de tablas es un signo de un defecto arquitectónico?

Recientemente tuve una discusión con un desarrollador que mencionó que durante el desarrollo del programa, crean y eliminan rutinariamente tablas y columnas de forma regular mientras trabajan en nuevas funciones y justifican cosas al decir que esto es normal cuando se utiliza un proceso de desarrollo ágil.

Como la mayor parte de mi experiencia se encuentra en un entorno de desarrollo en cascada, me pregunto si esto realmente se considera apropiado en el desarrollo ágil, o si esto podría ser un signo de un problema subyacente, ya sea con la arquitectura del programa o con su seguimiento del proceso ágil.

Todos los días me resulta cada vez más evidente que "ágil" se está convirtiendo en sinónimo de mal pensado, caótico, apresurado y sin asiento. Y ninguna de esas cosas son compatibles con un enfoque ágil tal como lo entiendo.

Tener un proceso ágil efectivo y repetible no es fácil, y no creo que reduzca inherentemente la cantidad total de trabajo a realizar a pesar de que puede conducir a mejores productos.

Si han dicho que no tienen tiempo para "refactorizar" la base de datos, entonces probablemente tampoco tengan tiempo para configurar el control de versiones y la migración de la base de datos. Probablemente no se hayan tomado el tiempo para crear un conjunto de pruebas funcionales para ello. Pienso en todas esas cosas cuando pienso en un proceso ágil sólido que se dirige hacia el éxito.

Al final, Agile es solo una palabra. Lo que está haciendo día a día determina si tendrá éxito o no.

Si bien no es inusual crear y soltar tablas a medida que evoluciona el diseño, es posible que se realice una limpieza para asegurarse de que su base de datos realmente esté usando todas esas tablas.

Sí, Agile se trata de refactorizar, pero si ahora dicen que el sistema es demasiado grande para refactorizar, han dejado de hacer Agile y ahora solo están programando Cowboy. Al equipo de desarrollo no le gustará que lo llamen así, pero eso es lo que están haciendo. Montando el rango disparando cualquier cosa que se mueva.

Un DBA ayudará, solo asegúrese de obtener un DBA que comprenda tanto el desarrollo como el desarrollo ágil. Su equipo de desarrollo necesita ser dominado, no encarcelado.

En general, a menudo crear nuevas tablas y agregar nuevas columnas es muy normal en un proceso donde la programación y la administración de la base de datos no están estrictamente separadas. Una nueva característica puede crear nuevos datos que deben ir a alguna parte. Intenta estrictamente evitar eso y terminas con un modelo de plataforma interna .

El software bien escrito apenas nota esos nuevos objetos de la base de datos, por lo que nada se rompe solo por una nueva columna en alguna tabla.

Por otro lado, las columnas que caen regularmente o incluso las tablas son sospechosas. Una nueva característica nunca necesita que se elimine una tabla, por lo que esto podría ser una señal de que las personas trabajan completamente sin plan.

Si su base de datos se puede versionar y migrar fácilmente y tiene las pruebas para demostrar que cambiar las cosas no las rompió, entonces probablemente tenga un proceso bastante ágil.

A la luz de los comentarios, generalmente en el sentido de que hay un montón de vaqueros que se justifican a sí mismos como ágiles, corren gritando. Rápido. Y publique todo lo que pueda en thedailywtf.com para que todos podamos disfrutar de su horror.

Como la mayoría de las respuestas aquí en StackExchange, la respuesta debería ser 'depende'. En el desarrollo ágil, los requisitos y especificaciones se descubren durante la implementación.

Sin embargo, dado el desarrollo ágil, cuando un modelo relacional se normaliza adecuadamente, rara vez es necesario agregar nuevos atributos a las relaciones, las nuevas entidades generalmente deben referirse a las más antiguas, dado un modelo adecuado.

La mayoría de los desarrolladores no normalizan sus bases de datos debido a limitaciones de tiempo, pereza, incompetencia o complejidad de la consulta. Renormalizar requiere la transferencia de datos existentes, la modificación de los DAO, etc., etc., lo que genera un factor de riesgo.

Para responder a su pregunta, no, eso no es normal en un proceso ágil.

Donde puede parecer que se deriva de una actitud ágil es el ciclo de diseño / desarrollo / prueba de iteración corta de Agile, y el énfasis de Agile en soluciones livianas que cumplan con los requisitos conocidos, pero que estén bien estructurados para poder cumplir con los nuevos requisitos cambio mínimo Teniendo en cuenta estas dos cosas, podría decir que un desarrollador, sin saber lo que podría ocurrir en el futuro, pero sabiendo que su cambio no debería afectar a la base de datos de una manera que no se pueda deshacer, simplemente realiza los cambios necesarios en el esquema en el La forma "más ligera" posible, y luego a intervalos, varios conjuntos de cambios "ligeros" se refactorizarán en algo más permanente y estable.

Dicho esto, todavía no he trabajado con un desarrollador que se suscribió a la teoría y metodología Agile, y también pensé que, por cualquier motivo, era necesario crear y eliminar rutinariamente tablas en el esquema. Ágil no significa bofetada o atornillado. Si se le proporciona una historia que requiere la adición de un nuevo campo de datos que pertenece a un registro en particular, debe agregar el campo a la tabla. Si ese cambio rompe algo, usted descubre por qué y realiza otros cambios según sea necesario (puedo pensar en muy pocas cosas que se romperían al agregar una columna a una base de datos que se está consultando; si se rompe con este tipo de cambio, usted tener problemas mayores). La refactorización normalmente se limita al código; cambiar el esquema suele ser un proceso más complicado que cambiar el código, por lo que cuando se producen cambios en el esquema, generalmente se realizan con más cuidado, y al menos un poco de atención al conocimiento de la dirección futura del proyecto. Tener que reestructurar una parte o la totalidad de la base de datos indica una falla fundamental de diseño; ser ágil no significa que no haya un "plan maestro" de arquitectura básica y reglas de diseño a seguir mientras se construye orgánicamente el programa y la estructura de datos.

Ahora, hay casos en Agile donde lo que "sabes" ahora será contradicho por lo que aprenderás más tarde. Supongamos que tiene un requisito de que su sistema debe tener una dirección para cada persona. Como se trata de una relación 1: 1 y los datos serán necesarios en la mayoría de los casos, simplemente agregue los campos Dirección a la tabla Persona. Una semana después, recibe el requisito de que una persona pueda tener más de una dirección. Ahora es una relación 1: N, y para modelarla correctamente debe deshacer sus cambios anteriores, dividiendo los campos en una nueva tabla de direcciones. Esto no es una rutina, especialmente entre los desarrolladores senior. Un desarrollador experimentado verá que una Persona tiene una Dirección, la considerará como conceptualmente separada, y creará una tabla de Persona y una tabla de Dirección, vinculando Persona a Dirección con una referencia FK a un AddressID. Un esquema como este es más fácil de cambiar si cambia la naturaleza de la relación; sin crear o eliminar tablas de datos "anchas" enteras, la relación entre Persona y Dirección se puede modificar fácilmente de 1: 1 a 1: N a N: N.

No hay tanto enfoque en el diseño por adelantado cuando se trabaja con Agile, por lo que no veo que esto sea un gran problema, ciertamente para la primera versión.

Es difícil comentar sobre un sistema que tiene 700 tablas que no he visto, puede que las necesite todas, pero también podría ser el caso de que la base de datos no se haya administrado lo suficientemente bien.

Incluso bajo ágil, para un sistema grande, es bastante común tener a alguien / equipo a cargo del esquema.

Si realizan cambios de este tipo con frecuencia, en particular descartar tablas y columnas en aplicaciones en vivo, parece una señal de inexperiencia. No tiene nada que ver con el proceso que afirman seguir. 'Agile' no es una excusa para no sentarse y pensar en los datos que necesita almacenar y cómo se relacionan antes de comenzar a descifrar el código. Si descubren que están alterando más del 10-20% de la estructura inicial, para mí eso es un indicador de que no están pensando bien o no tienen mucha experiencia en el análisis de requisitos y el diseño de bases de datos, por lo que simplemente obtienen Mucho de eso está mal al principio.

Si bien parece que su equipo es simplemente una codificación de vaquero, realmente no debería haber nada de malo en refactorizar el código O las bases de datos. No es trabajo perdido, se está adaptando a una realidad recién aprendida.

Sugeriría que lo que necesita el equipo es un entorno limitado para probar los cambios, hacer algunas pruebas, rechazarlos a los usuarios y decidir si tienen sentido. En ese punto, integrar los cambios que tienen sentido, con pruebas de regresión adecuadas, en su esquema debería estar bien.

Ágil se trata de codificación, las bases de datos no son código. Cambiar una base de datos debe tratarse como remodelar una casa. La gente de alguna manera tuvo la creencia de que ágil significa actuar ahora, planear más tarde, lo cual es completamente falso. Incluso bajo métodos ágiles, se debe dar tiempo para la planificación, especialmente para algo tan importante como el diseño de bases de datos.

Mi último trabajo fue en un equipo como este. Cuando se utiliza un proceso ágil, los requisitos cambian. A veces, los cambios significan que una entidad existente necesita un nuevo atributo que resulta en una nueva columna en una tabla existente o se requiere una entidad completamente nueva que resulta en una nueva tabla con relaciones con las tablas existentes. Este tipo de cambios viene con el territorio y no se puede ignorar solo porque no desea tocar el esquema. El éxito se determina al mantener la integridad de sus datos cuando se migra de una versión de base de datos a la siguiente y adecuada prueba unitaria.

Solo trata de no hacer cambios innecesarios en tu esquema. Por ejemplo, si una característica requiere que se cree una nueva tabla, asegúrese de estar satisfecho con la definición de esa tabla antes de incorporarla y extenderla a su entorno de prueba. Tener que deshacer un cambio en el esquema de su base de datos después de que sus datos hayan sido migrados puede ser doloroso.