Skip to content

Home

Jump to bottom
huni edited this page Jan 27, 2023 · 4 revisions

Welcome to the ft_transcendence wiki! 👋

Git 커밋 컨벤션

- Conventional Commits 확장 사용
- incho 의 추천으로 사용하기 시작, 깃모지나 커밋 컨벤션을 지켜주기 때문에 매우매우 편리하다

- ycha: 어... 그... 어... 크크흠.... 어... feat, fix prefix만 붙여도 괜찮지 않나요?
  - 확장을 깔아야 한다는 불편함이 있다
  - vscode를 설치해야만 쓸 수 있다는 문제가 있다 (터미널에서도 쓰고 싶어요)
  - 컨벤셔널 커밋의 옵션들이 너무 많아서 고민이 좀 된다
  • Conventional Commits를 사용하되, 접두사는 필수, 깃모지는 선택.
    • 단 style은 설명에 적혀있는 것처럼 코드 관련 변경사항이 아니라, 디자인 (CSS 등) 관련 변경 사항일 때 사용한다.

Git 브랜치 전략

- ycha: dev, main 브랜치가 필요한 시점은 프로덕트 배포 이후이다.
  - 프로젝트 국룰이긴 한데 굳이? 싶다
  - main만 해도 상관없을 것 같다
- jiychoi: 솔직히 dev만 해도 이미 작동을 잘 하는 (버그 없는) 코드를 올리기 때문에 굳이 매번 dev->main PR을 올릴 필요가 없어보인다
  • main만 둔다
  • 하위 브랜치의 접두사는 Conventional Commits 의 접두사를 따름 (style 포함)
    • [접두사]/[기능명 (자율)] 형식을 따르고, kebab-case 를 따른다.
    • 예시: feat/profile-page
    • 프론트엔드와 백엔드가 같은 레포에 있기 때문에 브랜치명이 겹칠 수 있지만, 유의하고 알아서 잘 짓는다.

파일명 컨벤션

프론트엔드

  • 파일당 함수 하나를 견지합시다.

  • 컴포넌트, 컴포넌트 파일 (일반 컴포넌트, 페이지)

    • 대문자 시작 (PascalCase)
    • 화살표 함수

  • 커스텀 훅, 커스텀 훅 파일

    • 소문자 시작 (camelCase)
    • use 로 시작하게끔 하기 (기존 훅 들과 컨벤션을 맞추기 위함)
    • 선언형 함수

  • 콜백 함수 (함수 안에 인자로 넘기는 함수)

    • 소문자 시작 (camelCase)
    • use 로 시작하지 않게 하기 (커스텀 훅과 겹칠 우려 있음)
    • 함수 안에 인자로 바로 정의할 경우에는 화살표 함수, 그 외에는 선언형 함수

  • 일반 변수, 상태값, 등등...

    • 소문자 시작 (camelCase)

  • 유틸 파일 (그외 함수들)

    • 소문자 시작 (camelCase)
    • use 로 시작하지 않게 하기 (커스텀 훅과 겹칠 우려 있음)
    • 함수는 모두 선언형

  • 스타일 파일 (emotion 사용)

    • 소문자 시작 (camelCase)
    • 지최 습관대로 하기 ([컴포넌트명].styles.ts 확장자로 저장 및 한 파일에 여러 스타일 상수 저장, 클래스명은 kebab-case)
    • Emotion은 템플릿 리터럴형으로 진행

  • 타입, 인터페이스

    • 대문자 시작 (PascalCase)

  • 타입 파일

    • 소문자 시작 (camelCase)
    • 한 파일에 여러 개의 타입 / 인터페이스를 선언해도 상관없다
    • d.ts 확장자로 저장 (ycha 불만있을 경우 레포 분리하겠음)

  • 전역 상태값 관련 파일 (src/store)

    • 소문자 시작 (camelCase)
    • 파일 및 전역 상태값 atom 변수의 이름은 State 로 끝나도록 하기

  • 전역 상수

    • 대문자, SNAKE_CASE
    • 디렉토리나 파일명은 자유롭게 하세요 _

백엔드

  • 파일 하나
    • export 웬만하면 하나
    • 클래스 하나, 함수 하나, type 하나씩 만 들어가도록 하는게 "권고" 사항
    • 클래스인데 param type같은건 같이 export 해도 괜찮
export type Param = {
  name: string;
}

export function hello(option: Param) {...}
  • 클래스
  • 함수

Socket.io 사용 시 프론트엔드 <-> 백엔드간 공유할 이벤트 핸들러 이름

  • API 정의와 영역이 상당히 겹친다
  • 지금 당장은 정하기 조금 애매하다
  • TODO
  • camelCase로 짓기는 확정

변수 네이밍

  • 배열의 이름은 복수형으로 만듭니다. 
    // 예시
chatArray // X
chatList // X
chats // O
  • 반환 값이 boolean 형인 함수나 변수는 is 또는 has 로 시작합니다.
  • 매직넘버 사용 금지(변수나 상수로 분리)

순서 컨벤션

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

import Main from './Main'

import colors from './style'

import icons from './assets'
    • 선언 그룹 사이에 공백을 둡니다.

.prettierrc & eslint

  • 지윤님이 쓰시던 규칙 사용

프론트엔드 함수 형식

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

프론트엔드 함수 이름

  • 핸들러 함수
    • handle + 동사 + 목적어
    • 예시: handleClickButton, handleSubmitForm

프론트엔드 함수 선언 위치

  • 컴포넌트 안에서 사용되는 핸들러 함수의 경우, 컴포넌트 안에 선언하되 useCallback으로 감싸줄 것 (재선언 방지)
  • setStateAction을 호출하는 핸들러 외의, 기타 유틸 함수들은 컴포넌트 밖에 선언할 것

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     : 기타 변경사항 (빌드 스크립트 수정 등)
#   structure : 공통 구조 작업
# ------------------
#     타입은 영어로 작성하고 제목과 본문은 한글로 작성한다.
#     제목 끝에 마침표(.) 금지
#     제목과 본문을 한 줄 띄워 분리하기
#     본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
#     관련된 이슈번호는 제목 맨 뒤에 추가한다. ex. (#1)
# ------------------

# 그라운드 룰
1. 의견 제시 했을 때 마다 박수치기
2. `any` 쓰면 사형 → [#42seoul_global_random](https://42born2code.slack.com/archives/CU6MTFBNH)에 애니 추천하기(다른 사람이 애니 정해주기)
3. 최소 맡은 것에 대한 책임을 저야함 (특정 분야의 선택은 그 사람이!)
4. prettier, eslint 안지키면 → 사형
5. 오후 10시 ~ 다음날 오전 10시 (스크럼 시간 시작 직전) 까지, 슬랙 털기 금지 (12시간동안 임시 휴전)
6. 스크럼 안오면 애니 추천하기 (빠질 때마다)
  - 현재 누적횟수 ycha 1회, jasong 1회 -> 지최한테 덤핑함. 지최는 이를 기억할 것입니다
Clone this wiki locally