1. SOLID Refactor (o cmo saber si refactorizar o no)

2. Qu haces t aqu? (o quin soy y por qu me decid a hacer esta charla) 3. Me presento Enrique Amodeo

• Me dedico al software

4. > 10 aos de experiencia

5. Desarrollo y arquitectura de software 6. Consultora y formacin 7. > 4 aos haciendo agilismo 8. Mail:[email_address] 9. Blog:http://eamodeorubio.wordpress.com/ 10. Sgueme, leches:@eamodeorubio Con esta pose saldr ms guapo 11. Hace un tiempo 12. Refactor: Qu y Por qu 13. Qu es refactor?

Es una transformacin de cdigo

14. No altera la funcionalidad del software 15. Pero s el diseo 16. Qu es refactor?

Es una transformacin de cdigo

17. No altera la funcionalidad del software 18. Pero s el diseo Y esto para qu sirve? 19. Qu es refactor? Parte integral del ciclo de TDD TDD sin refactor no asegura calidad Despus 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 Cdigo Aplicacin 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 Cdigo Aplicacin Ejecutar Test NO 21. Cundo tengo que refactorizar?

El cdigo no es de suficiente calidad

22. Tienes tiempo (cuidado con el timebox) 23. El beneficio en calidad compensa el coste 24. Cundo tengo que refactorizar?

El cdigo no es de suficiente calidad

25. Tienes tiempo (cuidado con el timebox) 26. El beneficio en calidad compensa el coste Calidad? No quiero liarme con plugins, mtricas y dems 27. Midiendo la calidad a ojo: SOLID y DRY (o cmo saber si el cdigo es bueno de un vistazo) 28. Calidad sin herramientas

Evaluar de un vistazo la calidad del cdigo

29. Reglas prcticas de fcil aplicacin 30. Reglas sencillas y claras para evitar polmicas 31. Calidad sin herramientas

Evaluar de un vistazo la calidad del cdigo

32. Reglas prcticas de fcil aplicacin 33. Reglas sencillas y claras para evitar polmicas DRY 34. Calidad sin herramientas

Evaluar de un vistazo la calidad del cdigo

35. Reglas prcticas de fcil aplicacin 36. Reglas sencillas y claras para evitar polmicas DRY SOLID 37. DRY

Dont Repeat Yourself

38. Pragmatic programmer

Evitar duplicacin de informacin (en sentido amplio)

• Cdigo (copy&paste)

39. Datos

40. Documentacin y comentarios Elimina doble mantenimiento y sus costes y riesgos 41. SOLID

Tito Bob

42. Son en realidad 5 principios

• S -> Single Responsibility

43. O -> Open Closed

44. L -> Liskov Substitution 45. I -> Interface Segregation 46. D -> Dependency Inversion 47. Single Responsability

Artefacto = mtodo, clase, paquete

48. Artefactos especializados en un responsabilidad 49. Promueve la alta cohesin 50. Evita el acoplamiento entre features y el cdigo espagueti 51. Facilita la identificacin del cdigo a modificar ante un cambio/bug Cada artefacto debe tener una nica razn para cambiar 52. Open Closed

O sea, su comportamiento debe ser configurable

53. Promueve un diseo OO basado en un grafo de objetos configurable (GOOS) 54. Cooperacin entre objetos 55. Bajo acoplamiento 56. Podemos aadir/modificar features sin modificar el cdigo ya existente Artefactos deben ser extensibles sin necesidad de modificar su cdigo 57. Liskov Substitution

Asegurar el buen comportamiento de la herencia

58. Evitar el problema de la clase base frgil 59. No hacer extends slo por similitud sintctica 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 62. Interface Segregation

O sea, las interfaces tambin se rigen por el principio de nica responsabilidad

63. Promueven las Role Interfaces (GOOS) 64. Evitar interfaces sin una responsabilidad clara o que sirvan para todo 65. Alta cohesin Muchas interfaces especficas son mejores que una nica de propsito general 66. Dependency Inversion

Todas las dependencias deben estar al mismo nivel de abstraccin

67. Puede ser el mismo o uno inmediatamente inferior al del artefacto en cuestin 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 72. SOLID + DRY

Class-Responsability-Collaboration

73. Sinergia con el estilo GOOS de TDD 74. Diseo basado en grafos de pequeos 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 77. Que yo uso JS o Ruby! No tengo interfaces !

Class-Responsability-Collaboration

78. Colaboracin -> 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 construccin JAVA ! 81. Entonces qu pasa con el TDD? (o cmo engancha todo esto) 82. TDD Reloaded Requisito / Tarea / Bug Escribir Test Pasa Test? Refactor Pendiente para la prxima! SI NO SI Escribir / Arreglar Cdigo Ejecutar Test NO DRY & SOLID? TENGO TIEMPO? FIN SI NO 83. TDD Reloaded Requisito / Tarea / Bug Escribir Test Pasa Test? Refactor Pendiente para la prxima! SI NO SI Escribir / Arreglar Cdigo Ejecutar Test NO DRY & SOLID? Test & Production code TENGO TIEMPO? FIN SI NO 84. Q & A? 85. Manos a la obra 86. FizzBuzz

Recibes un entero y devuelves una cadena

87. Devolver Fizz si el nmero es divisible por 3 88. Devolver Buzz si el nmero 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.