Enrique Amodeo

1. SOLID Refactor (o cómo saber si refactorizar o no)

2. ¿Qué haces tú aquí? (o quién soy y por qué me decidí a hacer esta charla)

4. > 10 años de experiencia

5. Desarrollo y arquitectura de software

6. Consultoría y formación

7. > 4 años haciendo agilismo

8. Mail: [email_address]

9. Blog: http://eamodeorubio.wordpress.com/

10. Sígueme, leches: @eamodeorubio Con esta pose saldré más guapo

11. Hace un tiempo…

12. Refactor: Qué y Por qué

14. No altera la funcionalidad del software

15. Pero sí el diseño

17. No altera la funcionalidad del software

18. Pero sí el diseño ¿Y esto para qué sirve?

19. ¿Qué es refactor? Parte integral del ciclo de TDD TDD sin refactor no asegura calidad Después de un refactor pasar test para asegurarse que no se cambió la funcionalidad Requisito / Tarea / Bug Escribir Test Unitario ¿Pasa Test? Refactor ¿Necesita Refactor? Luces Verdes! SI NO SI Escribir / Arreglar Código Aplicación Ejecutar Test NO

20. ¿Cuando tengo que refactorizar? Requisito / Tarea / Bug Escribir Test Unitario ¿Pasa Test? Refactor ¿Necesita Refactor? Luces Verdes! SI NO SI Escribir / Arreglar Código Aplicación Ejecutar Test NO

22. Tienes tiempo (cuidado con el timebox)

23. El beneficio en calidad compensa el coste

25. Tienes tiempo (cuidado con el timebox)

26. El beneficio en calidad compensa el coste ¿Calidad? No quiero liarme con plugins, métricas y demás

27. Midiendo la calidad a ojo: SOLID y DRY (o cómo saber si el código es bueno de un vistazo)

29. Reglas prácticas de fácil aplicación

30. Reglas sencillas y claras para evitar polémicas

32. Reglas prácticas de fácil aplicación

33. Reglas sencillas y claras para evitar polémicas DRY

35. Reglas prácticas de fácil aplicación

36. Reglas sencillas y claras para evitar polémicas DRY SOLID

39. Datos

43. O -> Open Closed

44. L -> Liskov Substitution

45. I -> Interface Segregation

46. D -> Dependency Inversion

48. Artefactos especializados en un responsabilidad

49. Promueve la alta cohesión

50. Evita el acoplamiento entre features y el código espagueti

51. Facilita la identificación del código a modificar ante un cambio/bug Cada artefacto debe tener una única razón para cambiar

53. Promueve un diseño OO basado en un grafo de objetos configurable (GOOS)

54. Cooperación entre objetos

55. Bajo acoplamiento

56. Podemos añadir/modificar features sin modificar el código ya existente Artefactos deben ser extensibles sin necesidad de modificar su código

58. Evitar el problema de la clase base frágil

59. No hacer “extends” sólo por similitud sintáctica

60. Los subtipos pueden debilitar las precondiciones y reforzar las postcondiciones

61. Promueve el uso de “interfaces” Una instancia puede ser reemplazada por otra que sea de un subtipo y no causar bugs

63. Promueven las Role Interfaces (GOOS)

64. Evitar interfaces sin una responsabilidad clara o que sirvan para todo

65. Alta cohesión Muchas interfaces específicas son mejores que una única de propósito general

67. Puede ser el mismo o uno inmediatamente inferior al del artefacto en cuestión

68. Bajo acoplamiento

69. Extensibilidad (las abstracciones pueden tener muchas implementaciones)

70. No “romper” capas de arquitectura

71. Role Interfaces para representar abstracciones Depender de abstracciones, no de cosas concretas

73. Sinergia con el estilo GOOS de TDD

74. Diseño basado en grafos de pequeños objetos interconectados con role interfaces -> True OO

75. Configurable y extensible reemplazando los objetos por otros que cumplan las misma interfaces

76. 1 cambio -> 1 interfaz y/o 1 clase

78. Colaboración -> Contrato entre dos partes -> protocolo

79. Interface es el conjunto de mensajes enviados/recibidos necesarios para cumplir tu parte del contrato

80. ¡ No es una construcción JAVA !

81. ¿Entonces qué pasa con el TDD? (o cómo engancha todo esto)

82. TDD Reloaded Requisito / Tarea / Bug Escribir Test ¿Pasa Test? Refactor ¡Pendiente para la próxima! SI NO SI Escribir / Arreglar Código Ejecutar Test NO ¿DRY & SOLID? ¿TENGO TIEMPO? FIN SI NO

83. TDD Reloaded Requisito / Tarea / Bug Escribir Test ¿Pasa Test? Refactor ¡Pendiente para la próxima! SI NO SI Escribir / Arreglar Código Ejecutar Test NO ¿DRY & SOLID? Test & Production code ¿TENGO TIEMPO? FIN SI NO

84. ¿Q & A?

85. Manos a la obra

87. Devolver “Fizz” si el número es divisible por 3

88. Devolver “Buzz” si el número es divisible por 5

89. Devolver “FizzBuzz” si es divisible por 5 y 3

90. Devolver “” si no es divisible ni por 5 ni por 3

91. TDD y Pair Programming

92. 10 min.