Presentación del seminario "Técnicas avanzadas de programación" donde se tratan los principios SOLID y la práctica de TDD http://bit.ly/vWuad4

1. Técnicas avanzadas de
diseño y programación

2. Desarrollador / Líder Técnico
Instructor / Ayudante de cátedra
Orador Aficionado
Agilista Entusiasta
Gabriel Falcone

3. Buen diseño

4. Buen diseño
Cambios

5. Buen diseño
Entregables

6. Buen diseño
Complejidad

8. Problemas de diseño

9. Problemas de diseño
Fragilidad

10. Problemas de diseño
Rigidez

11. Problemas de diseño
Inmovilidad

12. Problemas de diseño
Viscosidad

13. Problemas de diseño
Difícil de entender

15. S.O.L.I.D.
Single Responsability Principle
Open Closed Principle
Liskov Susbtitution Principle
Interface Segregation Principle
Dependency Inversion Principle

17. Única Responsabilidad
Una clase debe tener una única razón
para ser cambiada

18. Única Responsabilidad
Los suizos no están de acuerdo con
este principio

20. Abierto - Cerrado
Las entidades de software (clases,
módulos, funciones, etc) deben estar
abiertas a extensión, pero cerradas a
modificación.
Los cambios deben generar código
nuevo, no modificar el código viejo.

22. Sustitución de Liskov
Donde se usa una referencia a una
clase base debería poder usarse
clases derivadas sin que esto afecte.

24. Segregación de interfaz
Los clientes no deben ser forzados a
depender de métodos que no usan.

26. Inversión de dependencia
Los módulos de alto nivel no deben
depender de los módulos de bajo
nivel. Ambos deben depender de
abstracciones.
Las abstracciones no deben depender
de detalles. Los detalles deben
depender de las abstracciones.

29. ¿Por qué
hablamos de una
metodología que
tiene mas de 10
años?

30. ¡¡Me dan
asco!!

31. Yo soy programador, no tester

32. Es trivial, no necesita testing

33. No hay tiempo para testing

34. Es muy difícil de probar

35. Unit Testing

36. MSTest

37. Demo

38. El patrón 3A
Arrange
Act
Assert

39. Demo

40. Eso no huele a
un Unit Test

41. Rápido

42. Atómico

43. Repetible

44. Aislado

45. Demo

46. Mocks
http://martinfowler.com/articles/mocksArentStubs.html

47. Demo

48. TDD

49. TDD
Es una metodología

50. TDD
¡Pero no sobre testing!

51. TDD
¡Sino sobre diseño!

52. TDD
Escribiendo los tests primero

53. Escribir el código mas simple
que funcione
Everything should
be made as simple
as possible, but
not simpler.

54. Guiar el diseño del código
mediante unit tests

55. Escribir soluciones simples a
los requerimientos actuales

56. Escribir solo el código para
“superar” el test

57. Ciclo de vida en TDD
Nuevo
requerimiento

58. Ciclo de vida en TDD
Escribir
un test
Nuevo
requerimiento

59. Ciclo de vida en TDD
Ejecutar
el test
Escribir
un test
Nuevo
requerimiento
Hacer que
falle

60. Ciclo de vida en TDD
Ejecutar
el test
Escribir
un test
Nuevo
requerimiento
Escribir
el código
Hacer que
falle

61. Ciclo de vida en TDD
Ejecutar
el test
Escribir
un test
Nuevo
requerimiento
Escribir
el código
Ejecutar
el test
Hacer que
falle
Hacer que
funcione

62. Ciclo de vida en TDD
Ejecutar
el test
Escribir
un test
Nuevo
requerimiento
Escribir
el código
Ejecutar
el test
Refactorizar
Hacer que
falle
Hacer que
funcione

63. Ciclo de vida en TDD
Ejecutar
el test
Escribir
un test
Nuevo
requerimiento
Escribir
el código
Ejecutar
el test
Refactorizar
Ejecutar
el test
Hacer que
falle
Hacer que
funcione
Mejorar el
código

64. Ciclo de vida en TDD
Ejecutar
el test
Escribir
un test
Nuevo
requerimiento
Escribir
el código
Ejecutar
el test
Refactorizar
Ejecutar
el test
Hacer que
falle
Hacer que
funcione
Mejorar el
código

65. Ciclo de vida en TDD

66. Demo

67. TDD

68. TDD
Promueve la calidad en nuestro
código

69. TDD
Promueve la calidad en nuestro
código
Permite obtener soluciones mas
simples

70. TDD
Promueve la calidad en nuestro
código
Brinda confianza sobre el código
que estamos agregando
Permite obtener soluciones mas
simples

71. Preguntas
mail: gabrielfalcone@gmail.com
gfalcone@fi.uba.ar
twitter: gabrielfalcone
skype: gabrielfalcone