Refactorizacion

Refactorización
MEJORANDO EL DISEÑO DEL CÓDIGO EXISTENTE

Tomar código existente y hacerlo mejor
• Mas estructurado
• Mas legible
• Mas entendible
• Mas extensible
• No necesariamente mas eficiente
• No necesariamente sin errores, pero mas fáciles de localizar
3
¿Porque nuestro software sufre degeneración?
Hay que cumplir con la fecha de entrega comprometida, es LA PRIORIDAD NUMERO UNO!
4
...
Difícil de hacer una estimación confiable
Difícil de cumplir con lo planeado
Aparecen los “bugs” etc.
Difícil de solucionar los “bugs”
Aparecen “Expertos” o “Dueños” de código
!Es un circulo vicioso¡

El proyecto adquiere “deuda tecnologica”
5
¿Porque pasa esto?
Software es complejo
Hay diferentes modos de manejar la complejidad: proceso, encapsulación, componentes, los
“frameworks”, reutilización etc.
Sin embargo, hay que empezar manejando complejidad en el nivel de código.
 Antes, nuestras prioridades eran tener un código rápido, pequeño (ocupa poca memoria),
optimizado, utilizando los algoritmos mas eficaces etc...
 Hoy en día el enfoque es en código como tal, este código tiene que ser simple
6
¿Cómo es un código simple?
Funciona bien
Comunica lo que esta haciendo
No tiene duplicación
Tiene un número menos posible de clases y métodos
7
¿Cuales son los beneficios?
El código es mas fácil de cambiar, evolucionar o arreglar
Es mas fácil desarrollar de un modo iterativo e
incrementando
El código es mas fácil de leer (entender)
Es mas fácil hacerlo bien desde la primera, asi estamos
programando mas rápido
8
¿Cómo en esto nos puede apoyar la
Refactorización?
Refactorizar significa cambiar el código internamente sin alterar su
funcionalidad externa. En general, con motivos de mejorar el diseño
y obtener un código mas simple.
Refactorización enseña técnicas para descubrir el código de mala

calidad y técnicas para cambiarlo.
9
Identificar puntos débiles de código
Es difícil definir si código es malo o bueno, o cuando
deberíamos cambiarlo
Difícil de imponer las métricas
Por eso estamos hablando de los “Olores malos” en el
código (“Bad Smells” - Kent Beck)
10
Ciclo de la refactorización
Cómo
Enfoque formalizado
Técnicas o herramientas independientes
Muchos IDE ayudan a la refactorización
Utilizaremos un enfoque OO -- Java
Alcance de la refactorización
QUÉ ES QUÉ NO ES
Aplicación de un cto de técnicas No es depurar errores

Mejora del código ya funcional No es añadir nueva
funcionalidad
Intensificar la mantenibilidad y
la extensibilidad No es mejorar el rendimiento
Trabajar para el futuro No es hacer el código mas
bonito
Caja de herramientas.
Técnicas de refactorización
Cto de técnicas pequeñas, con nombre y dirigidas a un aspecto
concreto
Si un proceso definido
Es un proceso inteligente dirigido por el “olfato” del desarrollador
Entre 75 y 100 técnicas de mas generales a específicas
Unas 30 son las mas empleadas
Ej: Método que crece
Cómo refactorizar
Identificar código con mal aspecto. --- Code smells
Es tarea de experto
Ayudada por las checklist que vamos a ver
Ejemplos
Código repetido
Métodos largos --- todos los métodos de 50 líneas y uno de 200
Demasiados comentarios
Orígenes de la refactorización
Martin Fowler – Padre de la refactorización
Refactoring Improving the design of existing Code
Catalogo de técnicas de refactorización
http://martinfowler.com/bliki/CodeSmell.html
http://refactoring.com/
Code Smells
Código duplicado Muchos comentarios
Métodos largos Grupos de datos
Clases grandes Jerarquías de herencia paralelas
Lista de parámetros larga
Intimidad inapropiada
Cambio divergente – clase propensa a cambios
…..
Cirugía con escopeta- Cualquier pequeño cambio
implica tocar muchas clases
Envidia de funcionalidades
Los switch
Las temporales
Tipos de refactorizaciones
Categorías no disjuntas, son clasificaciones para la mejor
comprensión
A nivel de método
El nombre es correcto? Hay código duplicado? Los parámetros tienen sentido?
Hay muchas variables temporales? Es mejor partir el código?...
A nivel de clase
Este método debe estar en esta clases? Hay muchos métodos parecidos
A nivel de comunicación entre clases
La clase A está usando métodos de la Clase B? porque lo hace?
Técnicas de
refactorización
REEMPLAZAR NÚMERO
Reemplazar Numero Mágico con
Constante Simbólica
Un literal tiene significado especial
Una de las enfermedades mas antiguas en computación
Si en un momento hay que cambiar el numero, el esfuerzo necesario
puede ser enorme
Código difícil de leer
20
double energiaPotencial(double masa, double altura){
return masa * 9.81 * altura;
}
double energiaPotencial(double masa, double altura){

return masa * INTENSIDAD_DE_GRAVEDAD * altura;
}
static const double INTENSIDAD_DE_GRAVEDAD = 9.81;
21
Técnicas de
refactorización
EXTRAER MÉTODO
Extraer método
Ver un cto de líneas de código que tienen una cohesión y se pueden extraer
Función autónoma, cohesiva
y corta:
IMPRIMIR CABECERA FACTURA
Haremos lo mismo que el caso anterior?
El parámetro debe ser tipo Order o tipo Cliente?
Extracción de método
Refactorización en línea
Justo lo contrario de lo anterior
No se utiliza en otra clase

Usar sólo si el método no aporta
ninguna funcionalidad adicional
Técnicas de
refactorización
TEMPORALES
Eliminación de temporales. Con consultas
Escanear el código para buscar donde se utiliza

Puede utilizarse “final”
Eliminación de temporales. Con consultas
Eliminación de temporales en línea
Eliminación de temporales en línea
Refactorización que añade temporales
Divide variable temporal
Introduce una variable explicativa
Quita asignaciones a parámetros
Divide variable temporal
Divide una variable temporal
CONFUSO
Divide una variable temporal
Introducir variable explicativa
Sentencia excesivamente compleja
Quitar asignaciones a parámetros
Muy dependiente del lenguaje y del tipo de datos
Evitar impactos no deseados
Quitar asignaciones a parámetros
Técnicas de
refactorización
MOVER MÉTODOS
A nivel de clases. Moviendo métodos
¿Cuándo se cambia? y a donde?.
Maneja datos de otra clase
ENVIDIA DE CARACTERÍSTICAS
Mover método
1. Revisar método. Donde y quien lo usa. Pensar el nombre
2. Comprobar jerarquía de clases. Subclases y superclases.
3. Crear el método y renombrarlo
4. Copiar el código
5. Reemplazar las llamadas originales
6. Se puede hacer un movimiento parcial. Dejar el método allí y copiar en otra clase
Mover método
De que clase usa más datos?. Ojo siempre que los campos estén en
el sitio correcto
Y si no hay clase donde llevarlo pero no está en su sitio. Crear clase
Cuando hay mal aspecto:

Envidia de características
Intimidad inapropiada
Cirugía con escopeta. No matar moscas a cañonazos. Buscar una agrupación
diferente creando una clase que de servicios a las otras.
Técnicas de
refactorización
EXTRAER CLASES
Extraer clases
Conforme el proyecto crece
Crecen las clases y se les asignan funciones inapropiadas.
Clases muy grandes
Extraer clases
Refactorizar clases en línea
Pueden quedar clases casi vacías cuando movemos métodos
Es poco habitual
Técnicas de
refactorización
MEJORAR CONDICIONALES
Condicionales más fáciles de leer
Descomponer condicional
Consolidar expresión condicional
Consolidar fragmentos duplicados condicionales
Reemplazar con polimorfismo

Descomponer condicional
Es fácil de ver hoy pero que pasará dentro de dos meses?

Consolidación de expresión condicional
Consolidar fragmentos duplicados condicionales
Se parecen mucho pero no son iguales
Reemplazar condicional con polimorfismo
ERROR
Reemplazar tipos con subclases
Cuando no tenemos jerarquías de clases
Ojo con las condiciones múltiples
Enumeraciones
Condiciones múltiples
Campos de tipo
Comportamiento
Basado en tipo
Extraer subclases
Técnicas de
refactorización
MOVER CAMPOS
Mover Campos
Y que pasa si estos métodos usan también el campoUno ?
Movemos el campo
Añadir accesores, gets y sets --- Refactorización de encapsulación de campos

Usar los métodos de acceso --- Refactorización de campo auto-encapsulado
Cúmulos o grupos de datos
Datos que están junto y siempre juntos
Estos cúmulos tienen mal aspecto
Se extraen igual que clases y campos
Refactorización de preservación del objeto entero

Refactorización de introducir objeto parámetro
Preservar el objeto entero
Temporales en línea
Menos número de parámetros

Introducir objeto parámetro
Introducir objeto parámetro
Facilita la incorporación de otros

posibles métodos que aparezcan
como rotar o escalar
Técnicas de
refactorización
OTROS PROBLEMAS
Simplificación de llamadas a métodos
Renombrar métodos
◦ Métodos con otras responsabilidades. Evolución de los métodos
◦ Difícil de encontrar el nombre- Pensar en los comentarios
Añadir o quitar parámetros

◦ Preferencia por listas breves – menos es mas
Parametrizar métodos
Reemplazar parámetro con métodos
Separar la petición de modificador
Parametrizar métodos
Reemplazar parámetro con métodos
Separar la petición del modificador
Técnicas de
refactorización
SUBIR O BAJARA MÉTODOS Y CAMPOS ( PUSH Y POP)
Subir campo o método
Por evolución del código
Mismo concepto
Bajada de método y campo
Solo una clase usa el método o el campo
Pero es difícil de ver en el código
Refinar jerarquías de clases
Extracción de superclase
Extracción de subclase
Colapsado de la jerarquía justo lo contrario
Extracción de superclase
Abstract
Extraer a clase – Subir campo – Subir método

Extraer subclase
Se usan partes de la clase
Unos objetos usan una parte otros otra --- extraer clase
Unos objetos usan una parte y otros el todo --- extraer subclase
ProblemaATM solo es útil para las cuentas corrientes. Se crea una subclase
que recoja este comportamiento
Colapsado de la jerarquía
Tira la subclase de la superclase o al revés no siempre es la superclase
Tipos de refactorizaciones
Categorías no disjuntas, son clasificaciones para la mejor
comprensión
A nivel de método
El nombre es correcto? Hay código duplicado? Los parámetros tienen sentido?
Hay muchas variables temporales? Es mejor partir el código?...
A nivel de clase
Este método debe estar en esta clases? Hay muchos métodos parecidos
A nivel de comunicación entre clases

La clase A está usando métodos de la Clase B? porque lo hace?
Técnicas de
refactorización
Esconder al delegado
Cadenas de peticiones
Clase que sólo pasa información
Quitar el hombre de enmedio

No se quita la clase. Tendrá asociada otra funcionalidad
Refactorización a gran escala, Diseño
Tener una aplicación no OO en un lenguaje OO
Clases grandes – Clases Dios --- Datos tontos
Dominio y presentación separados MVC. MVVM

Refactorizacion

Cargado por

Copyright:

Formatos disponibles

Refactorizacion

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Refactorizacion

Cargado por

Copyright:

Formatos disponibles

Refactorización

MEJORANDO EL DISEÑO DEL CÓDIGO EXISTENTE

!Es un circulo vicioso¡

Refactorización enseña técnicas para descubrir el código de mala

Aplicación de un cto de técnicas No es depurar errores

double energiaPotencial(double masa, double altura){

No se utiliza en otra clase

Escanear el código para buscar donde se utiliza

Cuando hay mal aspecto:

Reemplazar con polimorfismo

Es fácil de ver hoy pero que pasará dentro de dos meses?

Añadir accesores, gets y sets --- Refactorización de encapsulación de campos

Refactorización de preservación del objeto entero

Menos número de parámetros

Facilita la incorporación de otros

Añadir o quitar parámetros

Por evolución del código

Extraer a clase – Subir campo – Subir método

A nivel de comunicación entre clases

Quitar el hombre de enmedio

También podría gustarte