Etiqueta: patterns

Dos estrategias para la adopción de DevOps

Partiendo de la premisa que DevOps viene a intentar mejorar el flujo de software delivery, reduciendo las fricciones entre desarrollo y operaciones, intentando incluso derribar los silos, me he encontrado con distintas estrategias de implementación. De forma muy simplificada he logrado identificar dos patrones recurrentes cuando una organización adopta una estrategia DevOps. A falta de creatividad en este artículo las denominaré «Desarrollo Empoderado» y «Operaciones Serviciales«.

Desarrollo Empoderado

Esta estrategia implica empoderar a los equipos de desarrollo para tomar responsabilidad sobre todo el proceso de delivery. Esto tiene dos implicancias fuertes. Por un lado el equipo de desarrollo incorpora más responsabilidades y habilidades, se involucra con la infraestructura, el pipeline de delivery, etc. Por el otro el equipo de operaciones «suelta» un poquito, comparte más con los equipos de desarrollo a partir de involucrarse en el día a día del proyecto, etc. Incluso en algunos casos una persona de operaciones se suma como un team member más al equipo de desarrollo.

Operaciones Serviciales

En esta estrategia operaciones sigue manteniendo cierta distancia con desarrollo pero a partir de un fuerte trabajo de automatización facilita el día a día del equipo de desarrollo proveyendo una experiencia que podríamos denominar «operaciones como servicio». En estos casos la visión de operaciones es: «que desarrollo se concentre en las user stories y hagamosle la vida lo más simple posible y que con un par de clicks puedan tener acceso los recursos que necesiten«. Esto requiere obviamente, incorporar habilidades, herramientas y sobre todo proactividad, colaboración y vocación de servicio.

En cierto modo estas dos estrategias, descriptas aquí de forma muy simplificada, pueden ubicarse en dos extremos de un continuo de estrategias que incorporan elementos de cada una.

Personalmente, trabajando en desarrollo, me siento mucho más cómodo con la estrategia Desarrollo Empoderado, pero soy consciente que puede no ser así para todos los desarrolladores y también que en algunas organizaciones puede ser más conveniente una estrategia del estilo Operaciones Serviciales.

Breve reseña de algunos libros de patrones diseño

Continuando con el tema de patrones del post anterior, se me ocurrió compartir esta breve reseña de algunos libros de patrones diseño de mi biblioteca.

Design Patterns, de Gamma y amigos

Este es EL libro de patrones de diseño que acuñó el término. Es un clásico, tiene dos capítulos introductorios y luego presenta los patrones agrupados por tipo de patrón: de creación, de comportamiento, de estructura, etc. El conjunto de patrones presentados en este libro son comúnmente denominados «los patrones de Gamma».
Una curiosidad del libro es que utiliza una notación gráfica para representar clases que es anterior (pero muy parecida) a UML. Por esas cosas de la vida que por momentos resultan inexplicables me compré la edición en castellano de este libro.

UML and Patterns, de Larman

Este es otro libro que para mi también es un clásico. Este libro tiene dos cuestiones que me gustan mucho. Por una la lado es un libro que presenta el uso de patrones de diseño en el contexto de un proceso de desarrollo en este caso el Proceso Unificado. Por otro lado, más allá de los patrones Gamma, este libro presenta un conjunto de patrones que denomina GRASP:

Este libro lo tomamos como referencia hace un par de año con @dfontde cuando armamos la primera versión de la materia Análisis y Diseño Orientado a Objetos en UNTreF.

Implementation Patterns, de Kent Beck

Tengo la sensación que este libro es muy poco conocido pero a mi me gustó mucho. Ma animaría a decir que es un libro de patrones de código, o sea son patrones «de bajo nivel». Si bien el código está en escrito en Java, muchas de las cuestiones son más de programación orientada a objetos y por lo tanto resultan aplicables incluso cuando uno no trabaje con Java. En InfoQ hay una interesante entrevista a Kent Beck sobre este libro.

C++ Coding Standards, de Sutter & Alexandrescu

El subtitulo del libro es «101 Rules, Guidelines and Best Practices» y si bien ni título ni subtítulo hacen referencia a patrones el libro perfectamente puede clasificarse como un libro de patrones. Las recomendaciones/patrones son específicas de C++ y en general no son extrapolables a otros lenguajes. Cuando los patrones son específicos de un lenguaje, como en este caso, se los suele llamar idioms. Este libro me llegó por mera casualidad hace unos 15 años en la época en que cursaba Taller de Programación 1 en Fiuba donde aprendí C++ en profundidad.

Applying Domain-Driven Design and Patterns, de Jimmy Nilsson

Este libro fue publicado en 2006, y si bien el subtítulo «With Examples in C# and .NET«, varias de las cuestiones expuestas son extrapolables a otras tecnologías. De hecho el libro es una bajada a C#/.NET de las ideas de dos libros: Patterns of Enterprise Applicacion Architecture (fowler) y Domain Driven Design (Evans). A pesar de ser un libro de que tiene ~15 años, creo que sigue vigente.

En un próximo post, escribiré sobre algunos otros libros que no son específicamente de patrones sino de temas muy relacionados.

Desorientados con los patrones de diseño

Los patrones de diseño son una herramienta muy popular en la actualidad, imagino que la gran mayoría de los programadores profesionales utilizan en sus soluciones algún patrón de diseño. Incluso en algunos casos, es posible que estén usando algún patrón sin ser conscientes de ello.

Sin embargo, he notado que en muchos casos se utilizan patrones sin tener en claro el problema que el patrón resuelve. En reiteradas ocasiones me he encontrado preguntado a un programador “¿Qué problema estás resolviendo con este patrón?” y he obtenido respuestas conceptualmente incorrectas. Me me encontrado con gente que cree que aplicar Model-View-Controller le dará escalabilidad a su solución. También me he encontrado con gente que organiza su solución con Layers y no sabe a ciencia cierta porque.

La razón para aplicar un patrón debería ser que el patrón en cuestión resuelve de forma satisfactoria un problema o situación concreta que uno está enfrentando. Esto implica que uno debería en primera instancia entender el problema que tiene entre manos y luego buscar un patrón que resuelva ese problema. Si no tenemos en claro el problema podríamos terminar aplicando un patrón menos apropiado.

Haciendo una analogía con la cocina: uno tiene que preparar una cena con determinas características, entonces busca en un libro de recetas alguna que se ajuste a la necesidades de la cena en cuestión. Obviamente que ese proceso de buscar el patrón apropiado puede no ser instantáneo. Uno podría estar horas buscando un patrón hasta encontrar uno apropiado o incluso podría no encontrarlo. Es ahí donde puede resultar muy valiosa la experiencia personal de cada uno y el hecho de haber leído algunos libros de patrones.

En línea con esto último, tengo que ganas de hacer un reunión (meetup) para compartir patrones diseño. Se me ocurre una consigna del tipo:

Cuentame tu problema
(y el patrón con que el que lo resolviste)

Todos los que quieran presentar se anotan con anterioridad a la reunión y al hacerlo indican que patrón presentarán. Luego durante la reunión:

  • Cada presentador tiene 15 minutos (este tiempo se puede ajustar dependiendo de la cantidad de gente presentar).
  • La presentación debe ser de un caso real de aplicación del patrón, o sea: no vale simplemente contar un patrón conceptualmente. Tiene que haber sido un caso de aplicación en un contexto de proyecto real.
  • La presentación del patrón debe empezar contando el contexto y el problema particular a resolver.
  • Debe incluir también las diferentes opciones consideradas para la solución (si es que la hubo)
  • A continuación se presenta el patrón
  • Finalmente se mencionan los efectos colaterales de la aplicación del patrón

Make sense?