[🐾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 프로젝트 생성 방법

https://vitejs.dev/guide/

Vite

npm create vite@latest my-react-ts-app -- --template react-ts

Vite 는 기본적으로 리액트와 타입스크립트를 지원하기 때문에 지원하는 템플릿으로 쉽고 빠르게 생성할 수 있다.

https://www.toptal.com/developers/gitignore

gitignore.io

자동으로 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/

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/

우리 팀을 위한 ESLint, Prettier 공유 컨피그 만들어보기 | 우아한형제들 기술블로그

 

// .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 한다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

---

협업을 시작하며 타인의 코드를 읽는 것이 가장 어려운 부분이기도 한데

미리 코드 컨벤션이나, 깃컨벤션 등 설정을 함께 지정하게 되면 시간은 많이 소요 되더라도

추후 코드 관리나 리팩토링, 진행사항 등을 보기 쉽기 때문에 꼭 필요한 과정이라고 생각한다.