폴더 구조화 고민

Cafe POS를 개발하면서 프론트엔드 코드는 React.js을 기본으로 해서, SSR 기능이 있는 Next.js와 코드의 안정성을 위한 TypeScript을 함께 사용해 작성하고 있다.

 

특히 React.js가 여러 컴포넌트를 조합해서 동적으로 UI를 만드는 특징을 갖고있는 만큼 파일이 많아질 수밖에 없어서 여러 파일들을 쉽게 관리하기 위해서 다음과 같이 폴더를 구조화했다.

/my-app
|-- /src
    |-- /components
        |-- /MenuPanel
        	|-- MenuPanel.tsx
        	|-- MenuBlock.tsx
        	|-- Category.tsx
            
        |-- /NavBar
        	|-- Clock.tsx
        	|-- NavBar.tsx
        |-- MenuEditorForm.tsx
        |-- MenuOrderForm.tsx
        |-- SlideMenu.tsx
    |-- /pages
        |-- index.tsx 
        |-- _document.tsx 
        |-- _app.tsx 
        |-- /api
        	|-- ... (API 요청 코드 모음 파일들)
    |-- /store
    	|-- store.ts 
    	|-- /slices 
       		|-- ... (Redux slice 파일들)
    |-- /styles 
    	|-- global.css  
    |-- /types  
    	|-- menuType.ts
        |-- optionType.ts
    |-- /utils   
    	|-- colorVarient.ts

 

 

이렇게 폴더를 구조화함으로써 다음과 같은 효과를 볼 수 있었다.

 

1. 파일의 역할에 따라서 어느 위치에 파일이 있는지 한 눈에 파악할 수 있다는 장점이 있다.

2. 지금 나는 이 애플리케이션을 개인적으로 만들고 있지만, 팀 프로젝트였다면, 팀원들과 협업하기에도 좋고, 가독성 또한 높일 수 있었다.

3. 코드를 실행해 어떠한 오류가 발생했을 때, 문제가 되는 부분을 바로 찾아가서 확인할 수 있어 편했다.

4. 공통으로 사용하는 컴포넌트 파일들과 api 및 interface들을 작은 조각으로 나누어 놓으면, 어느 곳에서든 import만 하면 되니까 재사용성도 높아질 수 있으니, 코드 중복을 줄일 수 있어 효율성 제고의 면도 도모할 수 있었다.

5. 데이터 타입 정의나 공통 함수 등의 추상화를 통해 전체 시스템의 복잡도를 줄일 수 있었다.

6. styles나 types처럼 특정 범위 내에서만 유효한 변수나 함수 등을 관리할 수 있어서 스코핑(scoping) 문제로부터 자유롭게 코드를 작성할 수 있었다.

7. API 호출 로직들이 한 곳(api 폴더)에 모여있기 때문에, 새로운 API 추가나 기존 API 수정 시 해당 폴더만 확인하면 되기 때문에 많은 시간을 절약할 수 있었다.