리팩토링 1. 디렉토리 구조 개선

Gn0lee·2022년 11월 20일
0

Tech 이모저모

목록 보기
9/18

기존 디렉토리 구조

이전 글에서 언급했듯이 기존 디렉토리 구조는 작은 프로젝트에 적합했다. 이전 프로젝트 디렉토리 구조는 아래와 같다.

components외의 디렉토리들은 모든 페이지가 공유를 해도 양이 많지 않아서 크게 어려움이 없었다.(사실 어렵긴 했다.) components는 문제가 많았다. components내 molecules같은 디렉토리는 components를 atomic design 기준으로 나눈 것이다. 하지만 프로젝트 내 컴포넌트들은 atomic design 기준으로 명확하게 나뉘지 않았다. 디자인 요소 없이 비지니스 로직만 수행하기도 하고 컴포넌트간 관계가 복잡해지자 명확하게 나누기가 어려웠다. 예를 들면 내가 새로 만드려는 컴포넌트에서 molecule에 있는 컴포넌트를 사용하여 cell로 만들려 했는데 다른 팀원이 organism에 비슷한 컴포넌트를 만들었다면 어떻게 해야하는지 난감했다. 서로간의 명확한 기준없이 작업을 시작하다보니 오차가 생겼고 오차는 계속해서 쌓여 풀 수 없는 지경에 이르렀다.

그리고 페이지의 수가 늘어나면서 4개의 디렉토리에 모든 컴포넌트들이 위치하다보니 한 디렉토리에 너무 많은 컴포넌트가 존재했다. 물론 vscode로 직접 검색해서 파일을 찾을수 있지만 깃헙에서 직접 코드를 찾을 때나 index.ts의 관리가 어려웠다. 그래서 feauture 별로 디렉토리를 분리하였다. 각 feature는 작은 프로젝트와 같은 디렉토리로 구성되었다. 이 경우 프로젝트의 디렉토리 구조는 복잡해지지만 한 기능은 해당 기능의 디렉토리 안에서만 생각하면 되기 때문에 유지보수가 편한 면이 있었다.

변경된 디렉토리 구조

우선 프로젝트내의 큰 기능을 중심으로 features를 구성했다. 하지만 feature들에서 공통으로 사용하는 코드들이 존재했다. 이런 코드들은 common 폴더에서 관리하였다. 그리고 context, thunk, data, layout 디렉토리를 새로 추가하였다. 우선 context는 각 feature에서 사용하는 redux slice와 useReducer 훅에서 사용되는 리듀서 파일을 포함했다. 그리고 thunk는 Redux thunk에서 사용하는 thunk 함수들을 포함했다. data는 json, 상수등의 데이터 관련 파일들을 포함했으며 layout은 페이지의 레이아웃을 결정하는 컴포넌트로 이루어졌다. layout은 common 폴더 내에만 생성하였다.

이렇게 나누고 나니 유지 보수가 편했다. 이전에는 상수를 utils 폴더 내 constants.ts에서 모두 관리하여 혼란 그 자체였다. 하지만 개편 후 data폴더 내 constants.ts에서 관리하여 해당 feature에서 사용하는 상수만 관리하여 유지보수가 간편해졌다.

추가적으로 개선해야하는 점

현재 다국어 json파일은 common/locale에서만 관리한다. 전체 프로젝트의 text key를 하나의 json 파일로 관리하기 때문이다. 하나의 text key를 수정할 때마다 정말 고역이다. 따라서 다른 디렉토리처럼 feature별로 나누어서 관리할 예정이다.

느낀점

처음 프로젝트 시작때는 디렉토리 구조가 중요하지 않다고 생각했다. 하지만 프로젝트의 크기가 커지면서 불편함이 하나하나 생기기 시작했다. 그래서 프로젝트 시작 시 프로젝트의 규모를 대략 짐작하여 적절한 디렉토리 구조를 설정하고 시작하는 것이 좋겠다는 생각을 했다. 마지막으로 디렉토리 구조에 정답은 없고 프로젝트의 성격에 맞추어 유연하게 계획하는 것이 좋은 것 같다.

profile
정보보다는 경험을 공유하는 테크 블로그입니다.

0개의 댓글