Cuando estamos desarrollando código muchas veces viene a nuestra cabeza refactorizar el código, y claro que lo entiendo, yo pequé por querer refactorizar todo el código que escribía, siempre pensaba que podía mejorarse, y como algunos ya saben, en mi opinión, refactorizar el código es algo que debiese postergarse.
Antes de continuar, puedes leer este post o ver y escuchar esta información en formato de video en nuestro canal de Youtube, te dejamos el link por si prefieres este formato. 😃 👍
Hola mundo, y bienvenidos a este post. La refactorización de código, si se utiliza bien, puede ayudarnos a mejorar la salud de nuestro código, pero la mayoría de las veces lo único que hará será hacernos perder tiempo. Y el factor social del refactor es algo que nosotros pocas veces consideramos antes de realizarlo. Pero…
¿Que es la refactorización de código?
En pocas palabras, la refactorización de código es el proceso de editar, limpiar y simplificar el código escrito con anterioridad sin cambiar la funcionalidad que este tiene.
Refactorizar puede mejorar la legibilidad y puede hacer el proceso de pruebas y depuración del código más eficiente. Este proceso no contempla corregir errores, pero pueden corregirse en una etapa posterior. Es muy importante mantener estas dos tareas separadas, ya que se debe verificar que el código que se refactorizó funciona bien antes de editar su lógica.
¿Qué ocurre con la refactorización que se hace cuando se practica TDD o test driven development?
Cuando se realiza la práctica de desarrollo TDD, lo primero que se hace es escribir las pruebas y estas pruebas deben fallar, luego se escribe el código para que estas pruebas pasen y luego se refactoriza el código para que este cumpla con los estándares de calidad del código. Esta refactorización no contempla cambios a nivel estructural y el alcance es solo a nivel de la funcionalidad que estás implementando.
Este tipo de refactorización, nosotros en este post no la contemplaremos, ya que nos enfocaremos en los cambios estructurales de nuestra aplicación cuando hacemos refactorización, que vendría siendo los otros casos.
¿Cuándo debemos considerar hacer una refactorización?
El mejor momento para considerar realizar una refactorización es antes de implementar una funcionalidad. Y para eso podemos utilizar varios sistemas para evaluar la refactorización. Siendo la primera la regla de tres. Esta regla dice lo siguiente, impleméntalo una vez, impleméntalo dos veces y a la tercera refactoriza.
Con este sistema lo que se está midiendo es si tú has tenido que implementar una funcionalidad más de una vez, de hecho al menos dos veces, y es para implementar el patrón DRY, el problema que tiene esta regla es que cuando trabajas con equipos de desarrollo lo más probable es que ellos también hayan realizado la misma implementación. Por lo que perfectamente podría estar esta implementación más de 3 veces. Y que tú tengas que estar activamente buscando estas implementaciones a lo largo de una base de código para ver si se repite 3 veces, es contraproducente. Por lo que la regla de 3 solo aplica si tú estás trabajando solo en un proyecto o con equipos muy pequeños donde puedas ver las implementaciones que ellos están realizando mediante los pull request y así ver si se puede aplicar la regla de 3. Por lo que la regla de 3 en lo personal lo considero una utopía. Si trabajas solo funciona bien, pero lo más probable es que vayas a trabajar en equipo.
La siguiente evaluación que puedes hacer para ver si debes realizar una refactorización es basada netamente en costos operacionales:
- La refactorización que haré, ¿hará que la funcionalidad que vaya a implementar se implemente más rápido con la refactorización incluida?
- ¿La refactorización que haré me permitirá corregir errores más rápido?
- Errores que son triviales, ¿están tomando días en resolverse por la complejidad del código?, ¿sería mejor una re-implementación en este caso?
- ¿Tu equipo entenderá la refactorización?
- ¿Esta refactorización hará que consigas más clientes?
- La refactorización, ¿mejorará el rendimiento de la aplicación de una manera notable? Y en este caso, si el rendimiento no es un problema, esta opción debiese descartarse.
Si la respuesta a todas esas preguntas es no, entonces lo mejor sería no refactorizar. Hacer un código bello o más legible en su mayoría es subjetivo. Hay desarrolladores que prefieren código componible, otros que prefieren código imperativo. Otros que prefieren que no toques implementaciones que ya existen. Y cuando desarrollas en equipo, te vas a topar con todos ellos.
Desde una perspectiva técnica una refactorización es muchas veces saludable cuando trabajamos con equipos pequeños o nosotros solos, pero en equipos grandes existen muchas preferencias y formas de ver los problemas de manera distinta. Si la cultura laboral en la que te encuentras tiene bien definida la perspectiva técnica de cuándo refactorizar, cómo hacerlo y cuándo, en ese caso es saludable hacer refactorizaciones. Pero con preferencias distintas y equipos grandes, una refactorización podría retrasar tu trabajo debido a la burocracia que conlleva esta.
En pocas palabras, la refactorización es buena, pero en contadas ocasiones, es mejor dejar que el código crezca orgánicamente y luego de un tiempo, si empiezan a aparecer problemas como que disminuye la velocidad del equipo, baja el rendimiento y tu equipo está de acuerdo que una refactorización podría solucionar el problema, en ese caso deberías considerarla.
Pero algo muy importante, yo NO les estoy diciendo que no hay que refactorizar. Lo que les estoy diciendo que de hacerse deben existir razones de peso, y que el código se vea feo no es una razón de peso. Y la mejor forma de saberlo es haciéndote esas preguntas, o mejor aún preguntárselas a otro desarrollador.
Y en el caso que tengas que refactorizar, debes asegurarte primero de lo siguiente:
Requisitos sugeridos para refactorizar
El código que vas a refactorizar, ¿tiene pruebas automáticas implementadas? ¿Y estas pruebas tienen una cobertura del 100% de los casos?
Estas dos preguntas son sumamente importantes, ya que las pruebas automáticas te dirán si rompiste algo, y si no tiene una cobertura del 100% en ese caso debes implementar las pruebas automáticas primero. Lo peor que podría pasar es que en la refactorización te saltes esos casos bordes que no están siendo capturados por las pruebas, y de esta manera romper producción.
Así que en ese caso implementar las pruebas primero, y en un pull request separado realizar la refactorización, luego de realizados esos dos pasos, ahi recién puedes implementar la funcionalidad que querías o realizar el cambio que debías. Antes no.
Y esto ha sido todo de este post, si te ha encantado, ¡golpea al botón de me gusta!, dejanos un comentario, y visita nuestra Academia Hola Mundo, donde encontrarás todos los cursos para formarte como un desarrollador o desarrolladora.
Y para no perderte nada, no olvides suscribirte a este blog, seguirnos en todas las redes como Youtube, Twitter e Instagram, y por último, te invitamos a escuchar nuestra música «Hola Beats«, diseñada para ayudarte a concentrarte y acompañarte en tu aprendizaje o trabajo, la puedes encontrar en Spotify, Apple Music, Amazon Music, Youtube Music y Deezer.
¡Hasta la próxima!, y chao mundo
Deja un comentario