팀프로젝트 그라운드 룰

적용할 기술 선택

• Front-End

• Back-End

• Test

코딩 컨벤션 👨‍💻👩‍💻

• eslint를 사용하여 코딩 스타일 통합
• 어떤 lint 스타일을 적용할 것인가?
  • 기본 룰은 airbnb 스타일 사용. 추후에 불편한 rule을 추가하여 조정.

네이밍 규칙

1. 함수명과 변수명 등 축약하지 않기

img 🙅‍♀ => image🙆‍♂

btn 🙅‍♀ => button🙆‍♂

2. wrapper vs container ✅

3. 반복문은 최대한 지양

   만약에 사용했을 경우, 변수 i -> j -> k

   for(let i = 0 ; ; )
       for(let j = 0 ; ; )
           for(let k = 0 ; ; )

4. 고차함수 index=> idx

   reduce(acc,item, idx)
   forEach(item, idx)

5. 그 외에

   const index = 0 ;
   const selectedCardIndex = ... ; 

6. 그 외는 리뷰를 통하여 조정하기.

컴포넌트 이름 규칙

기존 태그를 대체하는 것

• prefix : Custom을 붙인다.
• styled를 지정하는 변수명 = 기존 태그명 그대로 사용
  • CustomButton

복합적인 컴포넌트 구조를 구현할때

postfix:

xxContainer
    xxHeader
    xxBody
        xxItem

작업 분배

• 이슈, 마일스톤, 프로젝트로 관리하기
  • 마일스톤 기간은 일주일.
• 각 이슈를 가져가서 작업하기
• 데일리 스크럼 때 어떤 이슈 맡을 것인지 얘기하기

커밋 메세지 규칙

• Feat: 새로운 기능을 추가할 경우.

• Fix: 버그를 고친 경우.

• Docs: 문서 수정한 경우.

• Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우.

• Refactor: 프로덕션 코드 리팩터링.

• Test: 테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 없음).

• Chore: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음).

PR 규칙

• 몇 명이상 approve 해야 merge 가능한지

  • 본인 제외하고 최소 2명이 approve해야 merge한다.

• 퇴근시간 최대 21시❗️❗️❗️

• 브랜치 전략은?

  fork 해서 작업한 내용 push -> 원본 저장소에 pr -> 리뷰후 merge

  1 issue === 1 pr(to master) (뱅크샐러드-하루에-1000번-배포하는-조직-되기)

• commit 단계에서 유닛테스트를 통과해야만 pass 되도록 설정해서 버그를 줄이면 좋을 것 같음.

  -> githooks 로 처리 가능

  -> pre-commit

  commit -> lint-staged -> perttier -> eslint -> test -> done.

• merge할 때 이슈 관리

코드리뷰

이슈 처리를 완료하여 pr 요청을 보낸다.

pr 작성 시 리뷰어를 모든 팀원을 지정한다.

슬랙으로 @here로 pr 한 사실을 팀원에게 독촉한다.🤗🤗🤗

팀원은 코드를 보고 리뷰를 한다.🙆‍♂🙅‍♀