Refactorizando código aplicando Casos de Uso

Después del intento fallido de hacer un live-coding con este tema, por problemas de mi conexión tuve que cancelarlo. Intente grabarlo en un vídeo y subirlo, pero es un tema que se estaba haciendo largo y la edición iba a llevar un buen tiempo sumado que odio la edición. Así que, lo voy a hacer escrito, a la vieja usanza.

No se preocupen que lo iré haciendo paso a pasa para que se entienda lo mejor posible.

Código de un suscriptor que vamos a trabajar

Este es el correo electrónico que me envió Shonen donde me consulta cómo podría refactorizar su código. Y el código es el siguiente:

La idea de este artículo es analizar el código, ver sus problemas y cómo lo podemos encarar a una mejor solución. Siempre enfoque mis desarrollos a dividirlos en Casos de Uso. Así que veremos de que se trata esto, sus beneficios y su implementación.

Analizando el código de Shonen

Nos podemos dar cuenta que es un método de un controlador y que se encarga de actualizar los datos del perfil del usuario logueado.

Si bien este código cumple con su cometido pero tiene varios problemas:

1. No es un código que escale.
2. No es re utilizable.
3. Y es difícil de testear de forma unitaria.

Estos problemas convierten al código en un código de baja calidad.

Aplicando refactorización a Casos de Uso

¿Qué es un Caso de Uso?

Un caso de uso es una acción que puede hacer un usuario con nuestro sistema. Y son independientes del framework o packages que utilicemos.

En este ejemplo, el caso de uso general es Actualizar Perfil. Pero a su vez, vemos que esté realiza cierta lógica para generar el avatar del usuario y otra cierta lógica para generar la contraseña.

Entonces podríamos decir que estas funcionalidades son dos casos de uso más: generar avatar y generar contraseña. Lo podríamos diagramar de la siguiente manera:

Para el que no sabe UML, el dibujo de la persona representa cualquier usuario o sistema que llama a la actualización de perfil.

Cada circulo representa un caso de uso. Para que se entienda más, al caso de uso general de Actualizar Perfil le puse el mismo nombre que tiene el método. Esto no sería lo correcto pero lo hice para que se entienda mejor.

Después vemos que hay dos casos de uso más a los que se lo apunta con una flecha punteada y con la descripción «include». Esto quiere decir que el caso de uso edit_profile (o UpdateProfile, como lo llamaremos a partir de ahora), utiliza los casos de uso Generar Avatar y Generar Contraseña.

Dicho esto, vamos a pasarlo a código.

Refactorizando a Casos de Uso

Siempre hay que tener tests automatizados antes de empezar a refactorizar código para asegurarnos que las modificaciones que vayamos haciendo no afecten a la funcionalidad.

Pero, lo bueno de refactorizar a casos de uso es que se utilizan técnicas que entran dentro de las safe refactoring. Este tipo de técnicas son tan simples que no requieren que tengamos tests previamente.

Veamos los pasos para refactorizar a casos de uso.

Primer paso: Identificar los distintos casos de uso

Esto ya lo hicimos en el análisis. Vimos que tenemos los casos Actualizar Perfil, Generar Avatar y Generar Contraseña.

Segundo paso: Crear clases por cada caso de uso

Para nuestro ejemplo vamos a codear tres clases: UpdateProfile.php, GenerateAvatar.php y GeneratePassword.php. Y cada una debe tener un único método publico:

final class UpdateProfile
{
    public function execute()
    {
    }
}

final class GenerateAvatar
{
    public function execute()
    {
    }
}

final class GeneratePassword
{
    public function execute()
    {
    }
}

Tercer paso: Mover el código a cada caso de uso

Identificamos que porción de código pertenece a cada caso de uso, así que hagamos un «copy&paste» y movamos el código a cada clase:

Y, como el caso de uso de Actualizar Perfil es el incluye los dos anteriores (acuérdense el diagrama UML), quedaría así:

Y el controlador simplemente quedará así:

De esta forma estamos cumpliendo con la responsabilidad del controlador que es funcionar como un orquestador, obteniendo los datos, llamar a las clases necesarias que resuelvan la tarea y luego responder 💪.

Paso cuarto: Identificar dependencias y datos

Todo muy lindo, pero al copiar y pegar el código del controlador a cada clase, veremos que el IDE empezará a alertarnos que hay clases que no existen (dependencias) y variables no definidas (datos).

Un claro ejemplo es el caso de uso «GenerateAvatar» donde utiliza la facade Storage y el package WebP (dependencias) y $request->file('avatar') y Auth::user()->avatar (datos).

La regla que debemos aplicar para esto es, las dependencias las inyectamos por el constructor de la clase y los datos por el método publico.

Como vemos, todo lo que son dependencias las pase por el constructor y los datos por el método execute. También ya que estaba, mejore los dos IF. Al primero consulto estrictamente por null (ya que es un objeto). Y al segundo IF también puse que la comparación sea estricta con !== y pasa el string a una constante.

Como la clase GenerateAvatar es utilizada por UpdateProfile, este último va a tener estas mismas dependencias para poder pasárselas a GenerateAvatar, como así también los datos que UpdateProfile necesita.

Y a su vez, el controlador debe pasarle las dependencias y datos a UpdateProfile.

Esto no es la mejor forma de hacerlo, pero eso es cosa de un segundo artículo. Por ahora quedara así:

Además de agregar las dependencias y los datos en el execute en esta clase, también le hice una mejora.

Si ven el código anterior de la clase UpdateProfile la primer linea del método execute era así:

$user = User::where('email', Auth::user()->email)->first();

Y esta llamada a base de datos para obtener el usuario esta de más, porque en Auth::user() ya tenemos el usuario. Así que, la reemplace por:

$user = Auth::user();

Por otro lado, el controlador quedo así:

Quinto paso: Atacar cada clase

Ahora que tenemos cada caso de uso con su propia responsabilidad es mucho más fácil trabajar y refactorizar sobre cada una de ellas.

Empezemos a refactorizar GenerateAvatar:

• Para el primer IF, aplicare una Cláusula de Guarda (si no sabes lo que es, podes ver más info haciendo click aquí).

if ($avatar === null) {
    return $authAvatar;
}

• La variable $ruta nada mas se utiliza en la última linea, así que vamos a eliminarla y hacer lo siguiente.

$this->webp->make($imagen)->save(public_path("/storage/users/{$tiempo}.web"));

• El segundo bloque de IF utiliza variables que no se usan en la continuación del proceso. Así que, lo mejor sería extraer este bloque a un método privado.
• También aplicaremos una cláusula de guarda en este nuevo método y extraeremos la eliminación de archivos a un nuevo método.

• La variable $image es una variable temporal, así que la eliminare y directamente utilizare $avatar.
• Extraje algunos valores más a constantes.
• Y por último, en lugar de asignar la ruta del nuevo avatar al modelo user, vamos a retornar la ruta. Porque recordemos que esta caso de uso es genera el avatar, no lo actualiza. El que lo actualizara finalmente será el caso de uso UpdateProfile. Finalmente la clase nos quedará así:

Beneficios de los Casos de Uso

Al separar nuestro código en casos de uso ganamos:

• Orden: toda la logica no esta en el controlador.
• Legibilidad: se entiende mejor lo que hace cada clase.
• Testeabilidad: ahora podemos agregar tests unitarios a cada una de las clases (lo veremos en un próximo artículo).
• Reutilización: puede que en otra parte de nuestro sistema también necesitemos generar el avatar.
• Aplicamos características de SOLID: como por ejemplo el Principio de Responsabilidad Unica.
• Alta cohesión: ya que cada una de sus variables, constantes y métodos tienen que ver con el propósito de la clase, a esto se lo llama alta cohesión y es una de las características claves que tiene que tener toda clase para ser una clase de calidad.

Conclusión

Y quedan más cosas por aplicar que mejorarán nuestro código. Y veremos en próximos artículos. Sin duda, encarar nuestros desarrollos por medio de los casos de uso nos dan muchísimos beneficios y nos brindan un código de alta calidad. Por el momento, lo cortamos acá para no extenderla tanto.

Espero que les haya gustado y les agradecería mucho que compartan este artículo en sus redes sociales. Nos vemos 😉🤙.