[🐾JellyDiary] 프론트엔드 협업 프로젝트 초기 세팅
이번 🐾JellyDiary 프로젝트를 시작하기에 앞서
프론트엔드 개발자 간에 협업을 위해 미리 정해 둘 코드 컨벤션이나, 깃 컨벤션, 폴더구조 초기 셋팅 등을
정리해 보고 자 한다.
1. 들어가며
가장 먼저 정해야 할 것들은 어떤 기술 스택을 이용하여 개발을 할 건지 논의를 하였다.
이번 프로젝트는 기본적으로 React (리액트) + TypeScript(타입스크립트) + Vite(비트) 로 빠르고 안정성을 높인 구조로 진행하기로 하였으며,
서버 상태 관리를 위해 React Query(리액트 쿼리) 를 이용하여 캐싱을 효율적으로 관리하고 Redux(리덕스) 대신 Zustand(주스탠드) 를 도입하여 불필요한 렌더링을 최소화 하고 빠른 도입을 진행해 보기로 하였다.
스타일은 Styled-Component(스타일드 컴포넌트)를 적용하여 CSS in JS 기반 코드를 작성하여 확장성과 애니메이션 효과를 높여 보기위해 선택하였다.
이외에 React Router를 이용하여 path 기반 라우팅을 처리할 수 있도록 할 예정이다.
이에따른 코드 컨벤션과 , 개발할 기능에 맞춘 디렉토리 구조를 먼저 설계하였다.
와이어 프레임 등 UI 를 작업하기 위해 피그마를 이용하였고 코드 버전 관리 및 협업을 위해 Git&Github 설정도 마쳤다.
Jira를 이용하여 작업 프로세스를 관리하는데 1-2주의 스프린트 기간에 맞게 개발 일정을 미리 정해놓고 개발 후 해당 지라 티켓에 맞춰 커밋 컨벤션도 작성해볼 예정이다.
2. 프로젝트 파일 생성 및 .gitignore 파일 세팅
React + TypeScript + Vite 프로젝트 생성 방법
npm create vite@latest my-react-ts-app -- --template react-ts
Vite 는 기본적으로 리액트와 타입스크립트를 지원하기 때문에 지원하는 템플릿으로 쉽고 빠르게 생성할 수 있다.
https://www.toptal.com/developers/gitignore
자동으로 Vite 에서 .gitignore 파일을 생성해 주지만
gitignore.io에서 프로젝트에 맞는 파일을 생성할 수도 있다.
# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*
node_modules
dist
dist-ssr
*.local
# Editor directories and files
.vscode/*
!.vscode/extensions.json
.idea
.DS_Store
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?
3. 프로젝트 디렉토리 구조 설계
https://woochanleee.github.io/project-tree-generator/
현재 작업중인 깃헙 주소를 입력하면 자동으로 트리 구조를 생성해 주는 제네레이터도 있다.
```
📦 app
├─ public --> 정적 파일 및 HTML 파일이 저장되는 폴더
├─ src --> 앱의 소스코드가 저장되는 폴더
│ ├─ assets --> 이미지(.png, .svg) 등이 저장되는 폴더
│ ├─ axiosInstance --> Axios API 요청과 관련된 폴더
│ ├─ components --> 공통 컴포넌트를 저장하는 폴더
│ ├─ hooks --> Custom Hooks 를 저장하는 폴더
│ ├─ mocks --> MSW(MockServiceWorker) 관련 폴더
│ ├─ pages --> 각 페이지에 대한 레이아웃 이나 로직 컴포넌트 폴더
│ ├─ react-query --> React Query 관련 폴더
│ ├─ store --> 상태 관리 관련 폴더
│ ├─ types --> 타입 관리 관련 폴더
│ ├─ App.tsx
│ ├─ main.tsx
│ └─ vite-env.d.ts
├─ index.htm
├─ .gitignore
└─ pakage.json
```
©generated by [Project Tree Generator](https://woochanleee.github.io/project-tree-generator)
4. 코드 가이드라인 및 스타일 가이드라인 설정
// 폴더의 루트 파일은 index.tsx 로 생성
// import
1. 라이브러리
2. 컴포넌트
3. store, utils, hooks, type
4. Styled-Components
5. 그 외
// Type
interface [컴포넌트명]Props {}
// 함수형 컴포넌트
const [Name]: React.FC<[컴포넌트명]Props> () => {
// 상태(useState() or Zustand)
// params
// react-query
// (useRef())
// useEffect()
// 이벤트 핸들러
return (
<>
</>
);
}
프론트엔드 멘토링을 통해 코드의 통일성을 위해 팀 그라운드 룰을 정하기로 하였고,
ESLint 나 Prettier을 적극 활용하면 좋겠다는 조언을 받았다.
실제로 구글에서는 코드 통일을 위해 코드 컨벤션을 검사하는 직책이 따로 있을 정도로
엄격한 회사도 있다고 한다.
참고 블로그 : https://techblog.woowahan.com/15903/
// .eslintrc.cjs
module.exports = {
root: true,
env: { browser: true, es2020: true },
extends: [
"eslint:recommended",
"plugin:@typescript-eslint/recommended",
"plugin:react-hooks/recommended",
"plugin:@tanstack/eslint-plugin-query/recommended",
],
ignorePatterns: ["dist", ".eslintrc.cjs"],
parser: "@typescript-eslint/parser",
plugins: ["react-refresh"],
rules: {
"react-refresh/only-export-components": [
"warn",
{ allowConstantExport: true },
],
},
};
// .prettierrc.cjs
printWidth: 100,
trailingComma: 'all', // 기본값
tabWidth: 2, // 기본값
semi: true, // 일부 코드에서 라인의 시작 부분에 세미 콜론 추가
singleQuote: true,
bracketSpacing: true, // 기본값. true인 경우 {foo:bar}는 { foo: bar }로 변환됨
arrowParens: 'always', // 기본값
useTabs: false, // 기본값
5. 프레임워크 및 라이브러리 기본 설정
// package.json
// ...
"dependencies": {
"@fullcalendar/core": "^6.1.11", --> 다이어리 캘린더 라이브러리
"@tanstack/react-query": "^5.31.0", --> 서버상태관리 : 리액트 쿼리(tanstack)
"@tanstack/react-query-devtools": "^5.32.0", --> 리액트 쿼리 개발자 도구
"@types/styled-components": "^5.1.34", --> Styled-Components(ts)
"axios": "^1.6.8", --> API 호출을 위한 axios
"react": "^18.2.0",
"react-dom": "^18.2.0",
"react-icons": "^5.0.1", --> 아이콘 라이브러리
"react-router-dom": "^6.22.3",
"styled-components": "^6.1.8",
"zustand": "^4.5.2" --> 클라이언트상태관리 : Zustand
},
"devDependencies": {
"@tanstack/eslint-plugin-query": "^5.28.11",
"@types/react": "^18.2.64",
"@types/react-dom": "^18.2.21",
"@typescript-eslint/eslint-plugin": "^7.1.1",
"@typescript-eslint/parser": "^7.1.1",
"@vitejs/plugin-react": "^4.2.1",
"eslint": "^8.57.0",
"eslint-plugin-react-hooks": "^4.6.0",
"eslint-plugin-react-refresh": "^0.4.5",
"msw": "^2.2.13",
"prettier": "^3.2.5",
"typescript": "^5.2.2",
"vite": "^5.1.6"
},
"msw": {
"workerDirectory": [
"public"
]
}
공통적으로 사용할 라이브러리는 미리 설정하여 팀 내 공유를 하는 것이 편하다.
+ JIRA & Github 커밋 컨벤션
Jira를 이용하여 티켓 넘버를 만들 수 있는데 이를 이용해서 작업한 내용과 관련 업무를 태그하여
작업을 자동화 할 수 있다.
[{Jira Issue Number}] <TYPE> : Short Description
[JD-1]Feat: 새로운 파일을 추가했습니다.
### Commit Type
`Feat` - 새로운 기능 추가
`Fix` - 버그 수정
`Build` - 빌드 관련 파일 수정
`Util` - config 관련 파일 수정
`Ci` - CI관련 설정 수정
`Docs` - 문서 (문서 추가, 수정, 삭제)
`Style` - 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없는 경우)
`Design` - UI 변경 (CSS 작업)
`Refactor` - 코드 리팩토링
`Test` - 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없는 경우)
`Chore` - 기타 변경사항 (빌드 스크립트 수정 등)
📢 커밋 규칙
- 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
- 1개의 커밋에는 1개의 행위만 들어 있게 한다.
- 읽는 사람이 이해하기 쉽도록 작성한다
[{Jira Issue Number}] <TYPE> : Short Description
## **변경 내용**
[{Jira Issue Number - SUB TASK}]
기존 내용에서 변경된 사항을 before -> after 형식으로 작성해주세요.
description
- 작업 이유, 작업 내용, 리뷰어가 알아야 할 내용, 이미지 등을 상세하게 명시한다.
- 한글로 작성한다.
📢 PR 규칙
- 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다. (가급적 API단위로 PR작성)
- 리뷰어가 코딩 스타일을 리뷰하지 않도록 코드 컨벤션을 잘 지킨다.
- 정상적으로 동작하는지 테스트하고, 정상적인 경우에만 PR 한다.
- 한글로 읽는 사람이 이해하기 쉽도록 작성한다.
협업을 시작하며 타인의 코드를 읽는 것이 가장 어려운 부분이기도 한데
미리 코드 컨벤션이나, 깃컨벤션 등 설정을 함께 지정하게 되면 시간은 많이 소요 되더라도
추후 코드 관리나 리팩토링, 진행사항 등을 보기 쉽기 때문에 꼭 필요한 과정이라고 생각한다.