La refactorización es un proceso sistemático de mejora del código sin crear nuevas funcionalidades. La refactorización transforma el desorden en código limpio y diseño simple.
Refactoring.guru
Hoy quiero hablarlos de uno de los factores que nos retrasan en la programación a los que hice referencia en un post previo donde analicé la parte no tan bonita de los side projects. Vamos a profundizar en el “problema” o la necesidad de refactorizar nuestro código cada cierto tiempo y cómo puede afectar al ciclo normal de desarrollo.
El desarrollo mobile, y android en particular, es un entorno cambiante en muchos sentidos. Para empezar, aproximadamente cada año teníamos una versión con cambios interesantes o incluso obligatorios. A partir de este año además, tenemos dos versiones cada año por lo que el ritmo aumenta considerablemente. Por otro lado, la comunidad de android siempre ha sido muy activa a la hora de crear o adaptar patrones de diseño o arquitecturas de cara a mejorar la calidad de nuestro código. Si a esto le sumamos las diferentes librerías externas que usamos en los proyectos con sus respectivos cambios de versiones, la combinatoria se vuelve curiosa cuanto menos.
En mi caso, como buen desarrollador android, cada vez que aprendía una nueva arquitectura o un nuevo framework que mejoraba lo existente, intentaba aplicarlo a los proyectos que tenía abiertos. Este proceso, en la mayoría de los casos, no es nada trivial y conlleva un tiempo considerable.
Si pensamos desde la perspectiva de producto, la que tienen las empresas, estaba invirtiendo un tiempo que no estaba produciendo ningún cambio de cara a los usuarios finales. Querer aplicar las novedades en proyectos existentes es una actividad muy buena ya que nos prepara para las posibles dificultades que conlleva esa base de código en particular pero tenemos que ser conscientes de que muchas veces no nos aporta nada a nivel de funcionalidad.
Entonces, ¿no debo refactorizar nunca el código? Nada más lejos de la realidad. Refactorizar el código de cara a mejorar la arquitectura, la calidad o la sencillez, es una actividad completamente necesaria de cara a que nuestro trabajo futuro en ese proyecto sea más fácil. Si alguna vez habéis vuelto a un proyecto antiguo, imagino que habréis tenido la misma sensación que yo al ver el código: el mismo programador/a, cambia mucho su forma de escribir código a lo largo de los años. El cambio suele ser bastante tedioso y tenemos que invertir un tiempo simplemente en ver cómo van las cosas en ese proyecto.
Si funciona, no lo toques
¿Dónde poner el límite entonces? Si no refactorizar está mal y refactorizar todo el rato nos retrasa el desarrollo, la respuesta obvia está en el medio. Si seguimos una estrategia de refactorización continua pero gradual, la calidad de nuestra código aumentará pero podremos seguir avanzando en las funcionalidades necesarias. Una norma no escrita de la ingeniería es “si funciona , no lo toques” y aunque no sea siempre así, puede darnos una idea de cómo gestionar las refactorizaciones. Si tenemos un código abandonado, que funciona perfectamente y no va a ser cambiado ni extendido en el futuro, no es necesario que use las últimas librerías y arquitecturas del momento. Por el contrario, si tenemos una parte importante de nuestra app que está muy acoplada con el resto de funcionalidades y es muy probable que tengamos que cambiarla en el futuro, es un buen candidato de cara a una refactorización para que los cambios dejen de afectar al resto del proyecto.
Refactorizar es un arte. Todo código es mejorable de alguna forma. Siempre podemos sacar una clase más, extraer funciones nuevas, mejorar el performance del algoritmo, abstraerlo para evitar dependencias, etc. La lista es interminable. Nuestro trabajo como desarrolladores es balancear la refactorización para que mejore la calidad del código pero elegir cuidadosamente cuando y donde hacerlo.
Nos vemos!