metodologia XP

31

Refactoring: otra
práctica de la
Programación eXtrema

EXTREME PROGRAMMING

Hackers & Developers Magazine – Año 0, Número 6

En ediciones anteriores estuvimos hablando de TDD,
sus beneficios y forma de implementarlo. En esta
edición, nos concentraremos en el Refactoring: otra
de las prácticas técnicas sugeridas por eXtreme
Programming.

Escrito por: Eugenia Bahit (ArquitectaGLAMP & Agile Coach)
Eugenia es Arquitecta de Software, docente instructora de tecnologías
GLAMP (GNU/Linux, Apache, MySQL, Python y PHP) y Agile coach (UTN)
especializada en Scrum y eXtreme Programming. Miembro de la Free
Software Foundation e integrante del equipo de Debian Hackers.
Webs:
Cursos de programación a Distancia: www.cursosdeprogramacionadistancia.com
Web personal:www.eugeniabahit.com
Redes sociales:
Twitter / Identi.ca: @eugeniabahit

R

efactoring, es una de las prácticas técnicas sugeridas por XP 8 que consiste en
mejorar el código fuente de una aplicación, sin que dichas modificaciones, afecten
el comportamiento externo del sistema.

Cuando se programa con TDD 9 se hace imposible evitar refactorizar el código fuente ya
que de los propios test deriva estanecesidad. Sin embargo, las técnicas de Refactoring
pueden implementarse como una buena práctica de programación aunque no se
programe con TDD.

Existen diferentes tipos de refactorizaciones que pueden ser necesarias implementar al
código de nuestra aplicación. Cada tipo, representa una técnica diferente de
refactorización. Por ejemplo, eliminar código redundante requiere de una técnicadiferente a dividir los algoritmos de un método para crear métodos derivados.

8
9

Extreme Programming
Test Driven Development (Desarrollo guiado por pruebas)

Un problema no es un error...
Antes de continuar, habría que diferenciar el término “problema” de la palabra “error”,
para no generar confusiones.
El error en sí, es una falla en el código fuente que impide el correctocomportamiento
del sistema. Mientras que el problema, puede definirse como “algo que huele mal en el
código fuente”10 pero sin embargo, no impide el correcto funcionamiento de la
aplicación.
Los problemas que se pueden presentar en el código fuente de una aplicación,
dependen de muchísimos factores y en gran parte de los casos, encuentran una relación
directa con el paradigma de programación empleadoasí como en el lenguaje que se
utilice.
Si se intentara abarcar todos los problemas posibles, la lista podría tornarse infinita,
tediosa y hasta inútil o incluso confusa. Es por ello, que solo abarcaremos los problemas
más frecuentes que puedan considerarse generales con independencia del lenguaje en
que se programe. Trataré de incluir ejemplos tanto en Python como en PHP para hacer
el temamás general.

La regla
En el mundo del Refactoring, haciendo una analogía con el béisbol, suele utilizarse la
regla “Tres Strikes11 y ¡refactoriza!”. Esta regla puede traducirse como:

La primera vez que hagas algo, solo hazlo. La segunda vez
que hagas algo similar, notarás que estás duplicando código,
pero lo harás de todas formas. La tercera vez que te enfrentes
al mismo caso,refactoriza.

Cuando se está programando una aplicación con TDD, como hemos visto en ediciones
anteriores, el proceso de desarrollo se está dividiendo en dos acciones concretas:
programar y refactorizar. Esto es, a medida que vamos creando nuevos métodos, vamos
refactorizando el código para eliminar redundancias y en definitiva, hacer el código -del
test- más legible y así obtener un mejor rendimiento.Pero no estamos refactorizando el
SUT constantemente (aunque sí lo refactorizamos), puesto que éste, tiene un momento
y lugar para ser refactorizado.

10 Kent Beck, uno de los creadores de eXtreme Programming, es quien introdujo el término “bad smells” (malos olores) para
referirse de manera global, a aquellas expresiones y algoritmos poco claros que generan confusión en el código fuente...