Taller SOLID Refactor
4 recomendaciones901 vistas
Este documento habla sobre refactorización de código y los principios SOLID y DRY para evaluar la calidad del código. Explica que la refactorización es una transformación del código que no altera la funcionalidad pero sí mejora el diseño. También describe cada uno de los principios SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation y Dependency Inversion) y el principio DRY (Don't Repeat Yourself) y cómo aplicarlos para mejorar la calidad del código de manera sencilla.
![Mail: [email_address]](https://image.slidesharecdn.com/solidrefactor-111106062243-phpapp02/85/Taller-SOLID-Refactor-8-320.jpg)
Taller SOLID Refactor
- 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)
- 3. Me presento Enrique Amodeo Me dedico al software
- 4. > 10 años de experiencia
- 5. Desarrollo y arquitectura de software
- 7. > 4 años haciendo agilismo
- 10. Sígueme, leches: @eamodeorubio Con esta pose saldré más guapo
- 11. Hace un tiempo…
- 12. Refactor: Qué y Por qué
- 13. ¿Qué es refactor? Es una transformación de código
- 14. No altera la funcionalidad del software
- 15. Pero sí el diseño
- 16. ¿Qué es refactor? Es una transformación de código
- 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
- 21. ¿Cuándo tengo que refactorizar? El código no es de suficiente calidad
- 22. Tienes tiempo (cuidado con el timebox)
- 23. El beneficio en calidad compensa el coste
- 24. ¿Cuándo tengo que refactorizar? El código 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, 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)
- 28. Calidad sin herramientas Evaluar de un vistazo la calidad del código
- 29. Reglas prácticas de fácil aplicación
- 30. Reglas sencillas y claras para evitar polémicas
- 31. Calidad sin herramientas Evaluar de un vistazo la calidad del código
- 32. Reglas prácticas de fácil aplicación
- 33. Reglas sencillas y claras para evitar polémicas DRY
- 34. Calidad sin herramientas Evaluar de un vistazo la calidad del código
- 35. Reglas prácticas de fácil aplicación
- 36. Reglas sencillas y claras para evitar polémicas DRY SOLID
- 37. DRY Don’t Repeat Yourself
- 38. Pragmatic programmer Evitar duplicación de información (en sentido amplio) Código (copy&paste)
- 39. Datos
- 40. Documentación 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 = método, clase, paquete…
- 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
- 52. Open Closed O sea, su comportamiento debe ser configurable
- 53. Promueve un diseño OO basado en un grafo de objetos configurable (GOOS)
- 56. Podemos añadir/modificar features sin modificar el código ya existente Artefactos deben ser extensibles sin necesidad de modificar su código
- 57. Liskov Substitution Asegurar el buen comportamiento de la herencia
- 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
- 62. Interface Segregation O sea, las interfaces también 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 cohesión Muchas interfaces específicas son mejores que una única de propósito general
- 66. Dependency Inversion Todas las dependencias deben estar al mismo nivel de abstracción
- 67. Puede ser el mismo o uno inmediatamente inferior al del artefacto en cuestión
- 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. 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
- 77. ¡Que yo uso JS o Ruby! ¡ No tengo interfaces ! Class-Responsability-Collaboration
- 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
- 86. FizzBuzz Recibes un entero y devuelves una cadena
- 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.