simplicidad en la arquitectura

[leo]

Hola,
he visto esta charla en InfoQ que me ha parecido interesante:
http://www.infoq.com/presentations/Simplicity-Architect

Y las slides: http://qconlondon.com/dl/qcon-london-2010/slides/DanNorth_SimplicityTheWayOfTheUnusualArchitect.pdf

Si alguien ve (o ha visto) la charla, podemos luego comentarla :-)

Algunas cosas que me han llamado la atención:

- Optimizar para facilidad de cambio, no para flexibilidad. Aunque
parezca lo mismo es justo lo contrario, para facilidad de cambio hay
que intentar dejar abiertas cuantas más opciones mejor y para ello hay
que tomar las menores decisiones posibles hasta el último momento
responsable. Para flexibilidad en cambio tienes que intentar tomar
muchas decisiones para intentar tener en cuenta todos los posibles
usos.

- Como seres humanos estamos programados para complicar las cosas.

- La introducción es bastante divertidad, y luego la presentación
tiene algunas frases como:
“Some people, when confronted with a problem, think “I know, I'll use
regular expressions.” Now they have two problems.”
“Transfer Object” is an oxymoron (refiriéndose a que dos sistemas
diferentes se quieren pasar datos no objetos, ya que cada uno luego
puede tener representaciones totalmente diferentes de los mismos
conceptos)

Saludos,
Leo

[Gonzalo Garcia]

La presentación es interesante pero personalmente no creo que dé para
una hora de charla.

Por cierto:

> “Some people, when confronted with a problem, think “I know, I'll use
> regular expressions.” Now they have two problems.”

Es una cita de Jamie Zawinski, hablando de Emacs y Perl, hace muchos años.

[Agustín Ramos]

Recientemente di una plática sobre qué características pueden hacer crecer a un sistema de software,

y que este se desarrollo de tal manera que se integra adecuadamente con su contexto.

http://www.slideshare.net/zentimental.software/arquitecturas-que-crecen-y-arquitecturas-que-no-shlcon-2010

La presentación es más visual que textual, por lo que se pierde el contenido.

Pero las ideas básicas son estas:

1. Se puede hacer una analogía entre el desarrollo de los sistemas de software y los organismos vivos.

Al hacer la analogía identificamos que:

- Los sistemas de software con el paso del tiempo, adquieren estructuras o formas características.

- Una vez alcanzada esta forma característica, difícilmente cambian a algo radicalmente distinto.

- Por su lado, una buena cantidad de especies vivas se parecen mucho en las primeras etapas de su

  desarrollo embrionario. En su proceso de gestación se dan eventos que poco a poco van transformando

  su estructura convirtiéndola cada vez en una estructura más especializada. Una vez ya especializado,

  difícilmente podemos identificar una transformación que transforme a una especie otra.

  Si esto lo traducimos a software, quiere decir que un diseño muy elaborado se ha especializado de tal

  manera que el espacio de soluciones (estructuras) que puede alcanzar está más limitado que un diseño

  muy simple. En un diseño simple, es más sencillo aplicar transformaciones para convertirlo a la que las

  nuevas necesidades vayan requiriendo.

- El desarrollo de un organismo vivo depende de manera crítica en el contexto. En el software también.

  Pero ¿cuál es el contexto en el cual debe 'gestarse' un sistema de software? Bueno, no es precisamente

  el entorno de herramientas que usamos en el desarrollo, y aunque los equipos de desarrollo juegan un

  papel fundamental, pienso que el contexto adecuado es en producción. Es ahí a donde realmente

  pertenece el software, al entorno tecno-socio-económico en el cual se debe insertar, en el cual recibirá

  estímulos y presiones y en el cual debe integrarse para solucionar problemas reales. Si no ponemos

  nuestro software en producción desde sus etapas más tempranas, estamos privándolo de la oportunidad

  de adaptarse al entorno donde realmente vivirá, lo estamos privando de la oportunidad de adquirir

  la estructura 'característica' que le permitirá el éxito y lo convertirá en parte de su entorno, en lugar de

  ser solo un 'artefacto', quizá hasta un elemento que se interpone en la vida de las personas, en vez de

  ayudarlas.

2. Un diseño efectivo puede comenzar pequeño, pero definiendo adecuadamente los mecanismos de crecimiento

  En 1998 Guy Steele dio una plática titulada "Growing a Language" en donde abogaba por la

  creación de lenguajes de programación pequeños pero extensibles, a diferencia de querer crear 

  lenguajes muy completos y elaborados. Para esto, trataba de redefinir el objetivo de creación de 

  un lenguaje: diseñar buenos patrones de crecimiento (extensión) para los lenguajes, de tal manera 

  que los usuarios finales de estos lenguajes fueran quienes los extendieran de acuerdo a sus

  necesidades. Creo que esta es una de las ideas seminales de programación orientada a lenguajes,

  marco dentro del que se inserta la reciente explosión de interés en DSL's.

  Pero el punto es que pienso que estas mismas ideas son aplicables al desarrollo de sistemas de 

  software: en vez de crear un gran diseño desde un inicio, podemos comenzar con algo pequeño,

  pero definir cuales son los patrones o reglas de crecimiento de nuestro sistema. De otra manera

  (y dependiendo de muchos factores, como la cantidad de gente que desarrollará este sistema), se

  puede salir de control o perder estructura. 

3. Hay que regresar y tratar de entender a Christopher Alexander.

  La anécdota va así: Cuando Alexander vio los edificios que la gente estaba construyendo a partir de la interpretación

  que dieron a su obra anterior, se horrorizó y regresó a re-escribirla en 4 tomos: The Nature of Order.

  Creo que en muchos casos en software nos sucedió lo mismo. En la re-elaboración de su obra

  Alexander describe 15 propiedades que según él, todas las estructuras "vivas" 

  (con un sentido especial de la palabra) presentan. 

  He pasado meses pensando en cómo traducir estas propiedades a características del software

  (Sinceramente no le he dedicado el tiempo necesario), y aún no las tengo mapeadas todas y no

  he escrito nada al respecto. Pero creo que SI es importante entenderlas, identificarlas dentro del

  mundo del software y posiblemente hasta buscarlas en nuestros diseños.

  Este último punto puede ser muy controversial o al menos opinable. No voy a defenderlo,

  simplemente me gustaría saber si alguien más por aquí está explorando estos temas.

Espero esto contribuya un poco a la idea de mantener diseños sencillos.

Saludos

Agustín

Agustín Ramos

Software Craftsman