archivo

Archivos diarios: septiembre 3, 2011

Cuando desde técnicas ágiles como la programación extrema (XP) se hace especial hincapié en que el mejor comentario del código es el propio código, no se hace por simple capricho sino porque la inclusión de comentarios incorpora un elemento más a tener en cuenta en el mantenimiento del software (esto no supone la prohibición de utilizar comentarios, sino la concienciación de lo que supone utilizarlos de manera que solo se utilicen cuando sea preciso y en la medida de lo posible en aquellas zonas del programa menos susceptibles a cambios).

Sobre este aspecto Dave Storer piensa lo siguiente (traducción libre): “No te dejes embaucar por los comentarios, son terriblemente engañosos. Depura solo el código”.

Tom DeMarco es un ingeniero de software de reconocido prestigio a nivel internacional. Empezó su trayectoria profesional en el año 1963 en Bell Laboratories, a finales de la década de los sesenta empezó a trabajar en una firma francesa, lo que lo llevó a trabajar en proyectos relacionados con banca en diferentes países de Europa. En la década de los ochenta fundó junto a otros socios una consultora en Nueva York especializada en métodos y gestión en el proceso de desarrollo de software.

A toda esta actividad profesional hay que destacar que también es autor de libros, artículos, ha sido conferenciante y profesor y es considerado como uno de los creadores en la década de los ochenta del análisis estructurado.

Una trayectoria profesional extensa, con multitud de proyectos en diferentes países, hace que debamos tener en cuenta las reflexiones de Tom DeMarco, como por ejemplo la siguiente: “La documentación voluminosa es parte del problema, no de la solución”.

¿De qué sirve documentación inmanejable que se va a quedar desactualizada más pronto que tarde?, ¿de qué sirve documentar por documentar?.

La documentación debe acompañar al proceso de desarrollo de software, ser parte de él, no una parte independiente. Debe servir al proyecto y no ser un obstáculo en el mismo.

Responsibility-driven design es una técnica de diseño orientado a objetos propuesta por Rebecca J. Wirfs-Brock and Brian Wilkerson.

Rebecca J. Wirfs-Brock es una autora y consultora americana especializada en los ámbitos del diseño y programación orientada a objetos, con una gran experiencia desarrollada en diferentes empresas.

Brian Wilkerson es otro especialista en programación y diseño orientado a objetos, que ha desarrollado su carrera profesional en el mundo de la consultoría.

A principio de los 90 fueron coautores de los libros en los que formulaban esta técnica de diseño.

El diseño orientado a la responsabilidad se basa en dar respuesta para cada tipo de objeto a las siguientes preguntas:

– ¿De qué acciones es responsable el objeto?
– ¿Qué información comparte el objeto?

Proporcionando una alternativa a los diseños que consideraban a los objetos como datos y algoritmos. En este caso los objetos se consideran como la conjunción de roles y responsabilidades, los cuales conviven cooperando dentro de la aplicación.

Esta técnica de diseño está claramente inspirada en la mecánica de funcionamiento cliente/servidor, en la cual se define un contrato que rige el funcionamiento de los objetos implicados de manera que el cliente solo puede realizar los tipos de solicitudes/peticiones que se hayan definido y el servidor debe responder.

Es una técnica que también huye del conocimiento de los detalles de cómo un objeto realiza una acción u obtiene un resultado, fomentando de esta forma el concepto de encapsulamiento. Además, para reforzar esta cualidad, Wirfs-Brock y Wilkerson abogan por la existencia de un control de grano fino de visibilidad de los objetos.

No solo es una técnica que persigue el encapsulamiento sino la abstracción al ocultar, al menos en términos de diseño, la relación entre datos y comportamiento, ya que solo se debe pensar en responsabilidades a nivel de conocer, hacer y decidir.

En la técnica, por tanto, tendremos una comunidad de objetos que tienen asignadas responsabilidades específicas y que conforman un modelo colaborativo de funcionamiento en el que los mecanismos de colaboración están claramente definidos constituyendo de esta forma una arquitectura en la que existe un comportamiento distribuido.

De esta forma podemos realizar las siguientes definiciones:

¿Qué es una aplicación? Un conjunto de objetos que interactúan.
¿Qué es un objeto? La implementación de uno o más roles.
¿Qué es un rol? Un conjunto de responsabilidades
¿Qué es una responsabilidad? La obligación de realizar una tarea o de conocer un determinado tipo de información.
¿Qué es una colaboración? A la interección entre objetos y/o roles.

Tal y como se ha comentado anteriormente, esta técnica considera a los objetos como algo más que paquetes que solo encierran lógica y datos, ahora se en función de los roles que desempeñen a controladores, proveedores de servicios, titulares de información, interfaces con el exterior, etc…

Muchas empresas de desarrollo de software han ganado dinero a espuertas gracias a esto, en ocasiones propiciado por ellas mismas y en la mayoría de los casos provocado por los mismos clientes. En cualquier caso no hecho la culpa de ello a quien es contratado, sino a quien contrata.

Esto suele suceder en organizaciones donde la gestión informática está descentralizada, fragmentada y sin la existencia de una política real de coordinación. En situaciones como esta cada departamento TIC suele hacer la guerra por su cuenta, en unos casos por ser autosuficiente, en otros por considerar que son capaces de hacer su trabajo mejor que el resto y en otras por un mero afán de ser dueño de un cortijo (la diferencia con la autosuficiencia es que en el primera caso el objetivo es no tener que depender de nadie más para garantizar el funcionamiento y disponibilidad de los sistemas, mientras que en el segundo el principal objetivo es mantener una parcela de poder).

Es cierto que las problemáticas en diferentes organizaciones puede ser distinta a la hora de enfocar un mismo proceso pero en muchos casos la solución no debe pasar por desarrollar un sistema específico para cada casuística sino en determinar qué aspectos son comunes, cuáles son divergentes y cuáles son los motivos que provocan esa diferencia para intentar reducirla, antes o durante el proceso del desarrollo del sistema único y si no fuera posible por lo menos reaprovechar toda la infraestructura que sea posible.

De esta forma tendríamos proyectos mejor dotados presupuestariamente y por tanto con una mayor margen para intentar, si el proyecto evoluciona racionalmente, que el resultado final salga de la mejor manera posible.

La bonanza económica de hace unos años constituyó un caldo de cultivo adecuado para el carácter independiente y autónomo de muchos departamentos TIC, yo tengo el dinero, yo me lo guiso y yo me lo como, la consecuencia de eso es que ahora tienen múltiples sistemas que mantener y sin dinero para poder hacer frente a los mismos. Si se hubiera sido más solidario en su momento ahora podría repercutirse los costes de mantenimiento entre diferentes departamentos y la cosa sería diferente.

Pero no solo hay que echar la culpa a los departamentos TIC (que la tienen) sino también a la falta de una coordinación desde la organización. Si no existen normas rígidas al respecto se abre vía libre a que cada cual haga la guerra por su cuenta. No es fácil establecer un marco de trabajo común, un roadmap general, pero si no se intenta, difícilmente se podrá llevar a cabo.

Esto pasa tanto en el marco de entidades privadas como públicas y es un aspecto en el que hay que tratar de mejorar, no ya por intentar hacer las cosas bien, sino porque en momentos de crisis económica como el actual porque no hay otra alternativa.,