Nos vemos en el Agile Open Spain 2012 en Zaragoza

Este fin de semana, nos espera el emocionante Agile Open Spain 2012 ... Con muchas ganas de reencontrarme con gente y de compartir los valores ágiles...

Para los que no conozcan el  Agile Open Spain 2012 os comento que es una reunión/encuentro de gente que comparte los valores ágiles en formato Open Space. El formato de Open Space es uno de los formatos de conferencia más impresionantes que he visto, resulta completamente impresionante ver cómo tanta gente se autoorganiza sin ningún tipo de plan previo y con unas sencillas reglas.

Este año además, voy ha realizar el experimento social de ir junto con mi pareja y nuestra pequeña, que ni que decir tienen que no han tenido contacto previo con la agilidad (excepto que me ven jugar con tablones y pizarras por todos lados...)

Estoy convencido que el formato Open Space, les va a impresionar tanto como me han impresionado a mi todos los Open Spaces en los que he participado (por que en un Open Space no se asiste, se participa...)...

Tal como se decía en el Open Space de desarrollo Dev Open Madrid 2012, las reglas son sencillas...

• Involúcrate y pásatelo bien
• Los que vienen, son los que tienen que venir.
• Lo que ocurre, es lo que tiene que ocurrir.
• Empieza cuando tiene que empezar.
• Termina cuando tiene que terminar.

Si no estás aprendiendo o contribuyendo, es tu responsabilidad usar tus dos pies para encontrar otro lugar donde aprendas o contribuyas.

Nos vemos en el Agile Open Spain 2012, este fin de semana en Zaragoza!!!



Actualización:
En http://www.proyectosagiles.org/que-es-open-space/ disponeis de una descripción muy acertada de cómo es un Open Space.

Resumen Clean Coders capitulo 3: Funciones

Siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders.
En este caso, nos toca el Capitulo 3

Funciones

• Las funciones deben ser muy cortas (hasta 4) y hacer una sola cosa.
• Separar por agrupaciones de operaciones.
• Separar cosas de distinto nivel de abstracción.
• En las funciones largas es dónde se esconden las clases.
• Una función sólo hace una cosa cuando ya no podemos extrar más funciones ni clases de su implementación.
• Los bloques dentro de una estructura de control, son una oportunidad para encontrar nuevas funciones.

En este caso, en mi opinión,  sin llegar a ser tan extremista como Uncle Bob en cuanto al número de lineas, el código es más mantenible y legible con funciones cortas (de hasta 10 lineas).

Depende de a lo que estemos acostumbrados, nos puede parecer que el tener un gran número de funciones pequeñas y de clases pequeñas, hace que el código sea menos legible, pero creo que es más una tendencia proveniente de una forma de trabajo y que realmente una vez de que tienes interiorizado el realizar un buen nombrado de las funciones / clases y que organizas correctamente tus estructuras, es mucho más sencillo de mantener, con clases y funciones muy pequeñas y que tengan una única responsabilidad.


El resumen de este episodio ha quedado un poco pequeño puesto que gran parte se centra en ejemplos básicos y refactorizaciones... Por otro lado, me parece tan evidente lo que comenta, que poco puede aportar el resumen que yo haga....

Continuamos en el siguiente capitulo.

Resumen Clean Coders capitulo 2: Nombrado

Tal y como comente en el acciones de mejora / compartiendo videos cleancoders continuamos con los resumenes de capitulos del Clean Coders.
Esta vez nos toca el Capitulo 2

Capitulo 2 Nombrado

En este capitulo, uncle Bob se centra en enseñarnos cómo debemos usar los nombres (clases, métodos, variables, etc...) que seleccionamos al desarrollar, como una herramienta de comunicación...

1. Los Nombres son una herramienta poderosa de comunicación... Hay que elegirlos y tratarlos con cuidado
2. Elige nombres para comunicar tus intenciones. Si tienes que poner un comentario para explicar el nombre, es que no está bien elegido. Si tienes que leer el código para entenderlo, también está mal escogido.
3. Siempre evitar la desinformación (generada por mal naming o por cambios que hacen que se queden los nombres obsoletos). (Said what it means, means what it says)
4. Los Nombres deben ser pronunciables.
5. No usar encoding (no notaciones hungaras, no I para interfaces, …)
6. Clean Code como prosa. Para Clases nombres, Para Variables nombres, Boolean predicados, métodos verbos, si devuelven boolean predicados.
7. Scope rules...
1. Variables con nombres cortos o incluso muy cortos si tienen scope pequeño.
2. Variables con nombres más largos si tienen scope más largos.
3. Funciones, métodos, clases
1. Nombres cortos y convenientes si el scope es grande y su uso muy común.
2. Nombres más largos y descriptivos si el scope es más corto (métodos y clases privadas, por ejemplo).

Lo más importante:
Any fool can write code that a computer can understand.  Good programmers write code that humans can understand. Martin Fowler

--
Actualización:
31/5/2012 Resueltos algunos problemas de formateo...

Resumen Clean Coders capitulo 1

Tal y como comente en el acciones de mejora / compartiendo videos cleancoders aquí va el primer resumen de los capítulos de Clean Coders. Concretamente del Capitulo 1

Capitulo 1 Clean Code

1. ¿Qué es Clean Code?
1. Código escrito por alguien que parece importarle y con atención a los detalles.
2. Código que se lee como si fuese buena prosa.
3. Código en que cuando lees un método/función es más o menos lo que esperabas (por el nombre).
2. ¿Importa?
1. Tanto, como que es la única forma de ir deprisa en el desarrollo de Software.
2. Tanto que el no tenerlo en muchos casos es el principal problema de los departamentos de desarrollo de software.
3. ¿Quién es el culpable de crear código sucio (no clean code)?
1. Somos los desarrolladores, nadie más.
2. Todo lo demás son disculpas.
4. ¿Por qué creamos código sucio los desarrolladores?
1. Por desconocimiento / falta de profesionalidad.
2. Porque nos autoengañamos:
1. Pensando que obtenemos ventajas a corto plazo
2. Pensando que lo limpiaremos en el futuro
5. ¿Cómo nos limita el trabajar/crear código sucio.
1. El código es dificil de entender, y por tanto dificil de modificar y de mantener. Por lo que el coste de mantenimiento (e incluso el de desarrollo) es muy alto.
2. Se crean sistemas rígidos, en que cada cambien requiere de muchos otros cambios en otros módulos. Haciendo que el coste de mantenimiento sea alto e impredecible.
3. Se crean sistemas frágiles en el que cambios afectan a partes de la aplicación que en principio no deberían verse afectados. Esto provoca sensación de fragilidad y de baja calidad. Hace que los managers y los clientes no confíen en el producto. El coste de meter cualquier modificación es bastante impredecible.
4. Se crean sistemas inseparables en los que nunca sabes si vas a poder reusar un modulo. Normalmente, no puedes reusar los módulos fuera del contexto en el que fueron creados. Esto conlleva duplicadidad de código y un coste alto de mantemiento. Además los costes son impredecibles, puesto que nunca sabes lo que puedes reusar.

The only valid measurement of code quality: WTFs/Minute

Hasta el siguiente capitulo....

Acciones de mejora... Compartiendo videos cleancoders

Actualmente en Alea Soluciones, nos encontramos en pleno proceso de construcción de un equipo de desarrollo basado en los principios ágiles y en prácticas de Extreme Programming

Dentro de este proceso en una de las retrospectivas internas acordamos realizar una especie de grupo de estudio sobre los videos creados por @unclebobmartin (uncle Bob) en http://www.cleancoders.com/


Cada semana, cada miembro se ve/escucha un capitulo previamente acordado, tantas veces crea necesario, y posteriormente, a final de la semana, ponemos en común nuestras impresiones, dudas, mejoras internas que podemos realizar siguiendo los consejos de los videos....

De momento llevamos seis capitulos y tengo que decir que, si bien ver los videos es bastante enriquecedor, verlos a la vez que el resto de los miembros, y comentar posteriormente las impresiones, es mucho más enriquecedor y aporta un aprendizaje mucho más sólido.

Así que espero que durante el Largo proceso, podamos seguir realizando este tipo de acciones, tanto con estos videos como con otros materiales de formación sobre desarrollo de software...

Siguiendo los patrones del Apprenticeship Patterns,  record_what_you_learn y share_what_you_learn, tengo la intención de compartir por aquí las conclusiones que saquemos de cada uno de los capitulos.

Curso Agile Inception ofrecido por path11

El pasado jueves y viernes asisti al curso sobre cómo realizar una Agile Inception ofrecido por path11. El curso me resulto de lo más inspirador y se notaba que las profesoras, @rlaina
y @amaliahern, no sólo sabían muy bien de lo que hablaban y habían meditado y preparado muy bien cómo transmitirlo, también se notaba que tenían mucha experiencia real con esta herramienta ágil y daban todo tipo de ejemplos, situaciones reales, posibles escenarios y esos trucos que sólo la experiencia da.

De momento path11 es una de las pocas empresas que usan las Agile Inception de forma sistemática en el arranque de un proyecto, por lo que es un verdadero lujo que comparta su experiencia con el resto de agilistas.

Resumiendo, un curso altamente recomendable para cualquier equipo ágil que quiera alinearse rápidamente con el cliente y comenzar a trabajar juntos compartiendo una visión y un objetivo común.