Your SlideShare is downloading. ×
"Demystifying development techniques" por @eturino
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

"Demystifying development techniques" por @eturino

274
views

Published on

Presentación realizada en el #webcat Barcelona de Febrero 2014 …

Presentación realizada en el #webcat Barcelona de Febrero 2014
Autor: Eduardo Turiño (@eturino)

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
274
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Demystifying Development Techniques @eturino Eduardo Turiño
  • 2. ¡muerte a los puristas! el “otro título”
  • 3. las metodologías son sólo herramientas
  • 4. menos errores
 más velocidad 
 más constancia
  • 5. mejorar en cada paso lo que más moleste
  • 6. • nivel de Proyecto (Scrum, Kanban…) • nivel de Desarrollo! • nivel de Productividad (GTD, Pomodoro…)
  • 7. el camino 1. tradicional 2. tests automáticos 3. Test-First 1 643 52 4. TDD 5. BDD 6. completando BDD
  • 8. objetivos del desarrollo de software 1. hace lo que tiene que hacer y no otra cosa! 2. funciona sin fallos! 3. no rompe lo que ya funcionaba! 4. fácil de adaptar a nuevas funcionalidades
  • 9. tradicional ¿cómo se hace normalmente? 643 51 2
  • 10. tradicional • planificación y estudio de requisitos • desarrollo: diseño e implementación • pruebas: QA (Quality Assurance)
  • 11. pruebas (QA) • “hace lo que tiene que hacer y no otra cosa”: Pruebas de Aceptación • “funciona sin fallos”:
 Pruebas de Exploración • “no rompe lo que ya funcionaba”:
 Pruebas de Regresión
  • 12. lo que más molesta del enfoque tradicional demasiadas pruebas (no se hacen)
  • 13. tests automáticos automatizando las pruebas manuales 1 643 52
  • 14. tipos de tests de Aceptación: 
 comprueba funcionalidad de Regresión: 
 nos alerta si hemos roto algo anterior Unitarios: 
 componente (aislado) funciona bien
  • 15. cuidado sustituyen a pruebas manuales: probar comportamiento
  • 16. lo que más molesta de los tests automáticos • poca motivación para hacerlos • “¿y cómo pruebo yo esto?”
  • 17. Test-First probando lo que aún no hemos desarrollado 1 64 532
  • 18. primero el test ! después el código de producción
  • 19. ventajas de Test-First • mayor motivación • sensación de seguridad: menos fallos tontos • código más sencillo y fácil de probar
  • 20. lo que se echa en falta de Test-First no nos sirve de guía
  • 21. TDD Test Driven Development 1 652 43
  • 22. los tests como 
 guía del desarrollo
  • 23. TDD • el objetivo es el código de producción, 
 los tests son una herramienta para ese objetivo • que los tests sirvan como pruebas es secundario • se basa en repetición de un ciclo básico
  • 24. ciclo básico de TDD 1. escribir un nuevo test y verificar que falla 2. implementar lo mínimo para que: A. cambie el mensaje del error B. pase el test 3. repetir el punto 2 hasta que pase el test 4. refactorizar, sin cambiar comportamiento
  • 25. Red - Green - Refactor Green Red Refactor
  • 26. Red - Green - Refactor Green Red Refactor ⇧ funcionalidad ⇧ diseño seguimos
  • 27. bases de TDD • tests concisos • se prueba nuestro código público • antes de iniciar algo nuevo, dejar en verde • Diseño Emergente: al escribir test y refactorizar
  • 28. temas a mejorar de TDD frágil y tedioso 
 muchos test unitarios
  • 29. BDD Behaviour Driven Development ! o TDD “bien hecho” 1 62 53 4
  • 30. comportamiento, comunicación, y tests de aceptación
  • 31. BDD a grandes rasgos • usar lenguaje de dominio, no técnico • escribir tests de aceptación con los clientes (expertos de dominio) • ciclo de desarrollo usando un doble anillo RGR
  • 32. doble anillo de BDD 1. se empieza con un ciclo RGR de un test de aceptación (Anillo Exterior) 2. se va desarrollando hasta que el mensaje de error ya no nos es útil para seguir (outside in) 3. se baja a hacer un test unitario y se continúa con ese ciclo RGR (Anillo Interior) 4. anillo Interior refactorizado: se sube al Anillo Exterior 5. repetir 2-4 hasta que el Anillo Exterior esté completado
  • 33. doble anillo Rf R Rf R G G Aceptación Unitario
  • 34. qué se consigue con BDD • mejor comunicación con clientes y stakeholders • menos frágil: tests de aceptación y 
 sólo los unitarios necesarios • más natural y rápido
  • 35. limitaciones de BDD • sólo probamos el caso feliz • cuando el test es muy difícil de programar • cuando se tiene muy claro • cuando los tests unitarios se rompen • cuando no se tiene ni idea de por dónde tirar
  • 36. ¿y ahora?
  • 37. completamos con otras técnicas
  • 38. solucionando “probar sólo el caso feliz” 1 2 3 4 5 6
  • 39. tests unitarios extra • tras un ciclo RGR y antes del siguiente • ¿cómo debería comportarse el sistema ante esta situación? • es diseño • ok si el test empieza en Verde lugar de Rojo.
  • 40. solucionando “test difícil de programar” 1 2 3 4 5 6
  • 41. solucionando “test muy difícil” sustituye por 
 prueba manual
  • 42. solucionando “cuando es muy fácil” 1 2 3 4 5 6
  • 43. solucionando “cuando es muy fácil” pasos largos
  • 44. solucionando “tests se rompen” 1 2 3 4 65
  • 45. solucionando “tests se rompen” arreglarlos o tirarlos
  • 46. solucionando “cuando es muy difícil” 1 2 3 4 65
  • 47. solucionando “cuando es muy difícil” REPLs y Spikes
  • 48. REPL • Read Eval Print Loop • consola de javascript, irb/pry… • ir ejecutando lo que se programa en el momento • muy bueno para pruebas, bugfixing, 
 y para “¿cómo se usaba esto?” • REPL Driven Development
  • 49. Spike experimento rápido para: A. disminuir riesgo técnico B. pruebas de concepto
  • 50. Spike cuando se termina: • si es muy horrible:
 se tira • si se puede refactorizar y “no está tan mal”:
 se usa y se le añade un test de regresión
  • 51. concluyendo…
  • 52. mi proceso al principio • diseño y desarrollo tradicional • pruebas al final (bastante escasas), 
 apoyado por un buen equipo de QA
  • 53. mi proceso ahora • por defecto: 
 BDD con Outside-In • “¿cómo era esto?” y “¿cómo se usaba tal?”:
 REPLs! • “ni idea” o “peligroso”:
 Spikes! • “trillado”: 
 Pasos largos! • “test difícil”:
 Prueba manual
  • 54. ¿qué he ganado? • muchos menos errores • más constante • más seguro • más rápido
  • 55. buscando 
 las mejores herramientas para cada ocasión
  • 56. el objetivo es el software ! complementar tu metodología 
 con otras técnicas
 está bien