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 después 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 practicándola.
Una de las mejores inversiones que se pueden hacer en él manteniendo 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 dé 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?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
