✨프로젝트 소개

• 연결 : 경험이 필요한 취준생과 일손이 필요한 기업을 연결해주는 플랫폼
• 역량 증진 : 특정 업무 관련 기술에 대한 학습 및 실습
• 네트워킹 구축 : 업계 전문과들과의 멘토링 기회 제공 및 네트워크 구축

👨‍💻 Members

Codeit FE Sprint 4기 - 2팀

멤버 소개👀

소남주

김영은

박현우

최민혁

황준용

개별 역할

• 소남주
  
  • 회원가입
  • 로그인
  • 무한스크롤
  • 토스트
• 김영은
  
  • 메인페이지
  • 프로필 상세
  • 로고 및 디자인 수정 및 생성
• 박현우
  
  • 가게 정보 등록
  • 공고 상세
  • 프로필 등록
• 최민혁
  
  • 가게 정보 상세
  • 공고 등록
  • 공고 수정
  • 모달
• 황준용
  
  • 헤더
  • 공고 상세
  • 공고 신청
  • 공고 취소
  • 알림

🎞 Duration

2024.04.14(월) ~ 04.30(화)

☀️ Project Topic

신입도 경력을 쌓을 수 있는 플랫폼

💻 Site

https://the-julge.netlify.app/

🛠️ Skills & Tools

📚 Library

💬 Community

🚢 Deploy

---

✨ Feature

_3.1.mp4

---

✨ Project Architecture

🔁 Folder Flow

💡 Git branch strategy : Git flow

---

✨ 초기 세팅 - Convention

1. Naming

변수

• 기본적으로 camel case 적용하되, 상수일 경우 snake case 적용
• boolean 타입의 경우, 앞에 is 붙이기

함수

• 기본적으로 camel case 적용하되, 컴포넌트의 경우 pascal case 적용
• 함수 이름은 명령문 형태로 작성하기
• 이벤트를 다룰 경우에는 handle + 요소 + event 형태로 작성 (ex. handleButtonClick)
• API 요청하는 함수일 경우, 앞에 method 붙이기 (ex. getUserInfo, postIdInfo)

파일

• 모든 파일에 camel case 사용

폴더

• App 안에 들어가는 폴더는 kebab case 사용
• 이외 모든 폴더에 camel case 사용

2. 주석

• API 함수 및 Custom hook에 annotation 작성

/**
 * 특정 수신자의 롤링페이퍼 정보를 조회
 * @param {string} recipientId - 조회할 수신자의 ID
 * @returns {Promise} - 롤링페이퍼 정보를 포함하는 Promise 객체
 */

• 주석 태그 사용

주석 태그	설명	커스텀 주석 태그 여부
TODO	앞으로 해야 할 일	X
FIXME	앞으로 수정되어야 할 일	X
HACK	추후 수정 되어야 할 일	O
XXX	다른 프로그래머에게 문제가 있고 잘못된 코드를 경고	O
BUG, DEBUG	버그가 발생한 위치	O
NOTE	추가 정보 또는 설명을 나타내는 주석	O

1. 커밋 단위

• 1기능 1커밋

2. 커밋 메세지

fix: 로그인이 되지 않는 오류 수정 (너무 길어질 것 같으면 아래에 상세 내용 작성)

- 세부사항 필요할 경우 작성

Tag Name	Description
Feat	새로운 기능을 추가
Fix	버그 수정
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서 수정
Test	테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음
Chore	빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음
Rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove	파일을 삭제하는 작업만 수행한 경우

3. PR

PR 단위

• 1 이슈 1 PR

코드 리뷰 문화: Pn rule

• P1: 꼭 반영해주세요 (Request changes)

  리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

• P2: 적극적으로 고려해주세요 (Request changes)

  작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

• P3: 웬만하면 반영해 주세요 (Comment)

  작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

• P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

  작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

• P5: 그냥 사소한 의견입니다 (Approve)

  작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.