아마도 프론트엔드 개발에서 가장 악명 높은 아키텍처 안티패턴은 Big Ball of Mud일 것입니다. Big Ball of Mud라는 용어는 식별 가능한 구조나 모듈식 구성이 없는 시스템에 적용됩니다. 코드베이스는 유기적이고 혼란스럽게 성장하여 유지 관리가 악몽이 되었습니다. 특히 마감일을 지키고 많은 양의 기능을 개발해야 하는 상황에서는 많은 개발자가 처하게 되는 상황입니다.
현재 기사의 내용은 다음과 같습니다. Big Ball of Mud 안티패턴과 프론트엔드 개발에서 가져온 예, 이것이 왜 그렇게 일반적인지, 언제 문제가 되는지, 이 문제를 해결하는 방법은 다음과 같습니다.

큰 진흙 공은 무엇입니까?

큰 진흙 공은 아키텍처 경계가 제대로 정의되지 않은 시스템입니다. 이러한 시스템 내에서 코드는 서로 얽혀 있고 고도로 결합되어 프로젝트를 유지하거나 확장하는 데 문제가 됩니다. 시간이 지나면서 전체적인 디자인에 신경을 쓰지 않고 더 많은 기능이 추가되면서 코드 작업이 점점 더 어려워집니다. 구조가 없으면 시스템의 한 부분을 변경하면 다른 부분이 너무 쉽게 손상되어 실수로 개발 복잡성의 기준을 더욱 높이는 버그가 발생합니다.

큰 진흙 공에서는 다음과 같은 특징을 자주 볼 수 있습니다.
NOAA의 명확한 우려 분리; 비즈니스 로직, UI, 데이터 가져오기가 서로 얽혀 있습니다. NOAA 느슨한 결합; 구성 요소가 서로 얽혀 있으므로 변경 사항을 따로 분리하기가 어렵습니다. NOAA 모듈성; 시스템의 모든 부분은 다른 모든 부분에 의존합니다. NOAA 전역 변수 또는 예측할 수 없는 부작용이 있는 공유 상태.

큰 진흙덩이는 아키텍처에 대한 적절한 주의 없이 빠르게 제품을 납품해야 한다는 높은 압력으로 인해 흔히 발생하는 결과입니다. 프로젝트 초기에 개발자는 적절한 계획을 세울 시간이 거의 없이 가능한 한 빨리 기능을 구축하려고 서두르는 경우가 많습니다. 이로 인해 코드베이스가 들어갈 수 있는 모든 곳에 새로운 로직이 삽입되면서 모든 방향에서 코드베이스가 성장하게 됩니다. 시간이 지남에 따라 더 많은 기능을 제공하기 위해 리팩토링이 지연되거나 무시되고 아키텍처가 저하됩니다.

이 안티패턴에 영향을 미치는 다른 요인은 다음과 같습니다.

• 조정 부족: 개발자들이 서로 조정하지 않습니다. 일관되지 않은 코딩과 분산된 기능이 발생합니다.
• 확립된 표준이나 개발을 안내하기 위해 정해진 아키텍처 원칙이 없습니다.
• 기술적 부채: 지저분한 코드를 정리하지 않고도 이미 지저분한 코드 위에 새로운 기능이 추가됩니다.

일반적인 프런트엔드 프로젝트에서 큰 진흙 공이 어떤 모습일지 자세히 살펴보겠습니다.

프런트엔드에 있는 큰 진흙 공의 예

다음은 프런트엔드 아키텍처의 Big Ball of Mud 안티패턴의 추상적인 예입니다. 시간이 지나면서 혼란에 빠진 작은 React 프로젝트를 생각해 보세요.

파일 구조:

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

이 아키텍처의 문제:

• 모듈 경계 부족: 헤더, 바닥글, 사용자 프로필과 같은 구성 요소는 각각의 역할을 고려하지 않고 모두 하나의 폴더에 있습니다.
• 우려 사항 혼합: 구성 요소는 데이터 가져오기(예: API 호출 및 UI 요소 렌더링)를 담당합니다. 따라서 로직과 프리젠테이션 레이어 간의 긴밀한 결합이 지속됩니다.
• 전역 스타일: 프로젝트는 단일 전역 CSS 파일에 따라 달라집니다. 애플리케이션이 커짐에 따라 스타일 충돌이 발생할 수 있으며 유지 관리가 더욱 어려워집니다. 구성 요소에서 API 직접 사용: 데이터를 가져오고 업데이트하는 방법을 UserProfile.js와 같은 구성 요소에서 직접 가져오므로 데이터 가져오기 논리를 UI 코드와 혼합합니다.

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;

코드 문제:

• SoC 없음: 데이터 가져오기, 상태 관리 및 UI 렌더링이 모두 구성 요소 내 한 곳에서 수행됩니다.
• 긴밀한 결합: API를 업데이트하면 API와 구성 요소 사이에 추상화 계층이 없기 때문에 여러 구성 요소가 강제로 업데이트됩니다.
• 로직 재사용 없음: 사용자 데이터에 액세스하려는 또 다른 구성 요소는 API 호출을 다시 구현하거나 이 로직과 긴밀하게 결합됩니다.

이 엉키고 상호의존적인 코드는 확장과 유지 관리가 어렵습니다. 이것이 바로 커다란 진흙 덩어리입니다.

문제는 언제 시작됩니까?

이러한 유형의 아키텍처를 갖춘 프로젝트에서는 즉시 문제의 징후가 뚜렷하게 나타나지 않을 수도 있습니다. 그러나 프로젝트가 성장함에 따라 문제도 복잡해집니다.

• 느린 개발: 변경이 이루어진 위치와 관련 없는 시스템 부분의 버그가 나타날 수 있으므로 변경이 더 위험해집니다.
• 더 큰 기술 부채: 리팩토링 없이 설정된 추가 기능에는 실현하기가 더욱 어려워지는 아키텍처 개선이 포함됩니다.
• 낮은 생산성: 개발자는 이러한 지저분한 코드에서 탐색하고 의미 있는 것을 알아내는 데 더 많은 시간을 소비하기 시작하여 기능 개발 속도가 느려집니다.

매듭이 많아질수록 풀기가 더 어려워집니다. 물론 이는 기술부채 증가와 생산성 감소의 악순환에 불과하다.

큰 진흙덩어리를 피하는 방법

진흙 덩어리를 피하려면 개발 과정에서 좋은 건축 습관을 조기에 주입하고 엄격하게 시행해야 합니다. 몇 가지 전략은 다음과 같습니다.

1. 모듈형 아키텍처: 책임 경계가 있는 논리 모듈로 코드를 명확하게 구분합니다. 예를 들어, 데이터 가져오기, 비즈니스 로직, UI 렌더링으로 우려사항을 분리할 수 있습니다.

2. 추상화: 이러한 문제가 구성 요소에서 추상화되도록 서비스 또는 후크를 통한 추상 API 호출 및 데이터 관리입니다. 이렇게 하면 코드를 분리하고 API의 변경 사항을 더 쉽게 처리할 수 있습니다.

3. 모듈 경계: 구성요소 간에 경계가 잘 정의되어 있어야 합니다. 모든 구성 요소를 하나의 폴더 아래에 두는 대신 기능이나 도메인에 대해 별도의 폴더를 만듭니다.

4. 전역 상태 관리: 구성요소 간 공유 상태 관리를 위해 Redux, MobX 또는 React의 Context API와 같은 라이브러리를 사용하세요. 이렇게 하면 구성 요소가 상태 자체를 관리하려는 충동이 크게 줄어듭니다.

5. 리팩토링: 정기적으로 리팩터링합니다. 프로젝트가 더 이상 처리할 수 없는 단계에 도달하도록 허용하지 마십시오. 코드베이스를 깔끔하게 유지하면서 이러한 문제를 해결하세요.

이미 큰 진흙덩이에 갇힌 경우 해야 할 일

귀하의 프로젝트가 이미 커다란 진흙 덩어리로 발전했다면 희망이 있습니다. 해결책은 가능한 경우 아키텍처 원칙을 적용하여 코드베이스를 단편적으로 리팩터링하는 것입니다. 시작:

• 고충점 식별: 작업하거나 확장하기 가장 어려운 코드 부분에 집중하세요.
• 구성 요소 모듈화: 구성 요소를 점진적으로 리팩터링하여 문제를 분리하고 종속성을 제한합니다. 이제 테스트를 도입하세요. 단위 및 통합 테스트를 추가하여 리팩토링이 기존 기능을 중단하지 않는지 확인하세요.

요약하자면 Big Ball of Mud는 프런트엔드 프로젝트에서 많은 문제를 일으키는 매우 일반적인 안티패턴입니다. 모듈식 아키텍처 도입, 우려사항 분리 및 정기적인 리팩토링은 확실히 이 패턴으로 인해 코드베이스에서 발생하는 혼란을 유지하여 코드베이스를 더 깔끔하고 관리하기 쉽게 만드는 단계입니다.