🤝 팀 프로젝트 3차 회의(6/7)

페이지 구성

1. 로그인 페이지

2. 회원 가입 페이지

3. 메인 페이지

4. 알람 페이지

5. 프로필 페이지
• 프로필 이미지
• 온라인 여부
• 글
• 좋아요
• 팔로워
• 팔로우

6. 프로필 수정
• 프로필 사진
• 이름
• 이메일
• 비밀번호

7. 상세 게시글( 모달 )

8. 글 작성 페이지

9. 404 페이지

10. DM ( 후순위 )

컨벤션 룰

🤗 Naming

파일명

• 파일명은 기본적으로 PascalCase로 작성한다.

• style은 컴포넌트 파일과 함께 작성한다.(emotionJS)

변수명

• 변수명은 기본적으로 camelCase를 사용한다.

• 가능한 명사를 사용한다.

• 복수의 경우 복수형 명사를 사용한다.

• boolean 형을 갖는 변수는 앞에 is를 붙인다.

함수명

• 함수명은 기본적으로 camelCase를 사용한다.

• 가능한 동사를 사용한다.

• 함수명을 축약하지 않는다.

• boolean형을 return하는 함수는 앞에 check를 붙인다.

스타일

• 공통 스타일 속성, 변수는 메인 Stylesheet에 정의

• 이후 각 컴포넌트마다 해당하는 스타일을 emotion/styled-components 로 정의

• 스토리북을 통해 컴포넌트 구현 및 테스트 진행

🙄 Issue Conventions

• Issue 내용은 Todo-List 형식으로 작성한다.

• Issue 단위는 기능 단위로 작성한다.

• Issue 명
• feat / Issue 명
• fix / Issue 명

👊 Commit Message Conventions

• 커밋 시 아래 규칙을 참고해 메세지를 작성하자, 영어로 작성할 필요는 없다.

• issue-number는 Github의 issue를 발급하고, 생성된 번호를 사용한다.

[#{issue-number}] feat: ~(Ex. 좋아요) 기능 추가
[#{issue-number}] fix: ~ 버그 수정
[#{issue-number}] refactor: ~ 코드 리펙토링
[#{issue-number}] docs: ~ 문서 수정
[#{issue-number}] style: ~ 코드 포맷팅, 세미콜론 추가 / 변경
[#{issue-number}] design: ~ 스타일 추가 / 변경
[#{issue-number}] test: ~ 테스트 추가 / 변경

😾 Github branching

• main : 배포 (버전)

• dev : development branch

• feature/{issue-number}-{desc..} : 기능 구현 branch

• fix/{issue-number}-{desc..} : 버그 수정 branch

• branch는 camelCase로 작성한다.

• Pull Request는 Merge 전 Reviewer의 approve는 선택 사항

• feature -> dev ->(배포) main

👶 Code

• VS Code의 eslint와 prettier extention을 활용한다.

• eslint는 Airbnb 사용한다.

• 버그가 있으면 커밋 할 수 없다.

• 한 메서드에 오직 한 단계의 들여쓰기(두 단계까진 봐줌)를 하기 위해 노력한다. (3단계 안 들어가도록?)

• else 예약어는 권장하지 않음

• 상수는 두 파일 이상 사용할 경우 별도의 파일로 분리해서 작성한다.