Diseño Evolutivo

Este documento resume los lineamientos principales bajo los cuales fueron construidos estas dos ideas.

Obviamente un ORM no es una idea novedosa, en nuestro caso no aporta algún aspecto nuevo en sí, ni tampoco es nuestra intención inventar lo ya inventado. Pero si lo es entender el proceso de construcción de software, o al menos construir nuestra opinión al respecto. Ya que de la calidad de ese criterio depende buena parte del éxito de los proyectos en los que participamos.

Por qué otro ORM en nuestro caso es el producto de 4 años de trabajo en diferentes proyectos de software en diferentes compañías con diferentes equipos, lo que determino la necesidad de construcción de un ORM lo más sencillo posible a fin de rápidamente incorporar gente a la causa.

Todo esto fue posible en gran medida por tener siempre una guía o referencia bien clara. En el caso de Essential y Summit (y en general también) esta guía es este breve extracto del libro Refactoring To Patterns de Joshua Kerievsky.

Evolving a New Architecture

There was once a company that had an older system, with the all-too-common problems of poor design, instability, and difficult maintenance. The company decided to refactor the system's architecture rather than rewrite everything from scratch.

Common code would be accessible from a new framework layer. Applications would use the framework layer for common services.

This separation would allow framework programmers to gradually improve underlying framework code, with minimal impact on applications.

The company decided to form a framework team. Application teams would rely on the framework team for common services.

While this plan sounds reasonable, it's actually quite risky. If the framework team members lose touch with application needs, they can easily build the wrong code. If the application team members don't get what they need, they may bypass the framework to meet deadlines or slow down just to wait for what they need. Bypassing the framework is a return to the legacy architecture, while waiting for code is also a poor option.

Evolutionary design provides a better way. It suggests that you:

                                                               Form one team

                                                               Drive the framework from application needs

                                                               Continuously improve applications and the framework by refactoring


With one team, the framework and the applications can't fall out of alignment. With the framework driven by real application needs, only valuable framework code gets produced. Continuous refactoring is essential to this process, for it's what keeps framework and application parts separate.

The company in this story decided to follow this evolutionary path, hiring coaches to train and guide them. Despite initial concerns about not having one team focus exclusively on framework development, the process resulted in continuous improvement in architecture, continuous delivery of high-quality applications, and evolution of a lean, general-purpose framework.

Refactoring is the essential ingredient here. It's what allows the team to effectively and efficiently evolve a new architecture.

Quizás parezca trivial lo que dice esta referencia, pero la realidad es que en los últimos años nos cansamos de ver casos que no cumplen lo trivial.

Nuestro intento va en este sentido.

Otros aspectos a destacar

Racionalidad, Simplicidad

Nosotros en Circo Studio no pensamos que programar sea un arte. Esto no le quita ninguna característica de creatividad o libertad a nuestro trabajo. Simplemente entendemos que el diseño requiere de racionalizar los problemas; Cuantificar. Simplificar. Modelar.

Esta claro que muchos de nosotros realizamos este trabajo con pasión y ganas de hacer las cosas mejor para superaros. Hacer el mejor diseño, el mejor componente, etc. Nosotros trabajamos igual y entendemos que parte de ese trabajo es definir claramente nuestras ideas de modo de poder confrontarla con otras personas de un modo racional. (No hablando de gustos.) Esto nos acerca a pensar la mejor solución o mejor herramienta para cada caso. Dependiendo del entorno.

Si nuestro framework nos permite claramente definir componentes, nos permitirá entonces definir más claramente un modelo y nos ayudara a armar nuestro proyecto con mayor previsibilidad.

Cuanto más sencillos sean estos conceptos, más fácil será armar un equipo de trabajo.

Estas ideas están presenten en Essentials y Summit desde su concepción.

Mediciones

Si logramos obtener procesos simples, seguramente podremos medirlos. Este es un deseo de todos, pero logrado por muy pocos. Nosotros decimos que cuanto más simple sean nuestros procesos más fácil será esta tarea. Nuestras herramientas permiten realizar mediciones.

Last edited Dec 10, 2010 at 6:18 PM by danielcundari, version 2

Comments

No comments yet.