¿Por donde empiezas a refactorizar una vieja aplicación de codigo legado?
Lo primero en mi opinión es tratar de escribir tests automáticos de algún tipo,
que nos ayuden a asegurar que no rompemos funcionalidad. Lo normal es que sean
tests de extremo a extremo (tests de sistema). Sin embargo, el código puede
ser tan duro que escribir tests es casi imposible. Por eso tenemos que
contar con el respaldo de un equipo de QA que tenga un buen conocimiento
de la aplicación y de su dominio. Una vez tenemos tests y el apoyo
del equipo de QA, ¿por dónde empezamos a refactorizar?
Eric Evans dice lo siguiente en su libro, Domain Driven Design:
En la comunidad XP las respuestas suelen ser las siguientes:
1. Simplemente empieza por donde sea, ya que todo tiene que refactorizarse
2. Empieza por aquel lugar que está causando más problemas o molestias. Refactoriza lo que vayas necesitando para completar la tarea que estas desarrollando.
No me quedo con ninguna de estas. La primera no es práctica excepto en unos pocos proyectos en los que todos los desarrolladores del equipo tienen un nivel muy alto. La segunda tiende a dar rodeos, ocupándose de síntomas pero sin atacar a la raíz de los problemas. Al final el código va quedando cada vez más difícil de refactorizar.
Como alternativas Eric propone:
1. En un refactoring guiado por penurias (pain-driven), miras si la raíz tiene que ver con el núcleo del dominio (CORE DOMAIN) o con alguna de sus relaciones. Si la tiene, entonces cruzas los dedos y arreglas eso antes que nada.
2. Si te puedes permitir el lujo de refactorizar libremente, primero te centras
en un refactoring del núcleo del dominio, mejorando sus relaciones y facilitando
el soporte para conectar subdominios genéricos.