leanmind logo leanmind text logo

Artículos

Por Carlos Bléel 24/08/2019

Los múltiples beneficios del refactoring matutino

Refactoring book cover

La técnica de Refactoring consiste en simplificar el código sin alterar su funcionalidad. Simplificar significa sobre todo hacerlo más intuitivo y fácil de entender para los futuros lectos del código. La mejora del código debe hacerse a diario, cada pocos minutos, cada pocas horas, conforme se está añadiendo código. Lo primero es que el código funcione, que pase los tests y después es importante volver a leer el código que hemos escrito por si podemos hacer pequeñas simplificaciones en poco tiempo.

Cuando no se refactoriza a diario, la complejidad va aumentando y cada vez cuesta más poder cambiar el código. Así que se va posponiendo el refactor y la complejidad aumentando en un círculo vicioso. Hasta que llega el día en que los developers piden reescribir el código por completo, tirar todo lo que hay a la basura y empezar de nuevo. Refactorizar el código es como mantener limpia la oficina, cuesta poco si se hace a diario y se dejan las cosas colocadas en su sitio despues de usarlas, pero cuesta mucho si la oficina está hecha un desastre. Dan pocas ganas de limpiar una cocina que tiene montañas de platos sucios en el fregadero. Por eso hay personas que cuando se les habla de refactorizar, no piensan en hacer unos pequeños cambios que llevan minutos sino en parar las máquinas durante un tiempo indeterminado (días o semanas), romper el código por varios sitios y reescribir pedazos hasta que vuelva a funcionar, a riesgo de dejar rota funcionalidad. Poco atractiva la técnica de refactoring para los que tienen ese concepto en mente, lógicamente. La técnica de refactoring significa distintas cosas para distintas personas según la experiencia que han tenido practicandola.

Releer el código del día anterior

Una de las mejores inversiones que se pueden hacer en el manteniento del código, consiste en releer el código del día anterior al empezar la jornada de trabajo. Resulta muy curioso que incluso habiendo pasado solo unas horas, habrá días que nos de la impresión de que no fuimos nosotros quien escribió ese código. Habrá código que nos sorprenda, que nos choque. Típicamente lo que nos chocará son:

La idea es dedicar entre 10 y 30 minutos a leer el código y a realizar pequeños ajustes enfocados a simplificar el código. Típicamente los refactors que haremos serán:

Es importante recordar que no se trata de introducir complejidad sino de reducirla. Por ejemplo, el refactor de matutino probablemente no es el mejor momento para partir un componente React grande en varios componentes más pequeños. No es obligatorio hacer cambios cuando leemos el código del día anterior. Si encontramos pedazos de código que nos sorprenden, entonces sí, adelante con mejorarlo. Porque si nos forzamos a cambiar código por cambiar código, seguramente introduzcamos más complejidad y dediquemos más de 30 minutos. No se trata de rizar el rizo. Es más, si tardamos 5 minutos en leer el código y todo parece bien, pues ya está, podemos dar por finalizada la sesión. Sobre todo porque no se trata de esperar hasta el día siguiente para volver a hacer refactor. A las pocas horas o minutos, volveremos a dedicar otros minutos a hacer refactor. O sea que no es la única oportunidad del día de realizar simplificaciones.

Lo que hace especial el comienzo de la jornada, es que nos permitirá ver el código con ojos nuevos, identificando problemas de mantenimiento con poco esfuerzo. Es como hacer review del código de otra persona. Esto es lo interesante.

Llevo practicando unos años la técnica y la recomiendo encarecidamente. Lleva poco tiempo y produce mejoras sustanciales, por eso digo que es una de las mejores formas de dar alta rentabilidad al refactoring.

¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.

Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?