MADRID Global Day of Coderetreat 2014

GDCR

Celebrating Passion and Craftsmanship


Evento de desarrollo a nivel mundial:

137 países
22 zonas horarias
2.000 desarrolladores



http://live.coderetreat.org


REGLAS



  • Varias sesiones de programación de Game of Life .
  • Cada sesión define restricciones particulares.
  • Programamos en parejas.
  • Cualquier lenguaje de programación.
  • Stop, Delete your Code and Stand up : Al final de cada sesión dejamos de programar, nos levantamos y borramos todo el código escrito .
  • Usamos Test-Driven Development en todas las sesiones.
  • El objetivo no es acabar el juego , sino aprender todo lo posible.

otras REGLAS

  • Cambia de pareja en cada sesión.
  • Puedes usar las pizarras.
  • Propón reglas para las iteraciones en el tablón de cocreación.
  • Comparte: #gdcr14 o #madrid-gdcr14
  • Boy Scout Rule: Deja todo como estaba o mejor.
  • ¿Alguna duda? pregunta a los facilitadores:

 
   Jose               Juanma            Rafa      


conway's GAME OF LIFE

Autómata celular diseñado por John H. Conway en 1970


Una célula viva muere cuando tiene:

  • Menos de 2 vecinos vivos.

  • Más de 3 vecinos vivos.


Una célula viva sigue viviendo cuando tiene:

  • 2 o 3 vecinos vivos.


Una célula muerta vive cuando tiene:

  • 3 vecinos vivos.

GAME OF LIFE


AGENDA

09:30 - 10:00    Introducción al evento

10:00 - 11:00    Iteración #1

11:00 - 12:00    Iteración #2

12:00 - 12:30    Break

12:30 - 13:30    Iteración #3

13:30 - 14:30    Iteración #4

14:30 - 15:00    Break

15:00 - 16:00    Iteración #5

16:00 - 17:00    Iteración #6

17:00 - 17:30    Retrospectiva final (Closing Circle)


SESIÓN #1


  • Sin reglas especiales.
  • Nos centramos en conocer el problema y configurar el entorno de desarrollo.
  • Implementar las reglas del juego.

STANDUP SESIÓN #1





RETRO SESIÓN #1



¿Qué hemos aprendido?

¿Qué conclusiones sacamos?

¿Qué problemas hemos encontrado?


SESIÓN #2

Volvemos a empezar, pero esta vez...


  • Máximo de 5 líneas/método.
  • Máximo de 3 métodos/clase.


STANDUP SESIÓN #2


RETRO SESIÓN #2



¿Qué hemos aprendido?

¿Qué conclusiones sacamos?

¿Qué problemas hemos encontrado?


¿Las primeras reglas han ayudado a cumplir con SRP?
¿Qué ventajas obtenemos?




descanso de 30'

SESIÓN #3

Volvemos a empezar, pero esta vez...



  • Diseña cada "módulo" para que tenga  una única responsabilidad.
  • Diseña de manera que sea posible introducir cambios en la lógica del juego extendiendo el código, pero sin necesidad de cambiarlo.
  • No IFs.

SESIÓN #3

(tras 15 minutos...)


¡Atención! cambios de requisitos:


  • Reglas configurables.

STANDUP SESIÓN #3


RETRO SESIÓN #3


¿Qué hemos aprendido?

¿Qué conclusiones sacamos? 

¿Qué problemas hemos encontrado?



¿Has podido cambiar las reglas del juego extendiendo tu código, pero sin tener que llegar a modificarlo?

SOLID: SRP, Open-Closed Principle
Alta cohesión, Bajo acoplamiento

SESIÓN #4

Volvemos a empezar, pero esta vez...



  • Mute ping-pong with find the loophole:
    • Ping-pong: una persona escribe los tests, la otra la implementación.
    • Mute: prohibido hablar.
    • Find the loophole: el implementador trata de pasar los tests, pero aplicando a propósito el algoritmo incorrecto.

STANDUP SESIÓN #4


retro sesión #4


¿Qué hemos aprendido?

¿Qué conclusiones sacamos?

¿Qué problemas hemos encontrado?



Comunicación a través del código : 
"tests como documentación"





descanso de 30'

SESIÓN #5





TDD as if you mean it
  1. write exactly ONE failing test
  2. make the test from (1) pass by first writing implementation code IN THE TEST
  3. create a new implementation method/function by:
    • doing extract method on implementation code created as per (2), or
    • moving implementation code as per (2) into an existing implementation method
  4. only ever create new methods IN THE TEST CLASS
  5. only ever create implementation classes to provide a destination for extracting a method created as per (4).
  6. populate implementation classes by doing move method from a test class into them
  7. refactor as required 
  8. go to (1) 

STANDUP SESIÓN #5


RETRO SESIÓN #5


¿Qué hemos aprendido?

¿Qué conclusiones sacamos?

¿Qué problemas hemos encontrado?


Diseño preconcebido 
vs 
Diseño emergente de los tests

sesión #6


Legacy pairing

  • Resolver el problema de manera rápida.
  • Sin escribir código limpio ni preocuparse por el buen diseño.
  • Después de 20 minutos se intercambian las parejas.
  • El nuevo integrante será el responsable de limpiar el código, mejorar el diseño, añadir pruebas, etc.

standup sesión #6



retro sesión #6


¿Qué hemos aprendido?

¿Qué conclusiones sacamos? 

¿Qué problemas hemos encontrado?



¿Ha sido posible transformar en 25 minutos el código escrito en los primeros 20 minutos en código limpio?

¿Se observa el efecto "ventana rota"?

CLOSING CIRCLE



¿Qué has aprendido?

¿Qué te ha sorprendido hoy?

¿Qué crees que adoptarás a partir de hoy?

regalos



Cupones de descuento



Made with Slides.com