Skip to content

Rule

Jump to bottom
Dongoc edited this page Nov 30, 2020 · 2 revisions

Git

branch 이름 형식

  • 항상 자신의 branch 위치 확인하고 작업하기
  • Jira Issue code와 연결

feature/description/Jira-code feature/create-entity/RE-51

Commit message 형식

  • Jira Issue code와 연결
  • Husky가 현재 Branch 이름을 가져와서 commit을 수정함

description #transition? something I do #complete

  • Husky가 자동으로 최종 형식을 수정함 -> [RE-51] | something I do #complete

  • transitions:

    • #start : todo → in progress (테스크의 첫 커밋)
    • #complete : in progress → review (풀리퀘 직전)
    • #review : review → done (정은님 only)

  • desc:

    • prefix, path, function을 포함해서 구체적이게 서술할 것

PR 형식

  • Jira Issue code와 연결

[Jira-code] | Description

node & npm 버전 통일(추후 지정)

  • node version: 14.15.1
  • npm version:

lint

  • eslint: airbnb style

ESLint Config

Code Style

변수 이름 - Camel-case

  • clientLogin

파일 & 생성자 이름 - Pascal-case

  • ClientSide

Styling code

General

  1. size는 아주 작은 단위(1~2px)를 제외하곤 반드시 rem을 단위로 한다.
  2. 코드는 유사한 속성끼리 인접하게 정리한다. (ex: size / font / position...)
  3. selector는 element.classname의 형태로 사용한다.
  4. element 이름만으로 의미가 전달되지 않는 경우 classname을 추가한다.
  5. transition 타입 선언은 절대 all로 적용하지 않는다. (성능 저하)
  6. animation은 별도의 파일에 작성해 재사용 가능하도록 한다.

Styled-component

  1. 페이지 전반적으로 일관성을 가져야하는 속성은 반드시 theme에 선언해 사용한다.
  2. 제한적 컴포넌트가 아닌 전반적 페이지에서 사용되는 스타일은 Global style에 적용한다(ex: heading, container...)
  3. element 기존의 스타일을 제거해야하는 경우 reset에 작성한다.
  4. 자주 사용되는 style 패턴(utilities)은 theme에 작성해 재사용한다(ex: mt-sm, pd-sm, center)

Atomic Design

atom / module / template 3단계 구분

  1. atom은 classname을 갖지 않는 styled-components로 생성한다. 부모에게서 상속받은 속성을 거스르는 스타일은 지양한다. (ex: align self, position absolute) 고정 크기 값은 최대한 지양한다. (ex: list Item는 width:100%, list에 max width지정)
  2. atom은 모든 가변 값을 props로 상속 받는다.
  3. Variation은 style 확장 문법으로 구현한다.(ex: 같은 형태의 다른 색상 button)
  4. module의 classname은 해당 module을 block으로 기준해 BEM을 적용해 짓는다. 하위 element의 스타일 선언시 nest 문법을 적용한다.
  5. template은 레이아웃과 관련된 속성만 갖는다. (ex: flex, grid, sticky, relative)

Story Book

  1. 모든 styled-component는 story book에서 구현 후 develop 에 추가한다
  2. story book 작업 중 global style, theme에 수정이 필요한 경우 팀원들과 상의한다

js

Naming Reference : https://www.curioustore.com/#!/

라이브러리

  • 합의한 라이브러리 외의 라이브러리를 설치할 경우 미리 슬랙에 알려 정은님의 허락을..받는다

함수

  • 작명 규칙: 길어지더라도 동사형, 함수가 하는 일을 서술적으로 작성한다. carmelCase
  • 이벤트 리스너의 이름은 "handle"로 시작한다.
  • 같은 문맥 안에서 맥락이 같은 기능은 동일한 동사를 사용한다. (ex: add와 insert, delete와 remove 통일) 반대로 유사하지만 다른 맥락의 기능이 있다면 이름으로 역할이 구분되어야 한다.
  • 단일 책임 원칙. 함수는 한 가지 일만 해야한다.
  • DRY. 반복되는 코드는 분리한다.
  • 지역변수는 스코프 최상단에 선언한다.
  • 함수 문단은 위에서 아래로 읽히도록 배열한다.
  • 인수는 최대한 줄인다. 최대 2개를 넘기지 않는다.
  • 함수는 Arrow Function으로 선언할 것.
  • 유효성 검사가 필요할 시엔 early return 시킨다.
  • 비동기 함수는 반드시 try catch 처리한다.

변수

  • 작명 규칙: 명사. carmelCase
  • 조건자와 boolean타입은 is로 시작한다.
  • 의미 구분이 불분명한 이름은 사용하지 않는다. (ex: info와 data)
  • 착시를 일으키는 유사한 이름은 지양한다. (user와 users 대신 userGroup등을 사용)
  • 절대 수정해야하지 말것은 CAPITAL

Console

  • 출력 위치, 목적, 출력 내용이 전달되도록 작성한다.
  • production에선 test console을 모두 제거한다.

주석

  • 가능한 코드만으로 의미가 전달되어야한다. 위의 규칙을 모두 지키려고 노력했음에도 부득이한 경우 주석을 작성한다.
  • 기능의 중요성을 강조하는 경우
  • 경고용 주석
  • test code 표시 (production시 제거)
  • todo 메모

Error Handling

  • production시엔 앱 실행을 중단시킬 수 있는 error는 throw대신 console로 변경한다.

DB

  • 컬렉션 복수형
  • snakecase
  • DB Security Rules (추후 지정)
Clone this wiki locally