El que tiene miedo a refactorizar, que no programe: Cómo la refactorización te convierte en un mejor arquitecto de software

Deja un comentario / Análisis y Arquitectura / Por

Hace mucho tiempo que no me siento a escribir un artículo, pero mi mente siempre está activa, analizando problemas y buscando soluciones. La refactorización de código es un tema que ha estado en mi mente durante muchos años, y creo que ahora, después de muchas horas pensando, tengo la base necesaria para compartir mis ideas. En este artículo, quiero explorar por qué no debemos temerle a la refactorización, y cómo este proceso puede ser una herramienta valiosa para cualquier desarrollador.

Hay un dicho que siempre me ha llamado la atención: «El que tiene miedo a morir, que no nazca». Suena fuerte, ¿verdad? Pero si lo pensamos bien, encierra una verdad incómoda pero innegable: la vida implica riesgos, cambios y, sobre todo, aprendizaje. Y si lo llevamos al mundo del desarrollo de software, podríamos adaptarlo perfectamente: «El que tiene miedo a refactorizar, que no programe».

La refactorización es una de esas prácticas que, aunque todos sabemos que es necesaria, muchos evitamos como si fuera el monstruo debajo de la cama. ¿Por qué? Porque refactorizar implica cambiar código que ya funciona, y eso da miedo. ¿Y si lo rompemos? ¿Y si introducimos un bug? ¿Y si el cliente se enoja porque tardamos más de lo esperado? Son preguntas válidas, pero hoy quiero invitarnos a ver la refactorización no como un enemigo, sino como una oportunidad para crecer, aprender y convertirnos en mejores arquitectos de software.

El miedo a refactorizar: ¿por qué nos paraliza?

Imaginemos esto: tenemos un código que funciona. No es el código más limpio del mundo, ni el más eficiente, pero funciona. Y ahí está el problema. Como funciona, decidimos no tocarlo. Total, ¿para qué arriesgarnos? Mejor dejarlo así y seguir adelante con las nuevas funcionalidades. ¿suena familiar?

Este miedo a refactorizar tiene varias caras. Por un lado, está el temor a romper algo. Sí, ese pánico que sentimos cuando modificamos una línea de código y de repente todo se cae a pedazos. Por otro lado, está la falta de tiempo. En un mundo donde los plazos aprietan, refactorizar parece un lujo que no nos podemos permitir. Y, por último, está la falta de confianza. ¿Realmente somos capaces de mejorar este código? ¿O vamos a empeorarlo?

Pero aquí está la cosa: el código no es estático. El software evoluciona, los requisitos cambian y lo que hoy funciona, mañana puede convertirse en un dolor de cabeza. Si no refactorizamos, estamos acumulando deuda técnica, y como cualquier deuda, llegará el momento en que tengamos que pagarla, con intereses.

Refactorizar no es solo limpiar código, es aprender

Una de las cosas que más me gusta de refactorizar es que nos obliga a entender el código a fondo. No podemos mejorar algo que no comprendemos. Y en ese proceso de análisis, aprendemos. Aprendemos cómo funciona el sistema, cómo se relacionan las diferentes partes y, sobre todo, aprendemos a identificar patrones y antipatrones.

Refactorizar también es una oportunidad para aplicar mejores prácticas. ¿Han oído hablar de los principios SOLID? ¿O del principio DRY (Don’t Repeat Yourself)? La refactorización es el momento perfecto para poner en práctica estos conceptos. No se trata solo de hacer que el código sea más limpio, sino de hacerlo más robusto, más mantenible y más escalable. Recordemos que el mayor porcentaje de esfuerzo no está en el desarrollo de un software, sino en mantenerlo.

Y lo mejor de todo es que podemos experimentar sin miedo. Con un buen conjunto de pruebas automatizadas, podemos refactorizar con confianza, sabiendo que si algo se rompe, lo sabremos de inmediato. Es como tener una red de seguridad mientras caminamos por la cuerda floja.

Los beneficios de refactorizar: más allá del código limpio

Refactorizar no es solo una cuestión de estética. Tiene beneficios concretos que impactan directamente en la calidad del software y en nuestra productividad como desarrolladores.

  1. Mejora la mantenibilidad:
    Un código refactorizado es más fácil de entender, modificar y extender. Se vuelve más estándar. Esto significa que, en el futuro, nosotros o cualquier otro desarrollador podrá hacer cambios más rápidamente y con menos errores.
  2. Optimiza el rendimiento:
    A veces, refactorizar implica eliminar cuellos de botella o mejorar la eficiencia del código. Esto puede traducirse en una aplicación más rápida y con menos consumo de recursos.
  3. Facilita la escalabilidad:
    Un código bien estructurado es más fácil de escalar. Si en el futuro necesitamos agregar nuevas funcionalidades, será mucho más sencillo hacerlo si el código está organizado y sigue buenas prácticas.
  4. Reduce la deuda técnica:
    Refactorizar es como pagar la deuda técnica antes de que se convierta en un problema mayor. Un código limpio y bien organizado es más barato de mantener a largo plazo.

Cómo refactorizar sin miedo

Si todavía nos da miedo refactorizar, aquí tenemos algunas estrategias para hacerlo de manera segura y efectiva:

  1. Pruebas automatizadas:
    Antes de refactorizar, asegurémonos de tener un buen conjunto de pruebas. Esto nos dará confianza para hacer cambios sin miedo a romper algo. Aquí hago hincapié en que no hablo de pruebas unitarias, sino de pruebas automatizadas, ya que cada tipo de verificación implica analizar qué tipo de prueba vamos a usar. Esto es tema para otro artículo, pero sí, me refiero a pruebas unitarias vs pruebas de integración vs pruebas de tipo smoke.
  2. Refactorización incremental:
    No intentemos refactorizar todo de una vez. Hagamos cambios pequeños y frecuentes, y verifiquemos que todo siga funcionando después de cada modificación.
  3. Herramientas de apoyo:
    Usemos herramientas de análisis de código para identificar áreas de mejora y asegurarnos de que el código cumpla con los estándares de calidad. Hoy en día no podemos seguir pensando en usar vim para programar. Por supuesto que nuestro código tiene que ser agnóstico el IDE y que tenemos que ser capaces de modificar un código ya sea con vim o notepad, pero usemos la tecnología a nuestro favor.
  4. Documentemos los cambios:
    Expliquemos por qué y cómo refactorizamos, para que otros desarrolladores entiendan el proceso y puedan continuar mejorando el código. No hablo de documentarlo en documentos técnicos, sino que me refiero a que nos amiguemos con las documentaciones en el propio código.

Refactorizar te hace un mejor arquitecto de software

Al final del día, refactorizar no es solo una práctica técnica; es una mentalidad. Es la capacidad de ver el código no como algo estático, sino como algo vivo que puede y debe mejorar con el tiempo. Y esa mentalidad es la que nos convierte en mejores arquitectos de software.

Un buen arquitecto no solo piensa en cómo hacer que el código funcione hoy, sino en cómo hacer que siga funcionando mañana, dentro de un mes o dentro de un año. Y eso implica refactorizar. Implica estar dispuestos a cambiar, a mejorar y, sobre todo, a aprender.

Hablemos de un ejemplo tradicional

Situación inicial: Código duplicado en dos controladores

Imaginemos que tenemos dos controladores en una aplicación Symfony: ProductController y OrderController. Ambos necesitan calcular el precio total de una lista de productos, incluyendo impuestos y descuentos. En lugar de duplicar la lógica en ambos controladores, vamos a extraerla en un servicio.

1. ProductController (Código duplicado)

// src/Controller/ProductController.php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class ProductController extends AbstractController
{
    /**
     * @Route("/product/total", name="product_total")
     */
    public function calculateTotal(): JsonResponse
    {
        $products = [
            ['price' => 100, 'quantity' => 2],
            ['price' => 50, 'quantity' => 3],
        ];

        // Lógica duplicada para calcular el total
        $total = 0;
        foreach ($products as $product) {
            $total += $product['price'] * $product['quantity'];
        }

        // Calcular impuestos (15%)
        $tax = $total * 0.15;

        // Aplicar descuento si el total es mayor a 200
        if ($total > 200) {
            $discount = $total * 0.10;
            $total -= $discount;
        } else {
            $discount = 0;
        }

        return new JsonResponse([
            'total' => $total,
            'tax' => $tax,
            'discount' => $discount,
        ]);
    }
}

2. OrderController (Código duplicado)

// src/Controller/OrderController.php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class OrderController extends AbstractController
{
    /**
     * @Route("/order/total", name="order_total")
     */
    public function calculateTotal(): JsonResponse
    {
        $products = [
            ['price' => 75, 'quantity' => 4],
            ['price' => 120, 'quantity' => 1],
        ];

        // Lógica duplicada para calcular el total
        $total = 0;
        foreach ($products as $product) {
            $total += $product['price'] * $product['quantity'];
        }

        // Calcular impuestos (15%)
        $tax = $total * 0.15;

        // Aplicar descuento si el total es mayor a 200
        if ($total > 200) {
            $discount = $total * 0.10;
            $total -= $discount;
        } else {
            $discount = 0;
        }

        return new JsonResponse([
            'total' => $total,
            'tax' => $tax,
            'discount' => $discount,
        ]);
    }
}

Problema: Código duplicado

Ambos controladores tienen la misma lógica para calcular el total, los impuestos y los descuentos. Esto viola el principio DRY (Don’t Repeat Yourself) y hace que el código sea más difícil de mantener. Si necesitamos cambiar la lógica de cálculo (por ejemplo, ajustar la tasa de impuestos o el umbral de descuento), tendríamos que hacerlo en dos lugares.

Solución: Refactorizar en un servicio

Vamos a extraer la lógica de cálculo en un servicio reutilizable llamado PriceCalculatorService.

1. Crear el servicio PriceCalculatorService

// src/Service/PriceCalculatorService.php
namespace App\Service;

class PriceCalculatorService
{
    private const TAX_RATE = 0.15;
    private const DISCOUNT_THRESHOLD = 200;
    private const DISCOUNT_RATE = 0.10;

    public function calculateTotal(array $products): array
    {
        $total = 0;
        foreach ($products as $product) {
            $total += $product['price'] * $product['quantity'];
        }

        $tax = $total * self::TAX_RATE;

        $discount = ($total > self::DISCOUNT_THRESHOLD) ? $total * self::DISCOUNT_RATE : 0;
        $finalTotal = $total - $discount;

        return [
            'total' => $finalTotal,
            'tax' => $tax,
            'discount' => $discount,
        ];
    }
}

2. Registrar el servicio en Symfony

Symfony registra automáticamente los servicios en la carpeta src/Service. No necesitamos hacer nada más.

Refactorizar los controladores para usar el servicio

Ahora que tenemos el servicio, podemos usarlo en ambos controladores para eliminar la duplicación de código.

1. ProductController refactorizado

// src/Controller/ProductController.php
namespace App\Controller;

use App\Service\PriceCalculatorService;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class ProductController extends AbstractController
{
    private PriceCalculatorService $priceCalculator;

    public function __construct(PriceCalculatorService $priceCalculator)
    {
        $this->priceCalculator = $priceCalculator;
    }

    /**
     * @Route("/product/total", name="product_total")
     */
    public function calculateTotal(): JsonResponse
    {
        $products = [
            ['price' => 100, 'quantity' => 2],
            ['price' => 50, 'quantity' => 3],
        ];

        $result = $this->priceCalculator->calculateTotal($products);

        return new JsonResponse($result);
    }
}

2. OrderController refactorizado

// src/Controller/OrderController.php
namespace App\Controller;

use App\Service\PriceCalculatorService;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

class OrderController extends AbstractController
{
    private PriceCalculatorService $priceCalculator;

    public function __construct(PriceCalculatorService $priceCalculator)
    {
        $this->priceCalculator = $priceCalculator;
    }

    /**
     * @Route("/order/total", name="order_total")
     */
    public function calculateTotal(): JsonResponse
    {
        $products = [
            ['price' => 75, 'quantity' => 4],
            ['price' => 120, 'quantity' => 1],
        ];

        $result = $this->priceCalculator->calculateTotal($products);

        return new JsonResponse($result);
    }
}

Beneficios de esta refactorización

  1. Código más limpio:
    Eliminamos la duplicación de código y centralizamos la lógica en un solo lugar.
  2. Fácil de mantener:
    Si necesitamos cambiar la lógica de cálculo (por ejemplo, ajustar la tasa de impuestos), solo tenemos que hacerlo en el servicio PriceCalculatorService.
  3. Reutilizable:
    Ahora cualquier otro controlador o parte de la aplicación puede usar el servicio para calcular precios.
  4. Fácil de probar:
    Podemos escribir pruebas unitarias para el servicio PriceCalculatorService sin preocuparnos por los controladores.

Conclusión

Nos invito a que, la próxima vez que nos enfrentemos a un código que necesita ser mejorado, no temamos. Abracemos la refactorización como una oportunidad para crecer y convertirnos en mejores profesionales. No busquemos el por qué no hacerlo, sino el cómo podemos lograrlo. Porque, al fin y al cabo, el que tiene miedo a refactorizar, que no programe; porque en el mundo del software, la única constante es el cambio.

Por último, entiendo perfectamente que no todos tenemos las mismas capacidades, de hecho no tiene que ser así. Cada uno de nosotros tiene ciertos objetivos y ciertos gustos dentro de la tecnología: desarrollador, diseñador, analista, arquitecto de software. Este artículo está orientado a los que tenemos principal satisfacción con la arquitectura de software.

Ustedes, ¿Llegaron a ver cómo la refactorización de código les convirtió en mejores arquitectos de software? ¿O todavía da miedo?  ¡Compartamos esas experiencias y ayudémonos a crecer como comunidad! 😊

Descubre más desde Neurosimbiosis

Suscríbete y recibe las últimas entradas en tu correo electrónico.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *