La Ley de Demeter

Parece que esta bitácora va de leyes, así que ahí va otra:

No hables con desconocidos

Esta regla fue formulada en la Northeastern University en 1987 por Ian Holland. Y la explica magistralmente el blog Refactoring.

Es una regla comúnmente aceptada de buen Diseño, que se basa en el mínimo conocimiento del modelo de objetos, de modo que se reduzca el número y complejidad de las interrelaciones.

Aplicado la ley de Demeter a objetos, tendríamos que una operación de un objeto sólo tendría que utilizar:

• Las operaciones propias del objeto.

• Los objetos que tenga asociados o sean atributos del objeto.

• Los objetos que recibe como parámetro la operación.

• Los objetos que cree la operación.

Tags: Metodología, Programación

 

Cuando ser Ágil

Ya lo dice Martin Fowler en su artículo sobre La Nueva Metodología: Ágil no es para todo el mundo. No hay reglas predeterminadas que nos ayuden a determinar claramente cuando utilizar una metodología Ágil o, por el contrario, una metodología clásica.

En cualquier caso, ahí van unas ideas:

Dedicación del cliente.

Difícilmente podemos aplicar una metodología ágil si no contamos con la adecuada involucración del cliente. En ese caso es mejor tomar requisitos muy concienzudamente al principio.

Tamaño del proyecto.

El tamaño no es una limitación en si misma, pero a mayor tamaño más complicado es implantar una metodología Ágil.

Estabilidad de los requerimientos.

Cuando los requerimientos cambian, una metodología Ágil puede ayudar a adaptarse a ellos. Para requisitos estables, quiza una metodología clásica ayude a evitar el re-trabajo.

Criticidad.

Yo personalmente no utilizaría una metodología Ágil para diseñar y construir un sistema del que dependan vidas humanas: los sistemas de navegación de un avión, por ejemplo.

Experiencia.

Esto es obvio. No uses metodologías Ágiles con equipos sin experiencia. Estas metodologías se basan en la capacidad y madurez de los miembros del equipo.

Apetencia.

Otra obviedad. Si no te apetece usarlas, pues no las uses.

Tags: Metodología, Programación

 

Dos mil líneas de código menos

Esta curiosa anécdota puede servir para ilustrar como las medidas de productividad de la Ingeniería de Software a veces nos llevan en la dirección contraria a la que quisieramos ir.

Es muy habitual medir la funcionalidad o la complejidad de un determinado software y, por tanto, la productividad de quienes lo han escrito, en número de líneas de código. Pero a veces se puede hacer más con menos.

Bill Atkinson, autor del programa QuickDraw, en el año 1982 estuvo trabajando en su optimización. Tras escribir de nuevo ciertos algoritmos para hacerlos más simples y generales, consiguió que éstos se ejecutaran 6 veces más rápido, resultando además que la nueva versión tenía dos mil líneas de código menos que la anterior.

Cuando tuvo que rellenar el parte de trabajo y llegó a la casilla de número de líneas de código producidas escribió: -2000.

Dicen que desde ese día no le hicieron rellenar el informe nunca más.

Tags: Complejidad, Programación

 

Sistemántica

Repasando las citas y los autores que han hablado sobre la complejidad de los sistemas en general y los sistemas de información en particular, he dado con el libro Systemantics (Systemantics: How Systems Really Work & Especially How They Fail ) escrito en 1977 por John Gall. Mi cita favorita de este autor es:

Un sistema complejo que funciona, invariablemente ha evolucionado de un sistema simple que funciona.

Pero esto no es todo, porque continúa:

Un sistema complejo diseñado desde cero nunca funciona, y no se puede arreglar para que lo haga. Hay que volver a empezar partiendo de un diseño simple.

He visto demasiados sistemas complejos fallidos, y cualquier software verdaderamente complicado en el que piense ha tenido una versión 1.0 – comercial o no – y una larga evolución.

Mi último fracaso fue un sistema que se concibió simple pero no fuí capaz de mantener así, pues el usuario se pasó ¡casi dos años! redefiniendo e incluyendo nuevos requerimientos, hasta que se transformó en un diseño demasiado complicado como para ser abordable con garantías.

Tendría que haberle regalado el libro de John Gall a mi cliente. Y yo haberlo tenido encima de mi mesa todo ese tiempo.

 

Lenguajes Específicos de Dominio (II)

Como prometí, empiezo la lista de lenguajes específicos de dominio, con algunos de los más importantes o más utilizados.

ActionScript

Es un lenguaje de programación basado en ECMAScript (la misma base que el JavaScript) utilizado para el “scriptting” de aplicaciones y animaciones en Adobe Flash. Es un lenguaje centrado en la construcción de elementos visuales que forman parte del Interfaz de Usuario, animaciones, formularios, etc.

Business Process Execution Language (BPEL)

No podía evitar meter este…

El BPEL es un lenguaje basado en XML que permite definir procesos de negocio, de ejecución larga y asíncronos, que interactúan con entidades externas, como servicios Web, y que pueden ser ejecutados.

Job Control Language (JCL)

Hay muchos de estos. Su especialidad es la de controlar y ejecutar instrucciones y proramas por lotes. Cada Sistema Operativo tiene el suyo propio. El JCL es para la familia de ordenadores IBM/360, lo que sh o ksh son para Unix, REXX para OS/2 y DOS para el antiguo sistema operativo de PC en versiones MS, IBM o PC.

Structured Query Language (SQL)

No es un lenguaje de programación propiamente dicho, sino un lenguaje declarativo, aunque muchas de sus extensiones sí que lo son. Entre ellas nos encontramos el PL/SQL de Oracle, o el Transact-SQL de SQL Server.

Estos últimos languajes incorporan manejo de variables, control de flujo y otras características que permiten programar la capa de acceso a datos de una aplicación, siempre que éstos residan en una base de datos relacional.

Extensible Stylesheet Language Transformations (XSLT)

Este lenguaje tiene como objetivo la conversión de formato de documentos XML. La programación de dicha conversión se realiza mediante reglas de plantilla que permiten borrar, añadir o duplicar contenido al documento original, reordenarlo o reestructurarlo, o realizar transformaciones más complejas en función de las reglas programadas.

Seguiré completando esta lista…