Coding Dojo
Objetivo
Generar un espacio para adquirir nuevos skills donde los desarrolladores puedan resolver
desafios de programacion mientras se divierten mejorando la comunicación.
Varias Maneras:
Randori: Todo el mundo trabaja juntos con el mismo problema y en la misma maquina
Coding Kata
Ejercicios propuestos:
[Link]
Total del tiempo: 2:30hs
Agenda:
15min presentacion
¿Que es coding dojo?
Cuando se aprende karate en un dojo, la manera de aprender es colaborativo,
interactivo y hasta divertido.
Es donde podemos mejorar los skill técnicos de manera colaborativa. Pensar como
escribir codigo limpio siguiendo principios de diseño, escribiendo test, y haciendo refactoring.
Coding Kata: El kata es una secuencia de movimientos que uno aprende, utilizando la
memoria muscular.
Principios de coding dojo:
- No se pueden discutir tecnicas sin codigo
- No se puede mostrar codigo sin test
- Importante: Código que no tiene tiene test simplemente es codigo que no existe.
- No hay un solo maestro: No existe un maestro en todas las ares, cada uno puede
aprender y enseñar
1hs primer parte
1hs segunda parte
20min retro y review
Preguntas:
¿Estamos conformes con el codigo y el test que escribimos? ¿Como logramos
que el diseño sea limpio?
¿Se puede trabajar asi de forma productiva? ¿Se trabajo de manera
incremental?
Coding Dojo:
[Link]
Fuentes:
[Link]
[Link]
SOLID KATA:
[Link]
TDD KATA
Bootstrap project
[Link]
Crear proyecto base:
gradle init --type java-library
Retro Coding Dojo 10/1/2020:
● Breve de repaso de principios y TDD.
● Aplicar randori en las proxima.
Resumen de Coding Dojo:
Cada cuanto hacemos Coding Dojo? Un vez por spring o una vez por mes.
Que venimos a hacer? Utilizar buenas practicas tal como lo hacemos con código
productivo.
Elementos Esenciales:
● Introduccion y restrospectiva
● Escribir test
● Mostrar el trabajo realizado
● Tener un monerador
Como aprendemos y que aprenderemos en un coding dojo?
Mediante la practica, la colaboración aprenderemos:
● Aprender a usar shortcut del IDE
● Pair Programming
● TDD
● Refactoring
● Diseñar buenos TEST
● Trabajar de manera incremental y comiteando regularmente.
● Diseñando usando principios SOLID
● Paradigma orientado a Objectos
● Paradigma de programación funcional.
Test firt development -> Course in Pluralsigh.
Buenos habitos:
“I'm not a great programmer; I'm just a good programmer with great habits.” - Kent Beck
El habito es lo que hacemos cuando no estamos pensando.
Que practicamos en Coding Dojo? Code Kata: Ejercicios cortos que se pueden repetir.
Principios del Dojo:
Primera regla
● No se puede discutir tecnicas sin código
● No se puede mostrar codigo sin test
● Porque codigo que no tiene test es código que no existe.
Segunda regla
● No es necesario tener un mestro o sensei.
● Nadie es un mestro en todas las areas, cada uno puede enseñar y aprender.
Enseñar y aprender TDD
Juego colaborativo
● No es una competencia.
● Preparacion de Kata
○ Explicacion de ...
○ Practicas muchas veces
○ Elegir un Kata Corto.
○ Encontrar una pareja
○ Explicar cada decision de codigo.
● Randori
○ Timpo limite. 5 min por persona.
○ Ping pong. Uno escribe el test y el otro hace que el test pase y escribe otro test
que pase.
○ Ping pong Randori
● Reglas del randori
○ El tiene el teclado, decide que escribir.
○ Si el que tiene el teclado no sabe que escribir, puede pedir ayuda.
○ Si se pide ayuda, se debe responder amablemente.
○ Si no te hicieron ninguna pregunta, pero ves una oportunidad de mejora, se debe
elegir el momento adecuado para hablar. Por ejemplo en la etapa de refactoring
despues de escribir todos los test. O tambien en la retrospectiva.
● Randori in Pairs (Para grupos grandes)
○ Dividir el grupo en pares o trios
○ Cada par de trabajo trabaja en el mismo Kata
○ En la retrospectiva se comparte el código y se discute como se escribio.
○ Cambiar los pares y empezar el ejercicio de nuevo desde el principio.
○ Cada trabajo de pares, puede durar 45 min.
● Juego con Restricciones
○ Restricciones de Herramientas
■ Solo teclado y sin mouse
■ Usar un editor de texto plano
○ Retricciones de diseño
■ Metodos cortos, maximo 2 lineas en el body
■ No usar IFs
■ No usar loop, y usar stream
○ Restriciones de socializacion
■ Revisar de nuevo
■ Randori Kata de a pares
Ejemplo de series de Coding Dojo.
Coding Dojo: Principios SOLID - Inversion de dependencia
Introducción:
Proposito del Dojo
Habilidades con TDD
Acuerdo de Actividad
Las abstracciones no deben depender de detalles o depenencias concretas.. Los
detalles deben depender de las abstracciones.
Boton -> Lamp
Boton -> Switcheable [interfase] <- Lamp
Code!
Randori in Pair Katas - Tyre Presure
