Pages Menu
Categories Menu

Posted by on Feb 23, 2011 in arquitectura, buenas prácticas, calidad | 2 comments

Porque las estructuras de datos deben estar ocultas en un sistema software (2/2)

Segunda parte del post de ayer, con el segundo problema… y una anécdota final.

2 – El módulo externo que acede a la estructura de datos de otro podría leer datos no actualizados. Por ejemplo, un módulo podría guardar el dato edad y no tenerlo actualizado. Si se accede directamente a una estructura de datos nadie se responsabiliza de que lo que lee esté actualizado. Pero si accedemos a través de una interfaz, de un servicio, un método, un “getEdad”, este puede asegurarse de actualizar el dato en el momento en que se pide. Además de que una cosa son las estructuras de datos y otra la información que un módulo nos puede proporcionar, que es sus estructuras de datos o atributos + los cálculos que puede hacer con ellos.

Contaba esto el otro día en una de mis clases de la Universidad Rey Juan Carlos y como siempre que cuento esto alguien preguntó “pero entonces ¿cómo vamos a evitar que un módulo qué pide información sepa qué esa información es de de tipo entero, booleano o lo que sea?”. Esta regla no habla de no conocer tipos de datos primitivos, eso no es el gran problema, la regla se centra en no conocer “estructuras de datos”.

Y también siempre que sale este tema me viene el recuerdo de tantos pobres proyectos que por incumplir esta práctica se fueron poco a poco convirtiendo de “dinosaurios” cada vez más difíciles de evolucionar y modificar. Recuerdo especialmente cierta aplicación, de tamaño importante, cuyos desarrolladores incumplían sistemáticamente esta práctica. Y los módulos estaban totalmente acoplados a estructuras de datos a las que accedían directamente. Destacaban especialmente los accesos a la base de datos, a la que todos los módulos accedían sin  pasar por una interfaz o fachada de servicios. Todos los módulos tenían un trocito de SQL dentro. SQL no estándar, dependiente de un sistema gestor de base de datos (SGBD) concreto. Y llegó el día en que se planteó la cuestión de cambiar el SGBD, porque el fabricante ya no daba más soporte, al ser una versión antigua. Pero, claro, para cambiarlo había que recorrer muchos cientos de trozos de código revisando y actualizando su SQL. Y el coste y riesgo de dicha migración era tan grande que se decidió seguir utilizando el SGBD antiguo y pagar “eternamente” un soporte especial al fabricante.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

2 Comments

  1. Con respecto a tu anecdota, tambien tengo un caso similar, lo conocí hace ya 8 años, a la fecha siguen igual, y en un par de años mas, siempre llegaran al mismo punto de hace 8 años, tienen que cambiar.

    Saludos

  2. Hola Javier…..

    Me dió gusto leer el artículo, hace unos años pasé por lo mismo, a la fecha se sigue pagando el soporte. Pensé que no me toparía con otro caso igual, pero si la historia se repite, pero esta vez si vamos a migrar….

    Saludos y desearte lo mejor para este nuevo año 2014

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This