Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Taller SOLID Refactor

1,627 views

Published on

Enrique Amodeo

  • Be the first to comment

Taller SOLID Refactor

  1. 1. SOLID Refactor (o cómo saber si refactorizar o no)
  2. 2. ¿Qué haces tú aquí? (o quién soy y por qué me decidí a hacer esta charla)
  3. 3. Me presento Enrique Amodeo <ul><ul><li>Me dedico al software
  4. 4. > 10 años de experiencia
  5. 5. Desarrollo y arquitectura de software
  6. 6. Consultoría y formación
  7. 7. > 4 años haciendo agilismo
  8. 8. Mail: [email_address]
  9. 9. Blog: http://eamodeorubio.wordpress.com/
  10. 10. Sígueme, leches: @eamodeorubio </li></ul></ul>Con esta pose saldré más guapo
  11. 11. Hace un tiempo…
  12. 12. Refactor: Qué y Por qué
  13. 13. ¿Qué es refactor? <ul><li>Es una transformación de código
  14. 14. No altera la funcionalidad del software
  15. 15. Pero sí el diseño </li></ul>
  16. 16. ¿Qué es refactor? <ul><li>Es una transformación de código
  17. 17. No altera la funcionalidad del software
  18. 18. Pero sí el diseño </li></ul>¿Y esto para qué sirve?
  19. 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. 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
  21. 21. ¿Cuándo tengo que refactorizar? <ul><li>El código no es de suficiente calidad
  22. 22. Tienes tiempo (cuidado con el timebox)
  23. 23. El beneficio en calidad compensa el coste </li></ul>
  24. 24. ¿Cuándo tengo que refactorizar? <ul><li>El código no es de suficiente calidad
  25. 25. Tienes tiempo (cuidado con el timebox)
  26. 26. El beneficio en calidad compensa el coste </li></ul>¿Calidad? No quiero liarme con plugins, métricas y demás
  27. 27. Midiendo la calidad a ojo: SOLID y DRY (o cómo saber si el código es bueno de un vistazo)
  28. 28. Calidad sin herramientas <ul><li>Evaluar de un vistazo la calidad del código
  29. 29. Reglas prácticas de fácil aplicación
  30. 30. Reglas sencillas y claras para evitar polémicas </li></ul>
  31. 31. Calidad sin herramientas <ul><li>Evaluar de un vistazo la calidad del código
  32. 32. Reglas prácticas de fácil aplicación
  33. 33. Reglas sencillas y claras para evitar polémicas </li></ul>DRY
  34. 34. Calidad sin herramientas <ul><li>Evaluar de un vistazo la calidad del código
  35. 35. Reglas prácticas de fácil aplicación
  36. 36. Reglas sencillas y claras para evitar polémicas </li></ul>DRY SOLID
  37. 37. DRY <ul><li>Don’t Repeat Yourself
  38. 38. Pragmatic programmer </li></ul><ul><li>Evitar duplicación de información (en sentido amplio) </li></ul><ul><ul><li>Código (copy&paste)
  39. 39. Datos
  40. 40. Documentación y comentarios </li></ul><li>Elimina doble mantenimiento y sus costes y riesgos </li></ul>
  41. 41. SOLID <ul><li>Tito Bob
  42. 42. Son en realidad 5 principios </li></ul><ul><ul><li>S -> Single Responsibility
  43. 43. O -> Open Closed
  44. 44. L -> Liskov Substitution
  45. 45. I -> Interface Segregation
  46. 46. D -> Dependency Inversion </li></ul></ul>
  47. 47. Single Responsability <ul><li>Artefacto = método, clase, paquete…
  48. 48. Artefactos especializados en un responsabilidad
  49. 49. Promueve la alta cohesión
  50. 50. Evita el acoplamiento entre features y el código espagueti
  51. 51. Facilita la identificación del código a modificar ante un cambio/bug </li></ul>Cada artefacto debe tener una única razón para cambiar
  52. 52. Open Closed <ul><li>O sea, su comportamiento debe ser configurable
  53. 53. Promueve un diseño OO basado en un grafo de objetos configurable (GOOS)
  54. 54. Cooperación entre objetos
  55. 55. Bajo acoplamiento
  56. 56. Podemos añadir/modificar features sin modificar el código ya existente </li></ul>Artefactos deben ser extensibles sin necesidad de modificar su código
  57. 57. Liskov Substitution <ul><li>Asegurar el buen comportamiento de la herencia
  58. 58. Evitar el problema de la clase base frágil
  59. 59. No hacer “extends” sólo por similitud sintáctica
  60. 60. Los subtipos pueden debilitar las precondiciones y reforzar las postcondiciones
  61. 61. Promueve el uso de “interfaces” </li></ul>Una instancia puede ser reemplazada por otra que sea de un subtipo y no causar bugs
  62. 62. Interface Segregation <ul><li>O sea, las interfaces también se rigen por el principio de única responsabilidad
  63. 63. Promueven las Role Interfaces (GOOS)
  64. 64. Evitar interfaces sin una responsabilidad clara o que sirvan para todo
  65. 65. Alta cohesión </li></ul>Muchas interfaces específicas son mejores que una única de propósito general
  66. 66. Dependency Inversion <ul><li>Todas las dependencias deben estar al mismo nivel de abstracción
  67. 67. Puede ser el mismo o uno inmediatamente inferior al del artefacto en cuestión
  68. 68. Bajo acoplamiento
  69. 69. Extensibilidad (las abstracciones pueden tener muchas implementaciones)
  70. 70. No “romper” capas de arquitectura
  71. 71. Role Interfaces para representar abstracciones </li></ul>Depender de abstracciones, no de cosas concretas
  72. 72. SOLID + DRY <ul><li>Class-Responsability-Collaboration
  73. 73. Sinergia con el estilo GOOS de TDD
  74. 74. Diseño basado en grafos de pequeños objetos interconectados con role interfaces -> True OO
  75. 75. Configurable y extensible reemplazando los objetos por otros que cumplan las misma interfaces
  76. 76. 1 cambio -> 1 interfaz y/o 1 clase </li></ul>
  77. 77. ¡Que yo uso JS o Ruby! ¡ No tengo interfaces ! <ul><li>Class-Responsability-Collaboration
  78. 78. Colaboración -> Contrato entre dos partes -> protocolo
  79. 79. Interface es el conjunto de mensajes enviados/recibidos necesarios para cumplir tu parte del contrato
  80. 80. ¡ No es una construcción JAVA ! </li></ul>
  81. 81. ¿Entonces qué pasa con el TDD? (o cómo engancha todo esto)
  82. 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. 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. 84. ¿Q & A?
  85. 85. Manos a la obra
  86. 86. FizzBuzz <ul><li>Recibes un entero y devuelves una cadena
  87. 87. Devolver “Fizz” si el número es divisible por 3
  88. 88. Devolver “Buzz” si el número es divisible por 5
  89. 89. Devolver “FizzBuzz” si es divisible por 5 y 3
  90. 90. Devolver “” si no es divisible ni por 5 ni por 3
  91. 91. TDD y Pair Programming
  92. 92. 10 min. </li></ul>

×