Crónicas del Buen Programador: ¡A Refactorizar!

A medida que un programa evoluciona será necesario re-pensar decisiones que tomaste anteriormente y volver a trabajar en porciones de código ya escritas. Este proceso es perfectamente natural, el código necesita evolucionar, no es una cosa estática.

Desafortunadamente, la metáfora más común aplicada al desarrollo de software es la de “construcción” lo cual nos asocia a los desarrolladores con cosas similares a las que hacen los arquitectos (de edificios), hacer un plano, cavar las fundaciones, hacer el edificio, que la gente se mude y viva feliz para siempre junto con un mantenimiento aquí y allá.

El software no funciona de este modo, en vez de “construcción” el software es más como “jardinería”, es mucho más orgánico que el concreto. Puedes plantar muchas plantas en un jardín de acuerdo a un plan inicial pero dadas las condiciones algunas plantas morirán y otras vivirán sin problemas. Te tocará entonces mover plantas, cortar unas muy largas, traer plantas nuevas, acomodar la tierra, regar, proteger algunas partes del sol, otras de la lluvia, arrancarás yerbas no deseadas y utilizarás fertilizantes, constantemente monitoreando la salud de tu jardín.

Re-escribir, re-organizar y re-diseñar la arquitectura de tu código es lo que se le conoce en forma colectiva como “Refactorización”.

¿Cuándo debo refactorizar?

Cuando te encuentras trancado porque el código no quiere funcionar como debería, o notas un par de cosas que deberían ser una sola, o cualquier cosa que te parece que por algún motivo está “mal”, no dudes en cambiarlo, no hay mejor momento que el presente. Cualquier cantidad de cosas pueden calificar para hacer refactorización:

Duplicación: Principio DRY (No Te Repitas) en acción.

Diseño no ortogonal: Encontraste dos componentes que pudieran ser independientes.

Conocimiento vencido: Las cosas cambian, los requerimientos se mueven y tu conocimiento de los problemas puede incrementar, lo cual puede crear oportunidad de resolver situaciones de mejores formas, el código debe estar al día.

Desempeño: Necesitas mover funcionalidad de un area del sistema para mejorar desempeño.

Complicaciones del Mundo Real

Vas a tu jefe, o tu cliente y le dices… “Este código funciona, pero necesito una semana para hacer refactorización”, ¿qué crees que va a decir tu jefe si no hay tiempo?

La falta de tiempo siempre es la mejor excusa para no hacer refactorización. Pero esta excusa no debería sostenerse, si no haces la refactorización necesaria ahora puedes estar seguro de que habrán mayores inversiones de tiempo en el futuro para arreglar las consecuencias cuando hayan más dependencias afectadas, que haya más tiempo en el futuro es difícil.

Una forma de explicarle a tu jefe o cliente el problema, es con una analogía médica. Diles que es como un cancer, que es mejor sacar el tumor mientras esta más pequeño que cuando se distribuya por todo el sistema. Probablemente la imagen mental que esto crea será lo suficiente para que te den la aprobación.

Refactoriza Temprano, Refactoriza con Frecuencia

No trates de refactorizar y agregar funcionalidad al mismo tiempo.

Asegúrate de tener pruebas unitarias antes de refactorizar, cosa que al terminar puedas correr las pruebas y ver si rompiste algo.

Refactoriza por pasos. Mueve un campo de una clase a la otra, une metodos similares en una super clase.

Si tienes herramientas con funcionalidades para automatizar refactor, aprende a utilizarlas. En mi caso utilizo Eclipse en proyectos con cientos o miles de clases y renombrar funciones, mover clases, extraer métodos y otras prácticas se hacen sumamente rápido gracias al editor.

[ad#Google Adsense-468x15ContentLinkunit]

Sobre el Autor

Angel León (aka Gubatron) es un Ingeniero de Software Venezolano (UCAB) que ha desarrollado desde sencillos sistemas con bases de datos relacionales, servicios webs distribuidos para millones de visitantes mensuales, software p2p de uso masivo, hasta aplicaciones para dispositivos mobiles, todo esto empleando gran variedad tecnologías abiertas (Linux, Android, Java, Python, PHP, C++, Javascript).

Estas crónicas son inspiradas en el libro “The Pragmatic Programmer” (un libro que debería ser un texto obligatorio en todo curso de Ingeniería de Software) junto con las experiencias de Angel León durante los últimos 8 años desarrollando software en Venezuela y los Estados Unidos.