L'anti-modèle architectural le plus tristement célèbre dans le développement frontend est probablement la Big Ball of Mud. Le terme Big Ball of Mud s’applique aux systèmes qui n’ont pas de structure perceptible ni d’organisation modulaire. La base de code s'est développée de manière organique et chaotique, devenant un cauchemar de maintenance. C'est une situation dans laquelle se trouvent de nombreux développeurs, en particulier lorsqu'ils sont pressés de respecter les délais et de développer un grand nombre de fonctionnalités.
C'est de cela que parle l'article actuel : l'anti-modèle Big Ball of Mud avec un exemple tiré du développement frontend, pourquoi il est si courant, quand cela devient un problème et comment résoudre ce problème.

Qu'est-ce que la grosse boule de boue ?

La Grande Boule de Boue est un système dont les limites architecturales sont mal définies. Au sein de tels systèmes, le code devient intriqué et fortement couplé, ce qui rend problématique le maintien ou l'extension du projet. Au fil du temps, à mesure que de nouvelles fonctionnalités sont ajoutées sans prêter attention à la conception globale, il devient de plus en plus difficile de travailler avec le code. Sans structure, apporter des modifications trop facilement à une partie du système interrompt d'autres parties, introduisant par inadvertance des bugs qui élèvent encore la barre en matière de complexité de développement.

Dans une Grande Boule de Boue, vous verrez souvent les caractéristiques suivantes :
La NOAA sépare clairement les préoccupations ; la logique métier, l’interface utilisateur et la récupération de données sont étroitement liées. Couplage lâche de la NOAA ; les composants sont étroitement liés et les changements sont donc difficiles à isoler. Modularité NOAA ; chaque partie du système dépend de chaque autre partie. Variables globales de la NOAA ou états partagés avec des effets secondaires imprévisibles.

La grosse boule de boue est le résultat courant d'une pression élevée pour livrer rapidement sans prêter attention à l'architecture. Au début d'un projet, les développeurs sont souvent pressés de créer des fonctionnalités aussi rapidement que possible, avec peu de temps pour une planification adéquate. Cela conduit à la croissance de la base de code dans toutes les directions, une nouvelle logique étant insérée partout où elle peut s'adapter. Au fil du temps, la refactorisation est retardée ou ignorée au profit de la livraison de plus de fonctionnalités, et l'architecture se détériore.

Les autres facteurs contribuant à cet anti-modèle incluent :

• Manque de coordination : les développeurs ne se coordonnent pas entre eux. Il en résulte un codage incohérent et des fonctionnalités dispersées.
• Aucune norme établie ou principe architectural établi pour guider le développement.
• Dette technique : de nouvelles fonctionnalités sont ajoutées en plus de ce qui est déjà du code compliqué sans nettoyer le désordre.

Regardons de plus près à quoi pourrait ressembler la Big Ball of Mud sur un projet frontend moyen.

Exemple de grosse boule de boue dans le frontend

Voici un exemple abstrait de l'anti-modèle Big Ball of Mud dans l'architecture front-end. Prenons l'exemple d'un petit projet React qui a tourné au chaos au fil du temps.

Structure du fichier :

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

Problèmes avec cette architecture :

• Absence de limites de module : Les composants, par exemple l'en-tête, le pied de page et le profil utilisateur, résident tous dans un seul dossier sans aucune considération pour le rôle joué par chacun d'eux.
• Mélange de préoccupations : Les composants sont responsables de la récupération des données, c'est-à-dire des appels d'API et du rendu des éléments de l'interface utilisateur. Ainsi, le couplage étroit entre les couches logiques et de présentation persiste.
• Styles globaux : Le projet dépend d'un seul fichier CSS global. À mesure que votre application grandit, cela peut entraîner des conflits de styles et sera encore plus difficile à maintenir. Utilisation directe des API dans les composants : la méthode de récupération et de mise à jour des données est importée directement dans des composants comme UserProfile.js, mélangeant ainsi la logique de récupération de données avec le code de l'interface utilisateur.

Exemple de code 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;

Problèmes dans le Code :

• Pas de SoC : La récupération des données, la gestion de l'état et le rendu de l'interface utilisateur sont effectués au même endroit au sein du composant.
• Couplage étroit : La mise à jour de l'API forcera la mise à jour de plusieurs composants, car il n'y a pas de couche d'abstraction entre l'API et les composants.
• Aucune réutilisation logique : Un autre composant souhaitant accéder aux données utilisateur réimplémentera l'appel d'API ou se couplera étroitement à cette logique.

Ce code enchevêtré et interdépendant est difficile à mettre à l'échelle et à maintenir, ce qui est ce qu'est une grosse boule de boue.

Quand les problèmes commencent-ils ?

Un projet présentant ce type d'architecture peut ne pas présenter immédiatement de signes apparents de problèmes. Mais à mesure que le projet grandit, les problèmes s'aggravent également :

• Développement lent : Les modifications deviennent plus risquées car des bogues dans des parties du système sans rapport avec l'endroit où la modification a été effectuée peuvent apparaître.
• Dette technique plus importante : Les fonctionnalités supplémentaires définies sans refactorisation impliquent des améliorations architecturales qui deviennent plus difficiles à réaliser.
• Faible productivité : Les développeurs commenceront à prendre plus de temps simplement pour naviguer et trouver quelque chose de sensé à partir d'un code aussi compliqué, ralentissant ainsi le développement des fonctionnalités.

Plus il est noué, plus il est difficile à démêler. Bien sûr, il ne s’agit ici que de la spirale vicieuse d’une dette technique croissante et d’une diminution de la productivité.

Comment éviter la grosse boule de boue

Pour éviter la grande boule de boue, de bonnes habitudes architecturales doivent être inculquées dès le début et rigoureusement appliquées pendant le processus de développement. Certaines stratégies suivent.

1. Architecture modulaire : Division claire de votre code en modules logiques avec des limites de responsabilité. Par exemple, les préoccupations peuvent être séparées par la récupération de données, la logique métier et le rendu de l'interface utilisateur.

2. Abstractions : appels d'API abstraits et gestion des données via des services ou des hooks de telle sorte que ces préoccupations soient extraites de vos composants. Cela aidera à découpler le code et facilitera la gestion des modifications dans votre API.

3. Limites des modules : Il doit y avoir une limite bien définie entre les composants. Au lieu de regrouper tous les composants dans un seul dossier, créez des dossiers distincts pour une fonctionnalité ou un domaine.

4. Gestion globale de l'état : Utilisez des bibliothèques telles que Redux, MobX ou l'API contextuelle de React pour la gestion de l'état partagé entre les composants. Cela réduit considérablement le besoin pour un composant de gérer l'état lui-même.

5. Refactoring : Refactorisez régulièrement. Ne laissez pas le projet atteindre un stade où il devient absolument impossible à gérer ; répondez à ces problèmes tout en gardant la base de code propre.

Que faire si vous êtes déjà coincé dans une grosse boule de boue

Si votre projet s'est déjà transformé en une grosse boule de boue, il y a de l'espoir. Le remède consiste à refactoriser la base de code au coup par coup, en intégrant les principes architecturaux lorsque cela est possible. Commencez par :

• Identifier les points faibles : Concentrez-vous sur les parties du code qui sont les plus difficiles à utiliser ou à étendre.
• Composants modularisés : Refactorisez progressivement les composants pour séparer les problèmes et limiter les dépendances. Maintenant, introduisez les tests : ajoutez des tests unitaires et d'intégration pour vous assurer que votre refactorisation ne brise pas les fonctionnalités existantes.

En résumé, Big Ball of Mud est un anti-modèle très courant causant beaucoup de problèmes dans les projets frontend. L'introduction d'une architecture modulaire, la séparation des préoccupations et une refactorisation régulière sont certainement des étapes qui permettraient d'éviter le chaos introduit par ce modèle de votre base de code, la rendant plus propre et plus gérable.