폴더구조를 잡는것은 어렵다
그냥 마구잡이로 프로젝트 폴더들을 구성하다가
이건 어디에 들어가야하지?
이 부분은 왜 이렇게 코드가 길어지지 하는 고민을 자주 하게되고
그럴때 마다 새롭게 프로젝트 구조를 고민하게 된다...
어떤 블로그에서 폴더구조에 관한 글을 봤다
여기서 배울점이 많다고 생각해서 내 프로젝트와 비교하면서
블로그에 있던 글을 정리하며 읽어보려고 한다
현재 프로젝트구조
현재 내 프로젝트 폴더는 이렇게 구성되어있다
리덕스 공식사이트에서 권장하는 폴더구조를 따른것인데
app에 앱전체설정, 레이아웃, store, 리액트의 root진입점이 있고
common에는 나머지 일반적으로 사용되는것들
fetures에서는 전역상태가 관리되어야 하는 기준이 되는 기능별로 폴더를 잡는다. 리덕스 액션들이 모여있는 slice와 함께 하나의 동작하는 컴포넌트가 만들어진다
헬퍼함수와 유틸함수
헬퍼함수와 유틸함수의 차이점은 프로젝트에 대한 종속성이라고 한다
그러니까 헬퍼함수보다 유틸함수가 더 추상화된것이고 모든 프로젝트에 사용될 수 있다
1)유틸함수
자바스크립트의 내장함수나 lodash의 함수들을 생각하면 된다고 한다
2)헬퍼함수
헬퍼함수는 절차지향적으로 기능을 구현할 수 있지만
이렇게 구현한 소스는 기능을 수정하거나 추가하기가 점점 힘들어진다
그러므로 유지보수성을 고려해서 함수들을 분리하고
컴포넌트 부분은 최대한 hooks와 함수들의 구현부는 보이지않도록
선언적으로 유지하기위해 헬퍼함수를 사용한다
함수별 정리와 기능별 정리
스프링에서도 아키텍쳐의 분류별로 정리하는것과 도메인별로 정리하는것이 나뉘는데
후자가 개념적으로는 프로젝트가 분리될때 유연하고 코드응집도가 높아져서 좋지만
도메인이 명확하고 비즈니스로직을 잘 알지못할경우에는
제대로 분류되지 못하고 중구난방으로 섞일수가 많을때는 전자가 더 낫다
프론트엔드의 경우에도 마찬가지로 프레젠테이션로직은 프론트엔드 개발자가 유연하게 설정할 수 있지만
컴포넌트를 생성할때마다 해당컴포넌트가 속하는 위치를 잘 결정할 수 있는것이 어렵다
예를들어 이런것이다
특정 사용자를 검색하는 컴포넌트를 만들경우 이 컴포넌트는 user에 속할까 search에 속할까?
이런문제들이 있지만 적어도 어디를 찾아봐야 할지가 명확해진다는 점에서
기능별로 분리하는것이 좋다고 한다
나같은경우에는 오직 fetures 폴더안에서만 기능별로 정리하고
features보다 상위에서는 함수별로 정리하고 있다
별칭
현재 프로젝트에서 사용하고 있는 별칭들이다
분류별로 별칭을 사용하고 있다
상태관리
내 경우에는 상태관리를 위해 기능별로 폴더를 만들고
기능을 담당하는 slice가 너무 커지거나 따로 분리할 필요가 있다고 생각이 들면
하위폴더에 slice를 하나 더 만들어서 관리하고있다
정리
프로젝트를 진행하다보면 파일하나에 몇백줄은 우습게 넘어가버리는
처참한 내 코드를 볼수가 있는데 위 블로그 내용을 고민하면서
가독성도 좋고 유지보수하기에도 편리한 프로그램을 만들 수 있는 사람이 되고싶다
주관적인 분류별로 작성했던 컴포넌트들을 최대한 기능별로 잘 나눠서
필요한위치에 존재하도록 마치 프로바이더처럼 hook, helpers, type을 만들고
필요한 경우에는 slice도 만들자
하지만 constants와 util과 같은 전역에서 사용되는것들은 common에 그대로 두자
참고자료
리덕스공식사이트 추천 폴더구조
