Lecciones de diseño desarrollando Puppet

Dicen que es muy bueno leer código de otros. Un paso intermedio es leer cómo otros han diseñado ese código y para esto hay un libro espectacular: The Architecture Of Open Source Applications en el que desarrolladores cuentan entre otras cosas cómo han evolucionado arquitecturas y software que diariamente usamos como Git, Puppet, MediaWiki o Hadoop.

Leyendo el capítulo de Puppet se puede uno encontrar cómo este framework ha ido progresando con los principios de diseño de buen software muy en mente tales como bajo acoplamiento, alta cohesión, inyección de dependencias…

Declararon los recursos (archivos, programas…) como primitivos del framework y definieron una capa Resource Abstraction Layer desde la que usar los recursos independientemente del sistema operativo o la implementación de su uso. Se esforzaron por darle la posibilidad al usuario de Puppet de enfocarse en lo que necesita más que en cómo lograrlo.

Desarrollaron los clientes Puppet sin dejarle acceso a los módulos (encapsulamiento) entregándoles su configuración correspondiente. Así, cada cliente sólo conoce su configuración sin conocer la configuración de otros servidores evitando de esta manera que un cliente cree dependencias en servidores de los que no debería depender.

Más adelante en el texto comentan que el nodo Master Puppet recibe las necesidades de un nodo y más que configurarlo lo clasifica, cosa que me recuerda mucho a la orientación a objetos: Crear varias clases con la misma interfaz pero diferente comportamiento en la implementación, en lugar de tener sólo una clase y un montón de condiciones para definir el flujo dependiendo de la configuración.

Desarrollando un software para gestionar recursos en diferentes máquinas, se encontraron con la misma problemática de gestionar recursos en el código y poco a poco fueron desarrollando su propio framework (dentro de Puppet) de inyección de dependencias llamado Indirector que con el paso de las versiones ha llegado a gestionar todas las dependencias de la aplicación completa.

Y para terminar el texto concluye dándonos una gran lección sobre desarrollo de software:

Lastly, it took us too long to realize that our goals of simplicity were best expressed in the language of design. Once we began speaking about design rather than just simplicity, we acquired a much better framework for making decisions about adding or removing features, with a better means of communicating the reasoning behind those decisions.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s