Diseño de la base de datos

2012-08-20T10:30:00.004-07:00

En la entrada anterior argumentaba acerca de diseñar toda la base de datos al inicio del proyecto, y expresaba que esta aproximación no es muy adecuada bajo un enfoque agil, entonces ¿Cómo se debería hacer esta tarea?

Hace un tiempo, la empresa para la que laboro invito a Iva n Vallejo (Es uno de los pocos en el mundo, que ha escalado los picos mas altos sin ayuda de un balón de oxigeno), para que nos diera una conferencia. Hasta ese momento no sabia mucho (o nada) acerca del montañismo.

Él nos explico como hacía para escalar una montaña tan grande como el Everest, nos conto que el esfuerzo que se requería era muy alto, y que cada vez que tenia que escalar alguna montaña, tenía que prepararse cerca de un año, subiendo otras montañas, corriendo, etc.

Hasta ese momento yo pensaba que escalar una montaña implicaba una vez que se estaba lo suficientemente preparado, se iba a la montaña y se escalaba en un solo tramo hasta llegar a la cima; lo que nos mencionó ese día fue diferente, él nos contaba el proceso que se seguía, primero se hace un asenso hasta un punto en el que se quedaban un tiempo para aclimatarse, luego bajaban. Pasaban unos días y subían nuevamente acampando en el primer punto y luego subían aún mas alto acampaban y se aclimataban, luego volvian a bajar y repetian el proceso para poder aclimatarse, hasta que finalmente atacaban la cima. Como puede notarse, todo esto demoraba bastante tiempo, y no era (como yo creia) prepararse e ir a atacar directamente la cima.

Bueno, y todo esto que menciono ¿que tiene que ver con el diseño de base de datos?, pues mucho, me parece que el software en general y la base de datos en específico se deberían desarrollar utilizando esta aproximación.

Primero, antes de afrontar un proyecto de software nos deberiamos preparar (no me refiero a la Universidad), en la tecnología que utilizaremos (o que utilizamos). Podriamos hacer esto asistiendo u organizando dojos (de programación, integracion continua, administración de base de datos, etc), asi nos aseguramos que tenemos los conocimientos frescos y vamos entrenando para afrontar el proyecto. Y no solamente hacer los entrenamientos antes de iniciar el proyecto, tambien cuando el proyecto esta en marcha.

Al comenzar la construcción del software (y por lo tanto de la base de datos), se debe hacer de a pocos, subir un tramo (y aclimatarnos), para luego seguir sabiendo que estamos haciendo las cosas bien. Esto lo hacemos con las revisiones constantes del producto (reviews). Una vez que sabemos que el tramo que hicimos esta correcto y cumple con las espectativas del cliente avanzamos.

Luego de haber avanzado correctamente es bueno descender del lugar en el que estamos y revisar que es lo que el equipo hizo correctamente y lo que se puede mejorar, esto seria hacer retrospectivas, luego subir nuevamente pasar por el punto que entregamos y construir mas software valioso para la empresa.

Debemos repetir este proceso hasta que llegue el momento de atacar la cima (finalizar el proyecto) y ver que en realidad nos faltaba un tramo pequeño, porque todo el software que hicimos lo entregamos y los usuarios dieron su conformidad.

No estoy diciendo nada nuevo, simplemente estoy haciendo recuerdo que existen muchas herramientas que nos ayudarán a construir software de calidad.

GRAN DISEÑO DE LA BASE DE DATOS

2012-07-17T08:13:00.000-07:00

Hace unos días estuve viendo la película llamada Amor sin escalas (Up in the Air), en esta película, el protagonista, empezaba diciendo (en una conferencia):
“Imaginen por un segundo que llevan una mochila. Quiero que la llenen con todas las cosas que hay en su vida. Empiecen con las cosas pequeñas, las cosas de los estantes, cajones… Luego las cosas más grandes. Ropa, electrodomésticos, lámpara, televisor…, La mochila comienza a pesar. Sofá, coche, casa… Quiero que lo metan todo en la mochila; ahora imaginen caminando con esa mochila…, probablemente no puedan dar un paso”.

Al escuchar eso, lo relacione con el desarrollo de software, con la arquitectura y el diseño de la base de datos. Al establecer una arquitectura o al pretender hacer un modelo de datos al principio del desarrollo (BDUF) es como llenar una mochila para el equipo, mientras mas se avance en el modelo de datos, más difícil (menos ágil) será el camino; siendo, muchas veces, esto un impedimento para avanzar.

A veces el tener un modelo de base de datos (supuestamente terminado) al inicio del proyecto solamente causa retrasos en el desarrollo porque los desarrolladores podríamos ver algún tipo de error en el modelo; modificar este modelo sería mucho mas complicado porque mover una tabla que ya esta diseñada podría afectar otras tablas. Incluso hacer esto es un completo desperdicio de tiempo y esfuerzo, ya que las tablas que podrían estar involucradas en el cambio no se usan hasta muy avanzado el proyecto.

El diseño de la base de datos (Sea relacional o no), debería ser un diseño emergente, el modelo va a surgir conforme va avanzando el desarrollo del software. Y sobre todo (al usar TDD), todo el modelo esta respaldado y probado. Y haciendo las cosas al estilo "Lean", nuestro modelo en cualquier todo momento tendrá unicamente tdatos que aporten un valor para la empresa.

Entonces, lo que se debería hacer en el desarrollo de Software, es no llenar la mochila con una gran arquitectura o una gran diseño de base de datos, sino permitir que el este vaya evolucionando y creciendo de acuerdo a las necesidades del negocio

Pero ¿Y como se puede lograr esto?, al principio del desarrollo se entregaria un MVP (Minimum Viable Product), con esto, el negocio tendría un producto usable y que agrege valor al mismo. Sin preocuparse demasiado en aspectos que en "algún futuro" se utilizarán (esto no quiere decir que no las tengamos presentes). No podemos desarrollar un software para que soporte un millon de usuarios cuando actualmente solamente lo usan cien; cuando tengamos mas demanda la arquitectura tendrá que ir evolucionando y adaptándose a las nuevas necesidades de nuestro software.

Diseñar la arquitectura de un sistema o la base de datos (Cuando se hace bajo el enfoque BDUF) toma demasiado tiempo, si el proyecto se detiene (por algun motivo), en el momento del diseño, ese proyecto nunca existió porque los papeles (diseño) no es software y por lo tanto ese software tampoco existió. Si por el contrario empezamos con un diseño Agil, en poco tiempo tendremos software funcionando (y de calidad) que dará valor al negocio.

Nadie puede predecir que es lo que ocurrirá en el futuro, y menos nosotros; gastar energías en un "por si acaso", es desperdicio, y no se debería hacer. Asi que debemos enfocarnos en hacer software funcional y que aporte realmente al negocio.

dbagil

Diseño de la base de datos

GRAN DISEÑO DE LA BASE DE DATOS