Capitulo 2 de Refactoring

1. CAPITULO 2:
PRINCIPIOS EN REFACTORIZACIÓN

2. DEFINIENDO REFACTORIZACIÓN
Hay 2 posibles significados que
dependen del contexto.
• Sustantivo: Un cambio en la estructura
interna del software para hacerlo más
fácil de entender y más barato de
modificar sin cambiar su
comportamiento observable.
• Verbo: Para reestructurar software
aplicando una serie de
refactorizaciones sin cambiar su
comportamiento observable.

3. Refactorizar no es lo mismo que Optimizar.
• Refactorizar: Consiste en modificar el código de manera que sea mas fácil de leer
y entender sin cambiar su funcionalidad.
• Optimizar: Modificar el código de tal manera que este se ejecute de una manera
mas eficiente y rápida sin cambiar su funcionalidad.

4. La metáfora de “Los dos Sombreros” de Kent Beck.
• Cuando desarrollas un software y utilizas refactorización, el tiempo se divide en 2
actividades: Agregar funciones y Refactorizar.

5. ¿POR QUÉ DEBERÍAS REFACTORIZAR?
• Refactorizar mejora el diseño del software: Lleva mas tiempo hacer algo con un
código diseñado de manera pobre debido a los cambios que se le han hecho. Es
posible que se repitan accione en varias partes.
• Refactorizar hace mas fácil el entender el código: Cuando alguien esta creando
código, esa persona es posible que lo haga de cierta manera en que el es el único
que entiende ese código. Es posible que en el futuro, alguien diferente necesite
hacerle cambios.

6. REFACTORIZAR TE AYUDA A ENCONTRAR ERRORES
(BUGS)
• Entender el código de manera
mas fácil también ayuda a
encontrar bugs de manera mas
rápida.
• Al refactorizar el código, se
trabaja en entender el código
para limpiarlo. Si se entiende
todas las partes del código, se
puede ver partes que no están
correctas.

7. • Refactorizar te ayuda a desarrollar código mas rápido.
• Refactorizar ayuda a mejorar el diseño, mejorar la lectura del codigo, encontrar
bugs en el código, mejora la calidad. ¿Todo esto hace que tome mas tiempo
desarrollar codigo?
• Sin un buen diseño, se puede avanzar rápidamente al inicio, pero con el paso del
tiempo, el no limpiar el código dificulta su mantenimiento y hace mas lento el
proceso de desarrollo.

8. ¿CUÁNDO DEBERÍAS
REFACTORIZAR?
• Refactorizar no es algo que se tenga programado para
hacer en una fecha especifica.
• Refactorizar es algo que se hace todo el tiempo de a
pequeños ratos.
• Tu no decides cuando refactorizar, lo haces porque
quieres hacer algo mas.

9. • Refactoriza cuando agregues una función: Es el momento mas común para
refactorizar. Lo haces para entender el código que necesitas cambiar para
agregarle la nueva parte.
• Refactoriza para arreglar errores: Cuando se refactoriza un código para
entenderlo mejor, es muy posible encontrar errores.
• Refactoriza a medida que hagas una revisión de código: El refactorizar durante la
revisión de un código ayuda a pasar conocimientos de personas mas
conocedoras a otras mas jóvenes. Ayuda a proponer nuevas ideas para mejorar.

10. ¿QUÉ LE DIGO A
MI GERENTE?
• Refactorizar mejora la
calidad.
• Si es mas importante
cumplir horarios que la
calidad: No digas nada,
solo hazlo.

11. PROBLEMAS CON LA REFACTORIZACION
• Es difícil decir cuando es mas perjudicial hacer refactorización que no hacerla, pero
hay algunos casos claros.
• Bases de datos: Las aplicaciones de varios negocios están construidas alrededor del
esquema de las bases de datos que la soportan. Incluso si se ha realizado el esquema
de manera cuidadosa para minimizar la dependencia, cualquier cambio llevaría a una
migración de datos.
• Cambiar interfaces: Refactorizar puede alterar la interface. Renombrar un método no
es problema mientras se tenga acceso a todo el código que llame a ese método. El
problema se presenta cuando el método esta siendo utilizado por código que no se
puede acceder, como es el caso de una interface publicada.

12. ¿Cuando no refactorizar?
• No se debe refactorizar cuando el
código esta tan desordenado que seria
mas eficiente el reescribir todo desde
cero.
• Un claro ejemplo de cuando reescribir
es cuando el código simplemente no
funciona.
• Otro momento en el que se sugiere no
refactorizar es cuando se acerca la
fecha de entrega.

13. REFACTORIZACIÓN Y DISEÑO
• Escribir código y después realizar la refactorización es una froma que le funciona
a muchos, y gracias a esto, surgen muchos buenos diseño de software.
• La manera mas recomendada es primero pensar el diseño del código, arreglar los
problemas que se presentan a medida que se desarrolla y hacer una
refactorización al final.
• Al diseñar primero es posible tener una solución pensada, pero es posible lograr
una solución igual de eficiente después de refactorizar que no fue la original.

14. REFACTORIZAR Y DESEMPEÑO
• El refactorizar un software y hacerlo mas entendible puede ocasionar que este se
desempeñe de manera mas lenta. Mucha veces se ignora esto con esperanzas de que
un hardware potente solucione este problema.
• Puede que el software corra mas lento por esto, pero también o hace mas manejable
para afinaciones.
• El objetivo es refactorizarlo para que se pueda afinar después y luego afinarlo lo mas
posible.
• Si se pone a la tare de optimizar todo el código por igual, el 90% de estas
optimizaciones pueden ser un desperdicio ya que partes del código no se
implementan mucho.

15. ¿DE DONDE VINO LA REFACTORIZACIÓN?
• No se esta muy seguro de cuando surgió la refactorización, pero ya desde hace
tiempo, los programadores vienen limpiando el código para que sea mas fácil de
manejar.
• 2 de las primeras personas en reconocer la importancia de la refactorización
fueron Ward Cunningham y Kent Beck, quienes trabajaron con Smalltalk.