폴더 구조 변경

[lybell-art]

논의 배경

저희 프로젝트는 피처 기반 폴더 구조를 채용하고 있어요. 저희가 피처 기반 폴더 구조를 채용한 이유는 다음과 같아요.

• 유형 기반 폴더 구조(component, hooks, store 등으로 폴더를 채용하는 방식)에 비해, 유사한 기능을 가지는 파일들을 쉽게 탐색할 수 있어요.
  • 유형 기반 폴더 구조를 채용하면 특정한 기능을 개발하거나, 특정한 기능에서 오류가 발생했을 때, 유사한 기능을 담당하는 파일이 완전히 격리되어 있기 때문에, 폴더를 뒤져가면서 찾아야 하는 수고가 늘어나요.
  • 피처 기반 폴더 구조를 채용하면 유사한 피처를 담당하는 파일들이 하나의 폴더에 존재하기 때문에, 개발 도중 찾기가 수월하다는 이점이 있어요.

하지만, 피처 기반 폴더 구조를 채용하면 개발하면서 루트 src 폴더 내에 폴더가 매우 많이 증식하기 때문에, 최상단 폴더 관리가 어려워지는 단점이 있어요. 특히, common에 해당하는 요소들이 각각의 피처 폴더와 동일한 계층에 있기 때문에, common 폴더를 찾기가 매우 어렵다는 문제가 있었어요.

추가로, 저희가 어드민 페이지의 개발을 앞두고 있는 상황에서, 실제 서비스 페이지의 feature와 어드민 페이지에서 쓰이는 feature가 동일한 위계에 있으면 혼동이 올 수 있을 것이라고 생각했어요.

제안 사항

• common (메인 페이지 및 어드민 페이지에서 공통적으로 사용됩니다.)
  • modal
  • dataFetch
  • utils
    • components
    • hooks
    • utils
• mainPage (메인 페이지에서 사용되는 feature들의 모음입니다.)
  • shared (여러 구체적인 섹션에서 참조하는 공통 feature입니다.)
    • auth
    • realtimeEventState
    • scroll
  • features (구체적인 섹션입니다. features에 있는 코드는 다른 feature의 것을 참조할 수 없습니다.)
    • introSection
    • simpleInformation
    • detailInformation
    • interactions
    • fcfs
    • comments
    • qna
    • header
    • footer

common 폴더를 찾기 매우 어렵다는 점을 보완하기 위해, 그리고 어드민 페이지 관리에 대응하기 위해, 사용되는 범위에 따라, 폴더를 세 분류로 그룹화했어요. common, (페이지) / shared, (페이지) / features가 그것이에요.
common 폴더와 각 피처로 나뉘기 때문에, 루트 폴더에 파일의 수가 적어져서 common 기능을 찾기 쉬울 것이라고 생각했어요. common 폴더 역시 연관된 features로 묶이며, feature로 묶이지 않는 것들은 utils라는 폴더로 묶어서 관리할 예정이에요.

페이지 폴더는 shared, features로 나눌 예정이에요. shared 폴더나 common 폴더는 여태까지 그래왔듯 같은 계층의 다른 섹션을 참조할 수 있지만, features 폴더는 다른 features 폴더의 내용을 참조할 수 없어요. 만약 features 폴더가 다른 features 폴더의 것을 참조한다면, 참조되는 내용은 2개의 features가 참조하는 별도의 기능이기 때문에, 참조된 기능을 shared 폴더로 옮겨야 해요.

이렇게 제약을 둔 이유는 기능의 혼합을 막고, 기능 간의 의존성을 줄이기 위해서에요. 저희 프로젝트에는 서버 시간을 기준으로, 인트로 섹션에서 카운트를 렌더링하고, 선착순 섹션에서 카운트를 렌더링함과 동시에 현재 시간과 일치하는 경품을 하이라이트하고, 인터랙션 섹션에서 현재 시간과 일치하는 인터랙션을 보여주어야 해요. 하지만, 서버 시간을 받아오고 카운트하는 로직이 현재는 선착순 섹션에 존재하는데, 이렇게 되면 인터랙션 섹션에서 선착순 섹션을 참조하게 되어서 인터랙션 기능이 선착순 기능에 의존하는 모양이 되어버려요. 만약 선착순 기능의 특정 기능을 더 구현하겠다고, 서버시간 로직을 건드리면 연관된 인터랙션 기능도 망가지는 문제가 생겨버려요.

이렇게, feature 기반 폴더 구조의 장점을 살리면서, common 폴더를 쉽게 찾고, 보다 외부인이 볼 때 구조적으로 편안하게 볼 수 있도록 구성해 보았어요.

[lybell-art]

이렇게 폴더를 세분화하면, 개발 단계에서 코드가 번거로워질 수 있으므로(이전에는 @/scroll/scrollTo.js로 구분되었던 것이 @/mainPage/shared/scroll/scrollTo.js로 이동해야 함), 다음의 alias를 추가로 제시하는 것을 제안합니다.

@common: @/common과 동치입니다.
@main : @/mainPage/shared과 동치입니다.
@admin : @/adminPage/shared과 동치입니다.

[darkdulgi]

좋습니다!

[lybell-art]

폴더 구조 격변은 근간을 바꿔놓는 작업이기 때문에, 리팩토링 도중에는 개인 작업이 불가능하고, 둘이서 같이 진행해야 합니다.
폴더 구조 리팩토링이 완료되면 그때부터 개인 작업이 가능합니다.

• (백엔드 API 논의 끝나고) -> 폴더 구조 리팩토링 -> 개인작업