<aside> 📌

</aside>

🙄 개선의 이유

• 개선 전 디렉토리 구조

개선 전에는 코드를 역할(components, hooks, pages, …)에 따라 분류해놨다. 처음에는 이 정도의 분류로도 충분했지만, 개발을 할수록 점차 문제점이 보이기 시작했다.

개선 전 구조의 문제점

1. src/components의 평면적인 구조

• 페이지 종속 컴포넌트는 src/pages 하위에 잘 분리되어 있으나, src/components 내부 구조에 문제가 있음
  • 성격이 다른 컴포넌트들이 구분 없이 한 폴더에 섞여있음
    • 실제 재사용 컴포넌트 (ChatContainer, Header 등)
    • SVG 아이콘 컴포넌트 (Icons)
  • 컴포넌트의 역할과 책임이 불명확함

2. src/hooks의 평면적인 구조

• 각기 다른 기능을 담당하는 훅들이 동일 레벨에 위치
  • 스트리밍 관련: useConsumer, useProducer, useMedia, useTransport
  • 인증 관련: useAuth,
  • api 관련: useAPI
  • 공통 기능: useSocket, useTheme, useToast, useIntersect
• 관련 기능의 훅들이 분산되어 있어 코드 파악이 어려움
• 훅 간의 의존성 관리가 복잡함

3. 기능 확장의 어려움

• 평면적인 구조로 인해 새로운 기능 추가 시 적절한 위치 선정이 어려움
• 기존 코드와의 관계를 파악하기 어려워 리팩토링이나 기능 추가가 복잡해짐
• 이후에 기능을 추가하게 된다면 이러한 문제점들이 더욱 부각될 것으로 예상

이런 문제점들로 인해 디렉토리 구조를 개선하기로 결정했다.

개선 방향: FSD (Feature-Sliced Design) 도입

기능들이 동일 레벨에 혼재되어 있어서 구분이 명확하지 않다는 문제가 있었다. 그렇기에 애플리케이션을 기능단위로 분리하는 아키텍처 방법론인 FSD를 도입하여 각 기능 단위로 관련 코드들을 그룹화하면, 위 문제점들을 해결할 수 있을 것이라고 생각한다. 특히 라이브 스트리밍, 채팅과 같이 기능 중심의 복잡한 애플리케이션에서 FSD는 코드의 구조화와 유지보수성을 크게 향상시킬 수 있을 것이다.

FSD 말고 다른 컴포넌트 디자인 패턴은 고려 안 했나요??