Aprendiendo a refactorizar en JavaScript: consejos y pautas

Pequeñas pautas para encarar la refactorización en JavaScript y sentirse menos perdido. A la hora de refactorizar un código, es más sencillo comenzar con lo que nos parezca más fácil y útil e ir avanzando poco a poco, con tareas y objetivos concretos.

Una función, una tarea

En general, cada función debería encerrar un solo concepto. Es bueno intentar no mezclar diferentes tareas en una misma función.

Dedicar tiempo al nombrado

El nombrado debe ser descriptivo y claro. Cuando leo el nombre de una función, debo hacerme una idea de la funcionalidad que desempeña. Si leo el nombre de la función y me sorprende su interior, lo más seguro es que el nombrado no sea el correcto, bien porque el nombre no es explicativo o bien porque la propia función no es apropiada, por ejemplo, porque desempeña varias tareas.

De la misma manera, si me está costando mucho elegir el nombre de una función, también puede ser una pista de que la propia función no es adecuada (¡o simplemente estamos cansados y necesitamos estirar las piernas!).

Más cerca de las personas que de las máquinas

Uno de los objetivos principales de la refactorización es que el código sea legible y fácil de entender.

Cuando escribimos código, podemos intentar utilizar expresiones de más alto nivel (más abstractas y cercanas a las personas); o expresiones de bajo nivel (más cercano a la máquina y con menos abstracción). A la hora de leer un código, es de gran ayuda que existan determinadas funciones descriptivas y de alto nivel para entender el funcionamiento de la aplicación.

function initGame() {
    showButtonNextQuestion();
    paintQuestion(currentQuestion());
    updateQuestionIndex();
    startCountdown(); 
    prepareAnswersToBeClicked();
    updateScoreboard();
}

En la función anterior, de un solo vistazo podemos hacernos una idea de qué hace la aplicación.

Tampoco hay que llevar el nivel de abstracción al extremo. Hay que aplicarlo con cabeza y simplemente debemos intentar conseguir que quien sea lea nuestro código no tenga que leerse un montón de funciones para entender una funcionalidad concreta.

Variables globales, las justas

Las variables globales deberán ser las imprescindibles, puesto que al no tener un scope local afectan a todo el código y provocan que este sea menos mantenible y más propenso a errores.

Funciones puras

Las funciones puras -aquellas que son independientes porque no dependen de variables exteriores- son más fáciles de mantener porque no tienen efectos secundarios en el resto del código. Por esta razón, a la hora de programar, es una buena idea intentar que las funciones sean puras. Por supuesto, habrá muchos casos que necesitemos otro tipo de funciones y hay que analizar cada situación, pero es bueno tener en mente que las funciones puras ayudan a tener un código más mantenible.

Cuantas menos dependencias, mejor

Seguramente, muchas de nuestras funciones dependen de otras funciones para poder ejecutarse correctamente. Cuando muchas partes de nuestro código dependen de otras partes, es más fácil que algunos métodos afecten a otros sin que lo hayamos previsto o que cualquier cambio futuro sea complejo y laborioso.

Hay que intentar que las funciones sean lo más independientes posibles y limitar la dependencia a lo que consideremos necesario.

Separar presentación y lógica de negocio

Como regla general, es interesante separar la presentación de la lógica de negocio. Por un lado, la parte encargada de “pintar” e interactuar con la interfaz y, por otro, una parte que es más abstracta y que encierra la lógica necesaria para el funcionamiento de la aplicación. En muchos proyectos también se distingue la parte de datos.

Según el tipo de proyecto, querremos separar en mayor o menor medida estas partes. Al menos, es importante no mezclar ambos conceptos en una misma función.

Simetría

Normalmente, es recomendable que las funciones tengan cierta simetría. Por ejemplo, tengo una función que opera con dos variables y una de ellas se declara a través del parámetro de la función y la otra se declara como variable en el scope de la función. Para hacerla más armoniosa, podemos intentar declarar las dos variables en sus parámetros.

Otro ejemplo: en una función escrita con expresiones de alto nivel, es recomendable no introducir una única expresión de bajo nivel. Esto ayuda a su legibilidad.

Por último, lo ideal es refactorizar teniendo tests para evitar romper el código sin que nos demos cuenta. Si quieres profundizar acerca del código mantenible y limpio, puedes echarle un vistazo a los principios SOLID, enfocados a la programación orientada a objetos.