Archive | noviembre 2012

Agile principles, patterns and practices in C#

Agile principles, patterns and practices in C#

Robert C. Martin

Por qué lo he leído

Lo he leido porque me he encontrado referencias a este libro en libros anteriores que he leído, en blogs sobre desarrollo de software que suelo leer y en otros muchos sitios relacionados con el software. Si encuentro tantas referencias, será por algo, ¿no? Además, el autor es muy conocido y valorado, así que no había excusa para no leerlo.

Qué esperaba

Me esperaba un libro de Uncle Bob™. Ya he leído alguno del mismo autor, y me gusta su estilo. Algunas veces me parece un poco extremista, pero creo que es así porque cree en lo que hace y eso es lo que predica. Cuando creo que exagera, no le hago mucho caso y sigo hacia adelante, ya está.

Esperaba una descripción de las metodologías ágiles aplicadas al momento de escribir software y encontré …

Qué encontré

… un pedazo de ladrillo! Me asusté cuando vi la extensión del libro, pero enseguida entendí el porqué. El libro está lleno de diagramas UML y de código fuente (primero los tests, por supuesto). Así que es normal que sea tan largo.

En cuanto al contenido, me gustó mucho la descripción que hace de muchos patrones de diseño, (incluso he aprendido alguno que no conocía). En el libro también podrás encontrar una descripción detallada de los principios SOLID y de otros principios sobre cómo organizar y empaquetar los distintos componentes de tu aplicación (clases, paquetes, namespaces, lo que sea).

Conclusiones

Aunque el libro sea muy extenso, me ha gustado por varias razones:

  • He aprendido nuevos patrones de diseño.
  • He podido profundizar sobre el patrón Model-View-Controller (ver enlaces más abajo).
  • He encontrado una descripción muy detallada de los principios SOLID.

Pasajes que quiero recordar de este libro

Un módulo que es difícil de cambiar, está roto y necesita ser arreglado, aunque funcione.

Un módulo que no comunica está roto y necesita ser arreglado.

Cuanto más conocen los programadores sobre todo el proyecto, más sano y más informado está el equipo que lo desarrolla.

Es el big picture lo que mantiene unido el sistema. Es la visión del sistema lo que hace obvia la localización y la forma de los módulos individuales. Si la forma de un módulo es inconsistente con la metáfora, es el módulo quien está mal, no la metáfora.

Al final, el código fuente es el diseño.

Se sabe que el software se está pudriendo cuando empieza a mostrar alguno de los siguientes síntomas: rigidez, fragilidad, inmovilidad, viscosidad, complejidad innecesaria, repetición innecesaria u opacidad.

El elemento más volatil en los proyectos software son los requisitos. Vivimos en un mundo de requisitos cambiantes, y nuestro trabajo es estar seguros de que nuestros software puede sobrevivir a esos cambios, así que no culpes a los requisitos cambiantes por los fallos en el software.

Los principios SOLID: Single responsability principle, Open close principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle.

Un motivo de cambio es un motivo de cambio sólo cuando el cambio ocurre, mientras tanto no.

Strategy and Template method son las formas más comunes de satisfacer Open closed principle. Estos patrones representan una clara separación de la funcionalidad genérica de la implementación detallada de esa funcionalidad.

Fool me once, shame on you. Fool me twice, shame on me. Inicialmente, escribimos nuestro código pensando que no va a cambiar. Cuando ocurre un cambio, implementamos abstraciones que nos protegen de futuros cambios de esa misma naturaleza.

Liskov substitution principle nos lleva a una importante conclusión: un modelo, visto aisladamente, no puede ser validado significativamente. La validez de un modelo puede ser expresado solo en términos de sus clientes.

Liskov substitution principle clarifica que en la programación orientada a objetos, una relación de herencia pertenece al comportamiento que puede ser asumido y que los clientes dependen de este comportamiento, lo contrario de lo que normalmente se cree, que la herencia pertenece al estado

El diseño de grandes sistemas depende críticamente de un buen diseño de componentes (paquetes, entregables, …), de esta forma, los equipos individuales puede enfocarse en componentes aislados en lugar de preocuparse por el sistema completo.

Las interfaces pertenecen al cliente que las usa, no a la implementación. El enlace lógico entre el cliente y el interfaz es más fuerte que la relación entre el interfaz y sus implementaciones. Es tan fuerte que no tiene sentido desplegar el cliente sin el interfaz, pero sí que lo tiene desplegar el interfaz sin sus implementaciones.

Otras lecturas y enlaces relacionadas

[microtip] git: ramas locales y remotas

git es un sistema de control de version distribuido (DVCS por sus siglas en inglés), y una de sus características que lo hacen más atractivo es su gran rapidez para trabajar con ramas (branches).

En este pequeño post, que he llamado microtip, veremos cómo crear una rama, movernos entre ramas, realizar sencillos merge entre ramas y cómo hacer que estos cambios se vean reflejados en un repositorio remoto para poder compartirlo con nuestros compañeros de proyecto.

Para comenzar a trabajar en una rama nueva, podemos hacerlo de dos formas:

  1. Crear la rama y movernos a ella
  2. git branch nueva_rama
    git checkout nueva_rama
    
  3. Movernos a una rama y crearla en caso de que no exista
  4. git checkout -b nueva_rama
    

Ok, ya estamos trabajando en la nueva rama. Ahora podemos añadir ficheros, hacer commit de cambios que hayamos hecho, …

git add nuevo_fichero.txt
git commit -m "mensaje para el commit"

Una vez tenemos los cambios deseados en nuestra rama, podemos dejarlo así, de forma que será una rama privada, solamente nosotros tendremos acceso a ella, o podremos hacerla pública a través de algún repositorio remoto para que sea accesible por nuestros compañeros:

git push origin new_branch

Nota: este comando supone que origin es un remote válido para git.

Si queremos pasar estos cambios otra rama, por ejemplo, master: primero nos moveremos a esa rama y luego traemos los cambios a esta rama:

git checkout master
git merge development master

Mi experiencia en la CAS2012

Puede ver una versión activa de este post en mi nuevo blog. He decidido dejar de publicar en este blog por éstas razones. Su filosofía es la misma que éste, pero espero no tener los problemas que me he encontrado aquí.

Más vale tarde que nunca. Tenía ganas de escribir mi experiencia en la CAS2012 (mi primera CAS) pero todavía no había encontrado el hueco. Supongo que quería leer alguna experiencia de otros asistentes, o será mi alter ego perezoso, quién sabe.

La verdad es que volví de Cáceres encantadísimo, motivadísimo, y cualquier otro adjetivo que termine en -ísimo. ¡Qué pasada! Como ya he dicho antes, ésta ha sido mi primera CAS, y espero que se repita cada año. Sé que será difícil, pero lo intentaré.

Aunque fuera mi primera CAS, no me sentí para nada un extraño. Todo lo contrario, el ambiente que respiré fue de un profundo compañerismo. Era como si todos supiéramos que estábamos allí por algo, y creo que así era. Yo, al menos, acudí a la CAS porque sentía (y siento) una cierta atracción por el mundo agile, y en Cáceres noté esto mismo en todos y cada uno de los asistentes. Jose Manuel Beas dijo que la palabra que más estaba escuchando era confianza. Yo creo que la que más escuché fue tribu. Y así me sentí yo, como perteneciente a una tribu.

Después de estos sentimentalismos me gustaría agradecer a la organización de la CAS su duro trabajo, la acertada elección del lugar de celebración del evento, la visita guiada por la ciudad, la organización de la cena, … tantas cosas. Los agradecimientos también a los patrocinadores, sin los cuales el evento no habría sido posible. Muchas gracias a todos por darnos este eventazo.

No se puede hablar de este tipo de eventos sin mencionar a la gente. Fuí a la CAS sin conocer a nadie, sólo, a la aventura, pero con ganas de conocer a profesionales que admiro por su trabajo. Y así pude conocer a gente como @kinisoftware, @ialcazar, @xquesada, @oyabun y @alejandropgarci. Y también tuve el placer de conocer a gente que antes no conocía como @anuskiaranda, @rferlei, @maicatrinidad@FPerezP, @drobur, @masaKmaeda, Joao Gama, @eidrien. ¡Me alegro de haberos conocido!

Y por último, unas cuantas frases escuchadas en las charlas a las que asistí que me gustaría destacar, no están todas las mejores, pero son las que más me impactaron y me gustaría recordar:

Abre tu mente, abraza el cambio, haz un esfuerzo consciente de no rechazar cambios de forma instintiva. ~ Masa K Maeda

La tiranía de la curva J, al inicio de la introducción de un cambio, todo irá a peor. ~ Rodrigo Corral

Los desarrolladores son los únicos agentes de oxidación del software, ya que son los únicos que lo modifican. ~ Alejandro Pérez

Deja que las personas sean creativas, da libertad al equipo para ser creativo. ~ Luis Fraile

Mejor cuanto más caliente es la comunicación: cara a cara -> videoconferencia -> teléfono -> chat -> mail -> nada ~ Israel Alcázar

Los beneficios en la empresa son una consecuencia de los trabajadores, porqué no aportarles: transparencia, compromiso, confianza, autonomía, respeto. ~ Jose Ramón Díaz

Si quieres conocer más, en el siguiente documento se están recopilando enlaces y recursos sobre la CAS2012.

Enlaces de los martes (06-11-2012)

Hace muchos martes que no publicaba una serie de enlaces, así que creo que esta vez la lista ha quedado un poco larga, pero espero que encontréis los enlaces muy interesantes:

  • Branching and merging with git and github, encontrado en Learn Github: Buscando alguna manera de trabajar con ramas en git y github, he encontrado este enlace. Creo que explica de forma muy clara y concisa una forma básica de crear ramas, trabajar en ellas, y pasar los cambios de una rama a otra. Ahora por lo menos, lo tengo mucho más claro.
  • The App Developers Alliance, de Joel Spolsky: Este post me ha gustado especialmente, no por el título, si no por las perlas que Joel dice en el artículo:

Cuando un programador escribe software, escribe un guión para el futuro.

El software es omnipresente.

El software se está comiendo el mundo, así que los programadores son los diseñadores del futuro