En desarrollo ágil, ¿debería intentar la persistencia en el archivo plano antes de la base de datos?

Alguien me explicó que, dado que en el desarrollo ágil, la política y la lógica de la aplicación deberían ser más importantes que los detalles como el método de persistencia, la decisión de persistencia debería tomarse al final. Por lo tanto, podría ser una buena idea comenzar con una persistencia más simple, como archivos planos, hasta que lleguemos al punto en que la debilidad de este método sea evidente, y solo entonces cambiemos la persistencia, por ejemplo, utilizando una base de datos relacional.

¿Es esto cierto o entendí mal el concepto? ¿Es así como el equipo ágil suele crear aplicaciones? ¿Cuáles son las razones para ello y cuándo no debería adoptar este enfoque?

El concepto que se transmite es algo que definitivamente forma parte de lo ágil y relevante, la idea de llevar las cosas al último momento responsable.

Sin embargo, el ejemplo tomado en realidad se basa en una suposición completamente falsa para comenzar:

que es más fácil / menos trabajo implementar una base de datos de archivo plano que usar un RDBMS. - A menudo completamente falso

El ejemplo debería ser: la capa de persistencia se mantiene con la implementación más simple posible hasta que se decida que es inadecuada.

Para muchos equipos de desarrollo, obtener una base de datos para hacer esto es cuestión de una o dos horas (o 15 minutos para una base de datos pequeña con ORM), mientras que una base de datos de archivo plano con la que no necesitan entrometerse puede ser una enorme molestia y molestia porque tienen que escribir a mano todo el código de tipo de búsqueda y construcción de tabla de datos manualmente, cuando una base de datos puede ser tan simple como crear una tabla en una interfaz de usuario, agregar algunas columnas y luego hacer que un ORM genere todo más lo necesitas

Además, si no conoce su capa de persistencia para comenzar, es un acto aún más apropiado comenzar con un RDBMS común que su equipo conoce bien, ya que hacer el cambio más tarde de archivo plano a RDBMS es mucho más grande que más tarde cambiando de un RDBMS a otro. Hay muchas herramientas para convertir de la mayoría de los RDBMS comunes a otros, y consejos y cosas por el estilo, ya que es una ruta muy transitada. Hay muy pocas herramientas para convertir un archivo plano a cualquier RDBMS dado en el que su archivo plano tiene algún formato propietario para el que las herramientas no se han escrito previamente aparte de sus propias bibliotecas.

En resumen: el concepto es correcto y preciso, pero el ejemplo se basa en una suposición terriblemente grande y a menudo (casi siempre) inexacta .

Como sabe que usará una base de datos, no tiene mucho sentido escribir código para manejar archivos planos. Puede pasar por algunas iteraciones usando algunos CSV de solo lectura, pero rápidamente se encontrará escribiendo código que sabe que tirará.

Una cosa que puede hacer para simplificar la complejidad inicial mediante el uso de algo como SQLite (una biblioteca que le brinda una base de datos SQL sin servidor que se almacena en un archivo). Tiene un sistema de tipo flexible para que no tenga que comprometerse seriamente con un esquema, ningún servidor para configurar / conectarse y reconstruir su base de datos es tan simple como eliminar un archivo. También le permite incluir simplemente la imagen de la base de datos junto con el código en el control de versiones si es necesario.

Es un ejemplo, utilizado para demostrar un concepto, en lugar de un concepto en sí mismo.

El concepto es que no tome una decisión arquitectónica hasta el último momento responsable , pero no más tarde. Pero, en realidad, a menudo tienes una decisión sobre la base de datos que vas a usar desde el principio. Puede que no sea perfecto, pero es un hecho.

Una vez que se toma esa decisión, no la evitas activamente. Almacenar algo en una base de datos existente es a menudo tan fácil como almacenarlo en un archivo plano.

Pero cambiar de MySql en Linux a SQL Server en Windows podría no ser tan simple como cambiar de un archivo plano en cualquier lugar a SQL Server en Windows. Ese es el verdadero punto. Entonces, si bien hay dudas sobre la solución final, tome la opción más simple posible, teniendo en cuenta el cambio. Una vez que se toma una decisión, cúmplala.

¿Qué persiste?

Estoy en un equipo ágil y para una aplicación, persistimos casi todo en la base de datos. Eso sí, si no lo hiciéramos, entonces esta aplicación no tendría mucho que hacer: persistir en una base de datos es una gran parte de su razón de ser .

Entonces: ¿Qué persiste y qué hace su aplicación? Si a la aplicación no le importa dónde persisten sus datos, puede escribir una pequeña capa que tome la decisión (esa decisión puede almacenarse en un archivo de configuración en algún lugar) de archivo plano frente a base de datos. Creo que se necesita para evaluar su aplicación y sus datos y decidir si tiene sentido en el caso específico de invertir tiempo en la persistencia de base de datos, o simplemente leer / escribir archivos planos (que será probablemente ser más rápido en términos de tiempo de desarrollo).

Mucha gente malinterpreta ese aspecto de ágil, lo que significa que no deberían planificar con anticipación las características futuras. Nada mas lejos de la verdad. Lo que no debe hacer es permitir que la planificación de funciones futuras retrase la entrega de valor a sus clientes ahora.

Cómo se aplica eso a algo como la persistencia depende mucho de su aplicación. Uno de mis proyectos de hobby actuales es una calculadora. Eventualmente, me gustaría poder almacenar constantes y funciones definidas por el usuario, y guardar el estado cuando cierre el programa. Eso requiere persistencia, pero ni siquiera he comenzado a pensar qué forma tomaría. Mi programa será muy útil sin persistencia, y agregarlo ahora agregará un retraso significativo a mi primer lanzamiento. Prefiero tener una calculadora que funcione con menos funciones que ninguna mientras espero que sea perfecta.

Otro proyecto hobby mío es para la corrección de color de video y fotografía. Esta aplicación será completamente inutilizable sin poder guardar mi trabajo en progreso, y el código necesario para hacerlo es omnipresente en todo el programa. Si no lo hago bien desde el principio, cambiarlo podría ser prohibitivamente difícil, por lo que he dedicado bastante esfuerzo a la persistencia por adelantado.

La mayoría de los proyectos se encontrarían en algún punto intermedio, pero nunca debería sentirse mal por planificar futuras funciones si agrega poco o ningún esfuerzo adicional ahora. Las bases de datos pueden ser complejas, pero la mayor parte de esa complejidad está oculta detrás de una interfaz sólida y bien probada. El trabajo que tendrá que hacer en su aplicación puede ser menos para una base de datos que un archivo plano, debido a todas las características que una base de datos le brinda de forma gratuita. Hay opciones "híbridas" como SQLite si aún no desea lidiar con la molestia de un servidor de base de datos.

Creo que te estás enfocando en los valores incorrectos. En ágil, el valor empresarial está en foco. Usted crea un producto para entregar valor comercial a algunos usuarios finales.

Si crea la capa de persistencia tarde, o la inventa en el camino, es su estrategia para entregar valor comercial al cliente. No creo que el término "ágil" en sí mismo dicte si debe hacer uno u otro.

El punto de vista sobre el aplazamiento de la estrategia de almacenamiento de datos se aboga en esta presentación por Robert C. Martin (uno de los autores del manifiesto ágil).

Es una muy buena presentación, puedo recomendar que la vean.

Pero no estoy de acuerdo con eso! Al menos hasta cierto punto.

No creo que pueda llamar a una historia de usuario para "Hecho", si la historia de usuario involucra datos que deberían persistirse, y en realidad no tiene implementado ningún tipo de persistencia.

Si el propietario del producto decide que ahora es el momento de ponerlo en funcionamiento, no puede hacerlo. Y si no ha comenzado a implementar la persistencia hasta el final del proyecto, tampoco tiene información sobre cuánto tiempo tomaría implementar la capa de persistencia, lo que lo convierte en un riesgo importante para el proyecto.

Los proyectos ágiles en los que he trabajado no han diferido la estrategia de acceso a datos. Pero se ha desacoplado, lo que nos permite cambiarlo en el camino. Y el esquema completo de la base de datos no está diseñado por adelantado. Las tablas y columnas se crean a lo largo del camino a medida que se requieren para implementar el usuario almacenado que, al final, brinda valor comercial.

Se necesita buen juicio y experiencia para ver qué preguntas deben responderse primero al embarcarse en un nuevo proyecto.

Si el producto final aún se desconoce, entonces la construcción / creación de prototipos rápidamente lo ayudará a resolverlo, y sí, iterar de manera ágil ayudará. Eso, por supuesto, introducirá riesgos, como descubrir al final del proceso que la implementación de persistencia llevará más tiempo del que comunicó a sus partes interesadas.

Si el producto final es bien conocido, comprender cómo funcionará la persistencia en su aplicación podría ser más importante para saber desde el principio. El riesgo es que encuentre problemas con la especificación de su producto más adelante en el proceso de desarrollo.

¡Los archivos planos no son simples!

Permiten almacenamiento y eso es todo. La estructura de los datos, las rutas de acceso, etc., dependen de usted y hay muchas maneras de equivocarse.

Existen razones por las que existen bases de datos y una de ellas es hacer las cosas más simples para los desarrolladores.

La mayor parte de mi desarrollo se realiza para grandes sistemas dentro de grandes empresas. Siempre tenemos un modelo de datos completo y bien pensado antes de continuar con cualquier diseño o desarrollo adicional. Un modelo de datos lo ayuda a comprender su problema y permite una implementación limpia.

Los elementos de datos olvidados, las estructuras de datos no coincidentes y otras pesadillas pueden evitarse mediante la producción de un modelo de datos por adelantado.

Puede dejar su elección real de tecnología de base de datos hasta después del modelo de datos. Pero la mayoría de las tecnologías de "persistencia" están estrechamente ligadas a la programación e incluso a los estilos de diseño. Si codifica para una base de datos relacional y luego decide cambiar a un valor de clave turbia, necesitará reescribir completamente la mitad de su código.

Si comienza con archivos planos y cambia a una base de datos relacional, probablemente terminará tirando la mitad de su código ya que sus desarrolladores habrán perdido el tiempo implementando una base de datos pobre.

¿Debería intentar la persistencia en un archivo plano antes de la base de datos?

Sí, deberías probarlo. Especialmente si nunca lo has probado antes. No importa cómo resulte, aprenderás algo.