Probablemente el antipatrón arquitectónico más infame en el desarrollo frontend es la Big Ball of Mud. El término Gran Bola de Barro se aplica a sistemas que no tienen una estructura u organización modular discernible. El código base ha crecido de forma orgánica y caótica, convirtiéndose en una pesadilla de mantenimiento. Es una situación en la que se encuentran muchos desarrolladores, especialmente cuando se les presiona mucho para cumplir con los plazos y desarrollar un gran volumen de funciones.
De eso trata el artículo actual: el antipatrón Big Ball of Mud con un ejemplo tomado del desarrollo frontend, por qué es tan común, cuándo se convierte en un problema y cómo abordarlo.

¿Qué es la Gran Bola de Barro?

La Gran Bola de Barro es un sistema con límites arquitectónicos mal definidos. Dentro de tales sistemas, el código se enreda y se acopla mucho, por lo que mantener o ampliar el proyecto se vuelve problemático. Con el tiempo, a medida que se agregan más funciones sin prestar atención al diseño general, se vuelve cada vez más difícil trabajar con el código. Sin estructura, realizar cambios en una parte del sistema con demasiada facilidad daña otras partes, introduciendo errores sin darse cuenta que elevan aún más el nivel de complejidad del desarrollo.

En una Gran bola de barro, a menudo verás las siguientes características:
Clara separación de preocupaciones de la NOAA; La lógica empresarial, la interfaz de usuario y la recuperación de datos están entrelazadas. Acoplamiento flojo de NOAA; los componentes están entrelazados y, por lo tanto, es difícil aislar los cambios. modularidad de la NOAA; cada parte del sistema depende de todas las demás partes. Variables globales de la NOAA o estados compartidos con efectos secundarios impredecibles.

La gran bola de barro es un resultado común de la alta presión para realizar entregas rápidas sin la debida atención a la arquitectura. Al comienzo de un proyecto, los desarrolladores suelen tener prisa por crear funciones lo más rápido posible, sin dedicar mucho tiempo a una planificación adecuada. Esto conduce al crecimiento del código base en todas direcciones con la inserción de nueva lógica dondequiera que pueda caber. Con el tiempo, la refactorización se retrasa o se ignora en favor de incluir más funciones y la arquitectura se deteriora.

Otros factores que contribuyen a este antipatrón incluyen:

• Falta de coordinación: Los desarrolladores no se coordinan entre sí. Se produce una codificación inconsistente y una funcionalidad dispersa.
• No hay estándares establecidos ni principios arquitectónicos establecidos para guiar el desarrollo.
• Deuda técnica: Se agregan nuevas características sobre lo que ya es un código desordenado sin limpiar el desorden.

Echemos un vistazo más de cerca a cómo se vería la gran bola de barro en un proyecto frontend promedio.

Ejemplo de gran bola de barro en el frontend

Aquí hay un ejemplo abstracto del antipatrón Big Ball of Mud en la arquitectura front-end. Considere un pequeño proyecto de React que se ha convertido en un caos durante algún tiempo.

Estructura del archivo:

/src
  /components
    /Header.js
    /Footer.js
/Sidebar.js
    /MainContent.js
    /UserProfile.js
  /utils
    /api.js
    /constants.js
  /styles
    /globalStyles.css
  /App.js
  /index.js

Problemas con esta arquitectura:

• Falta de límites de módulo: Los componentes, por ejemplo, encabezado, pie de página y perfil de usuario, residen todos en una carpeta sin ninguna consideración por el papel que desempeña cada uno de ellos.
• Mezcla de preocupaciones: Los componentes son responsables de recuperar datos, es decir, llamadas API y representar elementos de la interfaz de usuario. Por lo tanto, persiste el estrecho acoplamiento entre las capas lógica y de presentación.
• Estilos globales: El proyecto depende de un único archivo CSS global. A medida que su aplicación crezca, esto podría generar conflictos de estilos y será aún más difícil de mantener. Uso directo de API en componentes: el método para recuperar y actualizar datos se importa directamente en componentes como UserProfile.js, mezclando así la lógica de recuperación de datos con el código de la interfaz de usuario.

Código de muestra de UserProfile.js:

import React, { useState, useEffect } from 'react';
import { fetchUserData, updateUserProfile } from './utils/api';
import './styles/globalStyles.css'; 

const UserProfile = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetchUserData()
    .then((data) => {
        setUser(data);
        setLoading(false);
      })
      .catch((error) => console.error('Error fetching user data:', error));
  }, []);

  const handleUpdate = () => {
    updateUserProfile(user)
      .then(() => alert('Profile updated!'))
      .catch((error) => console.error('Error updating profile:', error));
  };

  if (loading) return 
Loading.
;

  return (
    

      
{user.name}
      Update Profile
    
  );
};

export default UserProfile;

Problemas en el Código:

• Sin SoC: La recuperación de datos, la gestión del estado y la representación de la interfaz de usuario se realizan en un solo lugar dentro del componente.
• Acoplamiento estrecho: La actualización de la API obligará a actualizar varios componentes, porque no existe una capa de abstracción entre la API y los componentes.
• Sin reutilización de lógica: Otro componente que desee acceder a los datos del usuario volverá a implementar la llamada API o se acoplará estrechamente a esta lógica.

Este código enredado e interdependiente es difícil de escalar y mantener, que es lo que es una gran bola de barro.

¿Cuándo empiezan los problemas?

Es posible que un proyecto que presenta este tipo de arquitectura no presente signos aparentes de problemas de inmediato. Pero a medida que el proyecto crece, también lo hacen los problemas que se acumulan unos sobre otros:

• Desarrollo lento: Los cambios se vuelven más riesgosos porque pueden aparecer errores en partes del sistema que no están relacionadas con el lugar donde se realizó el cambio.
• Mayor deuda técnica: Las funciones adicionales establecidas sin refactorización implican mejoras arquitectónicas que se vuelven más difíciles de realizar.
• Baja productividad: Los desarrolladores empezarán a tomarse más tiempo simplemente para navegar y distinguir algo sensato a partir de un código tan desordenado, lo que ralentizará el desarrollo de funciones.

Cuanto más anudado se vuelve, más difícil es desenredarlo. Por supuesto, se trata simplemente de la espiral viciosa de una deuda técnica creciente y una productividad cada vez menor.

Cómo evitar la gran bola de barro

Para evitar la gran bola de barro, se deben inculcar buenos hábitos arquitectónicos desde el principio y aplicarlos rigurosamente durante el proceso de desarrollo. A continuación se presentan algunas estrategias.

1. Arquitectura modular: División clara de su código en módulos lógicos con límites de responsabilidad. Por ejemplo, las preocupaciones se pueden separar según la obtención de datos, la lógica empresarial y la representación de la interfaz de usuario.

2. Abstracciones: Llamadas API abstractas y gestión de datos a través de servicios o enlaces de modo que estas preocupaciones se abstraigan de sus componentes. Esto ayudará a desacoplar el código y facilitará el manejo de los cambios en su API.

3. Límites del módulo: Debe haber un límite bien definido entre los componentes. En lugar de tener todos los componentes ubicados en una carpeta, cree carpetas separadas para una función o dominio.

4. Gestión del estado global: Utilice bibliotecas como Redux, MobX o la API Context de React para la gestión del estado compartido entre componentes. Esto reduce en gran medida la necesidad de que un componente administre el estado por sí mismo.

5. Refactorización: Refactorización periódicamente. No permita que el proyecto llegue a una etapa en la que ya sea absolutamente imposible de manejar; aborde estas inquietudes mientras mantiene limpia la base del código.

Qué hacer si ya estás atrapado en una gran bola de barro

Si tu proyecto ya se ha convertido en una gran bola de barro, hay esperanza. El remedio es refactorizar el código base poco a poco, integrando los principios arquitectónicos siempre que sea posible. Empezar por:

• Identificación de puntos débiles: Concéntrese en aquellas partes del código con las que es más complicado trabajar o ampliar.
• Modularizar componentes: Refactorizar componentes incrementalmente para separar preocupaciones y limitar dependencias. Ahora, introduzca las pruebas: agregue pruebas unitarias y de integración para asegurarse de que su refactorización no interrumpa la funcionalidad existente.

En resumen, Big Ball of Mud es un antipatrón muy común que causa muchos problemas en proyectos frontend. La introducción de una arquitectura modular, la separación de preocupaciones y la refactorización regular son definitivamente pasos que mantendrían el caos introducido por este patrón fuera de su código base, haciéndolo más limpio y manejable.