miércoles, 2 de noviembre de 2011

[2 de 97]. Comienza con un esqueleto funcional.


Post publicado originalmente entre Mayo del 2009 y Enero del 2011 en mi anterior blog.
Pertenece a una serie sobre arquitectura de software, replicaré los comentarios ya que, a mi parecer, son lo más importante de la serie.

Puedes encontrar el listado de esta primera entrega en este enlace.

Siguiendo con los comentarios sobre el libro:

El axioma de hoy:
Start with a walking skeleton.


Punk!!!!

Clint Shank, es un desarrollador de software y mentor de Sphere of Influence, Inc. una empresa de diseño e ingeniería de servicios.

Aquí un fragmento de su axioma:

---
Start with a walking skeleton.

One very useful strategy for implementing, verifying, and evolving an application architecture is to start with what Alistair Cockburn calls a Walking Skeleton . A Walking Skeleton is a minimal, end-to-end implementation of the system that links together all the main architectural components. Starting small, with a working system exercising all the communication paths, gives you confidence that you are heading in the right direction.

Once the skeleton is in place, it's time to put it on a workout program. Bulk it up with full body workouts. This means implement incrementally, adding end-to-end functionality. The goal is to keep the system running, all the while growing the skeleton.
---

Para mi es una las estrategias favoritas para atacar una integración muy compleja o con un equipo mediano/grande de desarrolladores.

Coincido completamente con el comentario de Clint Shank, en desarrollos pequeños, una sola persona puede realizar todo a su modo y no requiere de este tipo de estrategias.
La idea es sencilla, se debe lograr tener un esqueleto funcional, de extremo a extremo, de la integración que va a realizar.

El objetivo también es sencillo; verificar que ese camino de extremo a extremo sea eficiente ( y descubrir a tiempo las implicaciones que puede tener construirlo/fortalecerlo/modificarlo).

La utilización de objetos y servicios mock pueden ayudarnos bastante con esta estrategia de implementación. Imaginemos un escenario hipotético (y muy común) en donde debemos realizar la integración de varios sistemas que incluyen unos servicios de muy bajo nivel (que aun no se han creado), pasando por una transformación de datos(no del todo definida), seguida de un traducción(un poco difusa) y finalizando con una visualización(aun en diseño).
  • Nuestro esqueleto haría uso de objetos mock para:
  • Simular la llamada a los servicios de más bajo nivel.
  • Simular la transformación de datos, recibiendo la salida del paso anterior como entrada a este paso.
  • La traducción recibe unos datos válidos pero arbitrarios y devuelve el formato esperado por la capa superior.
  • El componente de visualización únicamente se encarga de visualizar lo que recibe del paso anterior.
Y nuestro esqueleto esta completo.

A partir de él podemos ir creciendo y fortaleciendo nuestra aplicación sin afectar de manera significativa las capaz superiores, la construcción del esqueleto como mencionaba, nos dan la luz suficiente para saber el costo de modificar alguno de los puntos de conexión (firmas) de cada "hueso" del esqueleto..... y, conocer el costo (no siempre cabe aclarar) incentiva a definir puntos de conexión mucho más "desacoplados".

¿Y ustedes? ¿Con cuantos esqueletos se han topado?
Sólo cuentan los que vemos al inicio del desarrollo, los que vemos al finalizar el proyecto no cuentan (es más ¡¡¡ Ni los mencionen !!!)

;)

Saludos!!
---
RuGI

Comentarios:
---
En la misma idea, a mi en lo que me gusta "inspirarme" es en la teoria de autómatas de estados, donde la idea es partir de un "estado correcto" y solo permitir transiciones a otros "estados correctos".

Entendiendo por estados correctos, un sistema funcional.
Asi que el primer paso es ir a un sistema funcional mínimo y de ahí ir avanzando a trozos que te lleven a otro sistema funcional mas completo, sin dejar nunca el sistema en modo inestable.

El problema es que te lo dejen hacer, por que donde yo estoy lo llevan estilo años 70 y la idea "hay que hacerlo todo completo a la primera y bien"... :(

Enviado por GreenEyed en mayo 25, 2009 a las 12:56 AM CDT.
---

Hola GreenEyed!!

Esta interesante el enfoque que das utilizando autómatas, se me ocurre que, quizá podrían darse espacios para "estados de error/incorrectos" siempre y cuando se pudiese regresar al último estado "correcto".

Y tienes razón, lo más difícil siempre es que te permitan realizar con cierto grado de libertad las estrategias que mejor te parezcan para atacar un problema.

Y, creo recordar ese punto "político" se menciona también en el libro.

Saludos!!!

Enviado por RuGI en mayo 25, 2009 a las 09:51 AM CDT.
---
Hola!
Si, no quería decir que no pases nunca por estados incorrectos, pero, por decirlo así, en producción nunca ha de haber estados incorrectos, y la planificación ha de ser "de oca a oca y tiro por que me toca", no "avanzar, avanzar y ya veremos donde acabamos".

De todas formas, es metafórico y por lo tanto no es exactamente un fiel reflejo de la realidad. En cambio algunos de mis programas si me gusta enfocarlos desde el punto de vista de autómatas de estados, especialmente los que tienen que ver con comunicaciones :D.

Un saludo!

Enviado por GreenEyed en mayo 25, 2009 a las 02:19 PM CDT.


-----------------------------------------------------
Créditos:
La imagen es de: germeister
------------------------------------------------------

No hay comentarios:

Publicar un comentario