11.7 월 회의록

컨벤션

Git 브랜치 전략 - Git flow + PR

이유

• 브랜치의 구분을 명확히 하기 위해서

종류

• main
  • 개발이 완료된 dev 브랜치를 merge 하여 배포 가능한 상태만을 관리하는 브랜치
• dev
  • 개발이 진행되는 브랜치, 이 브랜치를 기반으로 feat, refactor 등으로 파생됩니다.
  • feat/[기능명][이슈번호(optional)]
    • 새로운 기능을 추가하고자 할 때, 사용하는 브랜치입니다.
  • refactor/[기능명][이슈번호(optional)]
    • 리팩토링이 이루어지는 브랜치입니다.
  • fix/[기능명][이슈번호(optional)]
    • 버그를 수정하기 위한 브랜치입니다.
  • design/[기능명][이슈번호(optional)]
    • 디자인 관련 작업을 하는 브랜치입니다.

코딩 컨벤션

대소문자 컨벤션

• camelCase
  • 일반적인 함수(hook 포함)
  • 일반적인 변수
• PascalCase
  • 컴포넌트 관련한 파일, 폴더, 명
  • class 명
• snake_case
  • DB
  • 상수(영문 대문자 사용)
• kebab-case
  • html 요소

변수 네이밍

• 배열의 이름은 복수형으로 만듭니다.

// 예시

• 반환 값이 boolean 형인 함수나 변수는 is 또는 has 로 시작합니다.
• 매직넘버 사용 금지(변수나 상수로 분리)

순서 컨벤션

• const 는 let 보다 상단에 작성합니다.
• 변수는 사용 시점에 선언 및 할당합니다.
• 선언과 할당을 동시에 하는 변수를 선언만 하는 변수보다 먼저 선언합니다.
• import 순서
  • 외부모듈 -> 내부모듈 -> style -> assets 순서로 작성합니다.

  // 예시
  

  • 선언 그룹 사이에 공백을 둡니다.

.prettierrc & eslint

• 지윤이 가져다 쓰기

프론트엔드 함수 형식

• 선언형 (function foo() {})
  • Hook 등의 로직
  • 유틸 함수 등, 통상적인 함수들
• 화살표 함수 (foo = () ⇒ {})
  • 컴포넌트
  • 콜백 함수
• 클래스 (class Foo {})
  • 생성자로 인스턴스를 만들어야 할 때 (this가 필요할 때)

Router 컨벤션

<Route path='/auth'>
   <Route path='/github' />
   <Route path='login' />
</Route>

• 부모-자식 라우터가 생길 것을 고려하여 컴포넌트 형식으로 작성
  • createBrowserRouter을 사용하면 부모-자식간 상관관계가 직관적이지 않을 우려 있음?

커밋 컨벤션

• 제목은 확실히 적어줍니다.
• 본문은 optional.

# <타입>: <제목> (#1)

##### 제목은 최대 50 글자까지만 입력 ############## -> |


# 본문은 위에 작성
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |
# --- COMMIT END ---
# <타입> 리스트
#   feat    : 기능 (새로운 기능)
#   fix     : 버그 (버그 수정)
#   refactor: 리팩토링
#   style   : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
#   docs    : 문서 (문서 추가, 수정, 삭제)
#   test    : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
#   chore   : 기타 변경사항 (빌드 스크립트 수정 등)
# ------------------
#     타입은 영어로 작성하고 제목과 본문은 한글로 작성한다.
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기
#     본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
#     관련된 이슈번호는 제목 맨 뒤에 추가한다. ex. (#1)
# ------------------

폴더 구조

- client
|- public
   |- assets
      |- images # png jpg
      |- svgs # svg export
   |- index.html
|- src
   |- common # 공용 컴포넌트 (2개 이상의 페이지에서 같이 쓰임)
      |- styles
         |- colors.ts # 색상값
         |- sizes.ts # border size, box size 등 사이즈 공용값
         |- reset.css # 기본 스타일 리셋
      |- hooks
      |- utils
      |- components
   |- pages
      |- TestPage1
         |- TestComponent1 # TestPage1 에서만 사용되는 컴포넌트
         |- TestComponent2
      |- TestPage2
   |- store # 전역 상태관리 상태값들 (redux dispatch 또는 recoil atom)
      |- testState1
         |- atoms.ts
         |- selectors.ts
   |- services # axios 또는 fetch 함수들
      |- fetchTest.ts
   |- types # 타입 값들
      |- test.d.ts
   |- api.ts # axios 를 쓰게 된다면 설정값
   |- App.tsx # 일단은 라우터도 여기로
   |- index.tsx # React가 읽어들이는 엔드포인트
|- prettierrc.json
|- eslintrc.json
|- tsconfig.json
|- package.json
|- .env
- server
|- app.ts
|- 도메인 별로 폴더
|- user // 예시
   |- userController
   |- userService
   |- userRepository
|- utils
   |- ...

기술 스택

언어 - TypeScript

• 프론트와 백에 같은 언어를 사용함으로써, 기본적인 문법을 통일함으로써 더욱 원활한 소통을 할 수 있습니다.
• 코드 작성 시 매번 타입을 결정해야 하기 때문에 번거롭고 코드량이 증가하지만, 정적 타입 언어로 코드 작성 단계에서 에러를 체크할 수 있습니다. 이 장점으로 버그를 발견하고, 해결하는 시간을 단축시킬 수 있습니다.
• any 는 최대한 사용하지 않습니다.

FE

React

• 커뮤니티가 큽니다.
  • Best practice 를 찾기가 쉽다고 생각합니다.
  • 상용화된 라이브러리가 많습니다.
• Angular, Vue 와 달리 React 는 라이브러리기 때문에, JavaScript 언어를 알고 있다면 프론트엔드 지식이 부족해도 이해하기 수월합니다. -> 풀스택 작업이 더 수월해집니다.
  • JSX 문법 덕분에 HTML 과 JS 코드 작성이 효율적입니다.

redux toolkit or recoil(고민 중)

BE

Express vs Nest.js

DB