함께 수정되는 파일을 같은 디렉토리에 두기 | Frontend Fundamentals

[giscus[bot]]

함께 수정되는 파일을 같은 디렉토리에 두기 | Frontend Fundamentals

변경하기 쉬운 프론트엔드 코드를 위한 지침서

https://frontend-fundamentals.com/code/examples/code-directory.html

[suyeon1218]

도메인 별로 디렉터리 구조를 분리하는 방법은 FSD 아키텍처의 Slice 개념에서 사용하는 방법이네요! 디렉터리 구조 관련으로 고민을 해보신 분들은 읽어보시는 걸 추천드려요!

[ringo-pg-study]

https://feature-sliced.github.io/documentation/kr/
링크 꺠져서 답글 달아놓습니다.

[eric-jy-park]

Domain을 기준으로 나누면 같이 변경될 여지가 많은 코드들끼리 가까이 위치하게 되어 관계 파악에 도움이 되는건 맞으나, 개인적으로 그럼 이 파일/코드는 어디에 위치하는게 맞을까?에 대한 고민을 자주 하게 되어 불편할 때가 좀 있었습니다.

예를 들어, 20개의 Domain중, 오로지 Domain 1과 Domain2만 useXXX라는 훅이 필요하다면, 이 useXXX훅은 둘 중 하나의 Domain 폴더에 위치하는게 맞을까요, 아니면 전체 공통 폴더에 위치하는게 맞을까요?

다수의 Domain중 단 두개의 Domain에서만 사용되는 것이 확실하기에 전체 공통 폴더에 위치하기는 좀 애매한데, 그렇다고 둘 중 하나의 Domain 폴더에 위치하기엔 Domain간의 의존성이 발생하는 것 같아서 꺼려지는 경우가 있더라구요.

비슷한 고민을 하신 분이 계신지, 만약 계신다면 어떤 선택을 하셨는지 궁금합니다!

[yoosion030]

저도 @eric-jy-park 님과 동일한 고민한 경험이 있어 저만의 결정 기준을 공유드립니다!
혹시 더 나은 방안이 있다면 피드백 코멘트 남겨주세요 :)

1. 새로운 Domain 생성

위에서 언급하신 것처럼, Domain1과 Domain2 간에 강한 연관성이 있고, 앞으로도 이 두 도메인의 공통 기능이 확장될 가능성이 높다면
새로운 도메인을 생성하는 것이 적절하다고 생각합니다.

- features
   - Domain1
   - Domain2
   - Domain1과 Domain2를 어루는 명칭
      - useXXX

회사 특성상 특정 기능이 개발된 이후에 또 다른 기능으로 확장되는 경우가 많아서 공통되는 로직이 생기면 그에 맞는 Domain을 새로 추가합니다!
실제로 새로 생성한 Domain에 기능이 확장되며 다른 로직들도 추가되는 경우가 있었습니다.

둘 중 하나의 Domain 폴더에 위치하기엔 Domain간의 의존성이 발생하는 것 같아서 꺼려지는 경우가 있더라구요.
하나의 Domain에 위치시키는 것이 아닌 새로운 공통 Domain을 생성하여 개별 의존성을 보장할 수 있다고 생각해요.

Domain1과 Domain2에서 공통 Domain에 접근하는 것은 의존성 방향을 단방향(Domain1, Domain2 -> 공통 Domain)으로 흐르게 됩니다.

Domain1    Domain2
   \          /
    \        /
     공통 Domain

• 장점: 코드의 의도가 명확해지고, 공통 로직이 점차적으로 확장되더라도 기존 코드에 최소한의 영향을 미침
• 단점: 공통점이 많지 않은 상황에서 Domain을 생성하면 폴더 구조가 과도하게 세분화될 수 있음

2. 공통 폴더에 하위 Domain 생성

공통 훅으로 보기에는 두 Domain에서만 사용되는 한정된 기능이라면, 공통 폴더 아래 하위 Domain을 만들어 두는 것도 하나의 방법일 것 같습니다.

- 공통 hooks 폴더
   - Domain1과 Domain2를 어루는 명칭
      - useXXX
   - useToggle
   - useBoolean

• 장점: 도메인 추가 없이 폴더 구조가 깔끔하게 유지되며, 재사용 가능성을 간접적으로 표현함
• 단점: 하위 Domain이 여러 개 생길 경우 공통 폴더가 복잡해질 가능성이 있음

정리

if (도메인_간_강한_연관성 && 공유_코드_증가_예상) {
  return '새로운 도메인 생성';
} else if (단순_기능_공유 && 제한적_사용) {
  return '공통 폴더 하위 도메인';
}

[Johnyworld]

저도 비슷한 고민을 했었는데요, 기본적으로 @yoosion030 님께서 말씀하신 방법 처럼, 공통 도메인을 추상화하여 쪼개는 것이 맞다고 생각하며, 개인적으로는 처음부터 큰 도메인을 만들어 나중에 작게 쪼개는 것 보다는 처음부터 도메인을 충분히 '작게' 만드는 방법을 좋아하는 편입니다.

예를들어 커뮤니티 게시글 페이지를 만들 때, 맥락상 댓글은 게시글에 포함되겠지만 댓글과 게시글은 도메인은 따로 분리합니다. 댓글 데이터를 불러오기 위해서는 게시글의 정보들이 필요할 수 있을텐데요. 댓글 도메인은 게시글 도메인을 의존하도록 하고 느슨하게 연결시켜 놓는 편입니다.

유저를 다룰때에도, user 라는 큰 도메인을 만들기 보다는 user-auth 와 user-profile 이런 식으로 서로 분리시켜 놓습니다.

domain1 과 domain2 가 공통된 domain3 을 의존할 수도 있고, domain2 가 domain1을 의존할 수도 있지만, 순환참조는 피하는 편입니다.

[ssi02014]

저는 캐시의 지역성을 기반으로 폴더 구조를 접근하니 "함께 수정되는 파일을 같은 디렉토리에 두기"를 더 깊게 이해하게 되었습니다.

현대 컴퓨터 시스템과 웹 생태계에 있어서 캐시는 굉장히 중요한 요소중 하나입니다.
적절한 캐시 활용과 높은 캐시 히트 비율은 시스템의 전반적인 성능을 향상시키는데 큰 도움이 되며, 이러한 캐시는 효율적으로 동작하기 위해 캐시의 지역성을 기반으로 설계되고 동작합니다.

캐시의 지역성에는 대표적으로 시간 지역성(Temporal Locality)과 공간 지역성(Spatial Locality)이 있습니다.

• 시간 지역성(Temporal Locality)은 특정 데이터나 메모리 주소에 대한 접근이 최근에 발생했을 경우, 가까운 미래에도 다시 접근할 가능성이 높다는 원칙입니다. 예를 들어, 반복문 내에서 같은 변수를 여러 번 사용하는 경우가 이에 해당합니다.
• 공간 지역성(Spatial Locality)은 특정 메모리 주소에 접근한 후, 그 주소와 가까운 다른 주소에 접근할 가능성이 높다는 원칙입니다. 예를 들어, 배열의 첫 번째 요소에 접근한 후 두 번째 요소에 접근하는 경우가 이에 해당합니다.

이러한 캐시 시스템을 개발자 관점에서 접근해봤을 때, 개발자의 뇌(?)를 하나의 캐시라고 가정해보겠습니다. 캐시에 모든 데이터를 담을 수 없듯이, 개발자도 거대한 프로젝트 구조와 맥락을 한번에 파악하기란 굉장히 어렵습니다. 그러나 특정 영역 혹은 폴더 맥락에 집중한다면, 해당 영역에 대한 추가/수정과 같은 처리를 빠르게 할 수 있습니다. (이는 마치 캐시 히트🎯가 발생하는 것과 유사합니다!)

프로젝트를 진행하면서 A라는 특정 기능 혹은 파일이 변경 됐을 때를 생각해보겠습니다.

특정 기능 A를 수정 후에는 우리는 해당 A를 가까운 미래에 다시 변경 할 확률이 높습니다. 예를 들어, 버그 수정, 기능 개선, 코드 리뷰를 통해 다시 A를 수정해야 될 수 있습니다. 이는 캐시의 시간 지역성과 연관 지어 생각해 볼 수 있습니다.

또한, 특정 기능 A가 수정 될 때, 관련된 주변 코드들이 함께 변경 될 확률이 높습니다. 예를 들어, A와 관련된 component, hook, util, test, style 코드 등이 있습니다. 이는 캐시의 공간 지역성과 연관 지어 생각 해 볼 수 있습니다.

이러한 특성을 생각했을 때 함께 수정되는 파일들을 동일한 디렉토리에 위치시키면, 개발자는 더 효율적으로 작업할 수 있습니다. 이는 높은 개발자 캐시 히트율로 이어집니다. 반면, 지역성을 고려하지 않고 폴더 구조를 갖게 된다면, 개발자는 프로젝트 내 여러 폴더를 탐색하며 프로젝트 맥락을 파악해야 하므로 많은 인지적 리소스가 소모(개발자 캐시 미스!😫)될 수 있습니다. 이는 프로젝트 규모가 커질수록 더욱 심화됩니다.

현대 컴퓨터 시스템과 웹 생태계에서 높은 캐시 히트율이 성능 향상으로 이어지듯이, 개발 과정에서도 이러한 개발자 캐시 히트율이 높으면 개발 생산성과 유지보수성이 크게 향상됩니다. 결과적으로 더 나은 개발자 경험(DX)을 제공할 수 있습니다.

[sinibida]

혹시 이 글에서 제시된 디렉토리 구조에 대한 관련 자료들이 더 있을까요? (마치 FSD 아키텍처에 대한 이 공식 문서처럼요.) 토스에서 독자적으로 고안해낸 방법이면 어쩔 수 없겠지만, 그게 아니라면 이러한 디렉토리 구조의 명칭, 예시, 주의점 등에 대해 더 배우고 싶습니다.

최근에 개발 중인 사이드 프로젝트에 이를 적용해볼 생각이라, 이 글의 아이디어에 대해 더 신중하고 면밀히 알아보고 싶네요. 좋은 글 감사드립니다!

[umsungjun]

사내 레거시 프로젝트의 JSP 페이지를 React로 하나씩 마이그레이션하면서, 자연스럽게 "함께 수정되는 파일을 같은 디렉터리에 두기" 방식으로 작업하게 된 점이 신기하게 느껴졌습니다.

개선 전 프로젝트에서는 API 폴더와 Pages 폴더 등등이 분리되어 있어 응집도가 낮았는데, 관련된 코드 파일들을 한 디렉터리로 구성하면서 응집도를 높일 수 있었습니다. 덕분에 구조가 훨씬 개선되었고, 정말 많은 도움이 되었습니다. 감사합니다!🙏