Refactoring

1. Refactoring Rosemary TorricoBascopé

2. Introducción • La evolución de un sistema software conlleva cierto grado de deterioro de su estructura. • El mantenimiento se centra más en la corrección de bugs y en la inclusión de nuevas funcionalidades que en el seguimiento y la mejora de su arquitectura y diseño. • La malas prácticas de diseño, causadas a menudo por la inexperiencia, el conocimiento insuficiente o la urgencia, originan designsmells (“malos olores en el diseño”): problemas en la estructura de un sistema, que no producen errores de compilación o de ejecución, pero que afectan negativamente a los factores de calidad del software

3. Quéesrefactorización? • "Refactorizar es una técnica disciplinada para reestructurar una porción de código, alterando su estructura interna sin modificar su comportamiento externo.” Martin Fowler • Cadatransformaciónllamada refactoring sehace de a poco. • Unasecuencia de transformacionespuedeproducirunareestructuraciónsignificativa.

4. Proceso de mejora continua • El refactoring se considera  un proceso de mejora continua. Debido a que se debe ir perfeccionando el software iteración por iteración. Estos cambios deben ser muy pequeños, a tal punto que pueda ser controlado sin miedo a generar errores. 

5. Objetivo del refactoring • Es realizar y mantener el código limpio y bien estructurado, permitiendo una mejor lectura del código para comprender que es lo que se está realizando.

6. ¿Por qué se debe Refactorizar el código? • Calidad • Crear un código de calidad es un código sencillo y bien estructurado, que cualquiera pueda leer y entender sin necesidad de haber participado dentro del equipo de desarrollo.   • Eficiencia: • El esfuerzo  que se debe realizar para mantener un código limpio, bien estructura, sin  duplicación de código y con diseño simple  se verá recompensado cuando se deba realizar tareas de mantenimiento a la aplicación, así como para la detección y corrección de errores y la creación de nuevas funcionalidades.  • Diseño Evolutivo en lugar de Gran Diseño Inicial: • En muchas ocasiones los requisitos al principio del proyecto no están suficientemente especificados y debemos abordar el diseño de una forma gradual. • Cuando tenemos unos requisitos claros y no cambiantes un buen análisis de los mismos puede originar un diseño y una implementación brillantes, pero cuando los requisitos van cambiando según avanza el proyecto, y se añaden nuevas funcionalidades según se le van ocurriendo a los participantes o clientes, un diseño inicial no es más que lo que eran los requisitos iniciales. • Refactorizar nos permitirá ir evolucionando el diseño según incluyamos nuevas funcionalidades, lo que implica muchas veces cambios importantes en la arquitectura, añadir cosas y borrar otras. • Evitar la Reescritura de código: • Refactorizar es más beneficio que reescribir.   • Nunca es bueno empezar de cero a pesar de que el código en el que se encuentra no es entendible y desorganizado. • Mejor opción refactorizar y empezar a usar ese código.

7. Bad Smell • Un “BadSmell” es un indicio de que existe código de poca calidad. • Martin Fowler define el BadSmell de la siguiente forma:“Un método parece estar más interesado en otra clase que la propia clase a la que pertenece”.

8. Bad Smells • Código Duplicado: • Poseer la misma estructura de código en dos o más lugares es señal de que ese código necesita refactorización. • Si se realiza un cambio en alguno de esos lugares, probablemente sea necesario realizar ese cambio en los otros lugares, pero muchas veces no se suele acordar de realizar esos cambios. • Métodos Largos: • Métodos largos se deben descomponer para una mayor claridad y facilidad de mantenimiento. • Clases grandes: • Esto es indicio de que las clases deben estar haciendo demasiado, usualmente tienen gran número de variables instanciadas. Mucha veces algunas de estas variables pueden ser agrupadas o en otros casos solamente son utilizadas ocasionalmente. • Lista de parámetros larga: • Una lista larga de parámetros muchas veces es difícil de entender.  No necesariamente se deben pasar todos los parámetros únicamente los necesarios.

9. Bad Smells • Cambio divergente: • El código debe estar estructurado para realizar cambios de forma sencilla. • Si una clase es cambiada de diferentes formas por diferentes razones, mucha veces es mejor dividir la clase en dos, una clase específica para cada tipo de cambio que se presente. • Cirugía de la escopeta: • Es el opuesto al cambio divergente. •  Si un programa requiere muchos cambios pequeños en diferentes clases, y se hace muy difícil localizar todos los lugares exactos que se necesitan cambiar. Es mejor que todos esos lugares afectados agrupados dentro de una sola clase.

10. Envidia de las funcionalidades: • Cuando un método dentro de una clase está más interesado en los atributos, usualmente en los datos de otra clase que de su propia clase.  Este método estaría más confortable en la otra clase. • Declaración de “Swtich”: • Muchas veces los “Switch” tienden a ocasionar duplicación. • Se pueden encontrar declaraciones de “switch” similiares dispersar a lo largo del programa. • Si se debe pasar un nuevo valor, se deben chequear todas las declaraciones de “switch”. • Las clases y los poliformismos suelen ser lo más apropiado para resolver esta situación.   • Obsesión por los primitivos: • Algunas veces vale la pena cambiar los tipos de datos primitivos en clases simples que realicen de forma más clara esa tarea. • Comentarios:  • El comentario miente, el código no. • No es recomendable reemplazar el código mal escrito por comentarios. Por lo tanto se debe mejorar el código. 

11. Clasesflojas • Clasesque no hacen un trabajoutildebe ser eliminadas • Generalidadespeculativa • Frecuentemente se diseñanclases y métodosparahacercosasque en realidad no se necesitan • Campos temporales • Puede ser confusocuandoatributos de unaclase son usadosocacionalmente.

12. Cadena de mensajes • Cuando un clientepide un objeto de otroobjeto, luegoqué se pidio del otroobjeto? • Hombre medio • La delegacionesfrecuentementeutil, peroavecespuedeirmuylejos. • Si unaclaseactuacomodelegadaperoejecutatrabajo extra no util, podria ser posibleeliminarla de a jerarquía

13. Data class • Clasesque solo tienendatos y metodos de acceso, pero no un comportamiento real. • Si el datoespublicohazloprivado. • Legadorechazado • Si unasubclase no quiere o no necesitatodo el comportamiento de la clase base, quiza la jerarquía de clasesesteequivocada.

14. El sistemadebeseguirfuncionando a 100% después de cadarefactorización (pequeña), reduciendo la posibilidad de que el sistema se dañegravementedurante la restructuración.

15. Principios • Escribircódigo simple • Hacerlo simple no esfácil • Einstein • Escribircódigoclaro, que se entienda • Escribircódigobrevecorto, no sentenciaslargas (clases, programascortos). • No escribircódigoque no sea necesario • Está mi codigohaciendounacosa, y unacosabien?

16. Smell bad • Clever code • Mejorescribircodigoclaro, simple en lugar de inteligente • Métodos largos • Dificil de leerlos, dondeempieza , dondetermina • Dificil de reutilizarlos • Dificil de probarlos • Complejos • Efectoscolaterales • Dificil de vertodo • Conllevaduplicacion • Dificil de mantener • Es propenso a errores

17. El códigoenterodebepoder verse en una sola ventana • El códigodebeestar a un nivel de abstracción • Como estuvotu fin de semana? • Fui al cine,.. No esnecesariomasdetalles, quepeliculaviste? Yaes un segundonivel. • Eliminarduplicación • Es dificil de mantener

18. Eliminardependencia • Revisar el codigocontinuamente

19. Bibliografía • Refactoring: Improving the Design of Existing Code, Martin Fowler • http://ebooks.elportal.info/Addison%20Wesley%20-%20Refactoring%20-%20Improving%20the%20Design%20of%20Existing%20Code.pdf • http://refactoring.com/ • http://www.youtube.com/watch?v=iGsPeR-SYYo