✨ 프로젝트 소개 Notion
- 사용자의 휴대폰 QR코드로 음식 주문이 가능한 비대면 주문 결제 서비스 구현
- 팀원 4명
- 2024.05.24 ~
-
회원가입 및 로그인
아이디 및 비밀번호 찾기
비밀번호 변경
기간별 매출 및 제품별 매출 조회
매출 대시보드
메뉴 및 옵션 추가/관리
회원 조회
점포 관리(가게 설정, 비밀번호 변경하기)
-
사용자 모드 메뉴
메뉴 선택
장바구니
직원 호출
-
포스 화면
테이블 합석, 이동, 분리
테이블 단체지정 및 결제
주문내역
환경설정 (테이블 구조 변경)
| 이정찬 | 김세진 | 이지언 | 정건희 |
|---|---|---|---|
|
|
|
|
| 팀원 | Back-End | Front-End |
|---|---|---|
| 🐶 이정찬 | 메뉴 판매 주문 영수증 환불 | 로그인 및 회원가입 포스 환경설정 |
| 🦝 김세진 | 메뉴 추가, 수정, 삭제 카테고리 추가, 수정, 삭제 옵션이름 추가, 수정, 삭제 옵션제목 추가, 수정, 삭제 | 사용자 메뉴 선택 사용자 메뉴 상세보기 장바구니 |
| 🐰 이지언 | 회원가입 및 로그인 관리자 비밀번호 변경 아이디 및 비밀번호 찾기 임시 비밀번호 전송 총 매출 조회 선택된 날짜 매출 조회 |
로그인 및 회원가입 CSS 매출 대시보드 기간별 매출 조회 메뉴별 매출 조회 포스 주문 화면 |
| 🐨 정건희 | 아이디 및 비밀번호 찾기 임시 비밀번호 전송 서버 헬스 체크 서버 env 확인 | 메뉴 간편 조회 메뉴 리스트 조회 메뉴 상세 조회 포스 주문 상세 화면 |
| 공동 작업 | 디자인 도안 작업 Front 명세서 작성 API 명세서 작성 DB 설계 |
- 해당하는 업무에 대해 GitHub Issue를 생성합니다.
- GitHub Actions에 의해 자동으로 생성된 브랜치로 전환하여 해당하는 업무를 진행합니다.
- 작업을 완료하면 각자의 생성한 브랜치에서 코드를 push합니다.
- PR(Pull Request) 을 오픈합니다.
- 팀원들의 코드 스타일은 다같이 공유하며 서로 잘 이해할 수 있도록 다 같이 정리하는 시간을 가지도록 하였습니다.
- PR이 merge되어 close 되면 해당 이슈는 자동으로 Done상태로 변경됩니다.
- 📋 GitHub Issues(Front) &
GitHub Issues(Back)
- 간편한 이슈 생성을 위해 이슈 템플릿을 만들어 사용했습니다. + 팀원이 현재 어떤 작업을 진행하고 있는지를 바로 알 수 있어 의사소통 비용을 줄일 수 있었습니다.
- 📁 GitHub Projects
- 칸반 보드로 프로젝트 진행 상황을 한 눈에 확인할 수 있어 일정을 관리하기 수월했습니다.
-
개발과 동시에 지속적으로 배포를 진행할 것이 아니라, 기능을 모두 개발하고 최종적으로 배포를 할 예정이었기 때문에 Git flow에 비해 흐름이 단순해짐에 따라 그 규칙도 단순한 GitHub Flow 전략이 적합하다고 생각했습니다.
-
프로젝트 기간 동안 팀원들이 같은 시간에 작업하기 때문에 잦은 충돌이 발생할 것을 우려하여 충돌의 크기를 줄이고자 GitHub Flow 전략을 채택하여 작은 단위로 이슈를 쪼개 이슈 별로 브랜치를 분기하고 main 브랜치에 지속적으로 merge 하는 방식으로 진행했습니다.
-
기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request기능을 사용하도록 권장하였습니다.
팀원 간의 원활한 소통과 협업을 위해 커밋 컨벤션과, 코드 컨벤션을 만들어 이를 따랐습니다.
1. 커밋 유형 지정 - 커밋 유형은 영어 대문자로 작성하기 - 커밋 유형 - Feat : 새로운 기능 추가 - Fix : 버그 수정 - Docs : 문서 수정 - Style : 코드 formatting, 세미콜론 누락, 코드 자체의 변경이 없는 경우 - Refactor : 코드 리팩토링 - Test : 테스트 코드, 리팩토링 테스트 코드 추가 - Chore : 패키지 매니저 수정, 그 외 기타 수정 ex > .gitignore - Design : CSS 등 사용자 UI 디자인 변경 - Comment : 필요한 주석 추가 및 변경 - Rename : 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우 - Remove : 파일을 삭제하는 작업만 수행한 경우 - !BREAKING CHANGE : 커다란 API 변경의 경우 - !HOTFIX : 급하게 치명적인 버그를 고쳐야 하는 경우
🧾 2. 제목과 본문을 빈행으로 분리
- 커밋 유형 이후 제목과 본문은 한글로 작성하여 내용이 잘 전달될 수 있도록 할 것
- 본문에는 변경한 내용과 이유 설명 (어떻게보다는 무엇 & 왜를 설명)
#️⃣ 3. 제목 첫 글자는 대문자로, 끝에는 . 금지
↩️ 4. 제목은 영문 기준 50자 이내로 할 것
⏺️ 5. 자신의 코드가 직관적으로 바로 파악할 수 있다고 생각하지 말자
👆 6. 여러가지 항목이 있다면 글머리 기호를 통해 가독성 높이기
✝ 7. 깃 이슈 네임 등록 할 때 ex > [ 메뉴관리BE ] 메뉴등록
🛼 문자열을 처리할 때는 쌍따옴표를 사용하도록 합니다.
🐫 문장이 종료될 때는 세미콜론을 붙여줍니다.
💄 함수명, 변수명은 카멜케이스로 작성합니다.
🐫 가독성을 위해 한 줄에 하나의 문장만 작성합니다.
❓ 주석은 설명하려는 구문에 맞춰 들여쓰기 합니다.
🔠 연산자 사이에는 공백을 추가하여 가독성을 높입니다.
🔢 콤마 다음에 값이 올 경우 공백을 추가하여 가독성을 높입니다.
💬 생성자 함수명의 맨 앞글자는 대문자로 합니다.
🔚 var는 절대 사용하지 않는다. (const를 let 보다 위에 선언한다)
👆 const와 let은 사용 시점에 선언 및 할당을 한다. (함수는 변수 선언문 다음에 오도록한다.)
✏️ 외부 모듈과 내부 모듈을 구분하여 사용한다.
🧮 배열과 객체는 반드시 리터럴로 선언한다. (new 사용 X)
📠 배열 복사 시 반복문을 사용하지 않는다.
😎 배열의 시작 괄호 안에 요소가 줄 바꿈으로 시작되었다면 끝 괄호 이전에도 일관된 줄 바꿈 해야한다. (일관되게 모두 줄 바꿈을 해주어야 한다.)
🧶 객체의 프로퍼티가 1개인 경우에만 한 줄 정의를 허용하며, 2개 이상일 경우에는 개행을 강제한다. (객체 리터럴 정의 시 콜론 앞은 공백을 허용하지 않음 콜론 뒤는 항상 공백을 강제)
🧂 메서드 문법 사용 시 메서드 사이에 개행을 추가한다.
🌭 화살표 함수의 파라미터가 하나이면 괄호를 생략한다.
🍳 변수 등을 조합해서 문자열을 생성하는 경우 템플릿 문자열을 이용한다.
🧇 변수 등을 조합해서 문자열을 생성하는 경우 템플릿 문자열을 이용한다.
🥞 wildcard import는 사용하지 않는다. (import문으로부터 직접 export하지 않는다.)
🥖 한 줄짜리 블록일 경우라도 {}를 생략하지 않으며 명확히 줄 바꿈 하여 사용한다.
🥯 switch-case 사용 시 첫 번째 case문을 제외하고 case문 사용 이전에 개행한다.
🥐 삼중 등호 연산자인 ===, !==만 사용한다.
🚐 반복문 사용은 일반화된 순회 메서드 사용을 권장한다.
🚑 람다함수 안에서 밖에 있는 변수를 사용하지 말라
🚚 코드 블럭 주석 처리를 위해서는 한 줄 주석을 사용한다. 여러 줄 주석을 작성할 때는 *의 들여쓰기를 맞춘다. 주석의 첫 줄과 마지막 줄은 비워둠
💫 시작 괄호 바로 다음과 끝 괄호 바로 이전에 공백이 있으면 안 된다.
https://www.notion.so/88d73303c2b543c5b9870e03a997b664?v=521e4b16175f46ec83169ad83928a3a2
https://www.notion.so/40991af39a1a4145b7d07f1dd6f6ca8d?v=8a80e6294eeb4d6884ede663bcd73982