⏲️ WAITING CATCH! ⏲️

"사용자가 설정한 지역의 레스토랑을 불러와 줄서기를 대신해주고, 그것과 관련된 서비스를 편리하게를 대신 해주는 웹사이트 입니다."
백엔드 로직에 집중하기 위해서 화면은 최대한 간결하게 만들고 설계하였으며 REST API 서버로 대용량 트래픽을 고려한 애플리케이션으로 개발하였습니다.

• 서비스 주소
• 시연 비디오
• 프레젠테이션자료

🚀 Tech Stack

🚀 Architecture

🚀 WIKI

화면 설계에 대한 Figma 프로토타입 디자인과 Usecase를 보실 수 있습니다. 기술적인 문제에 부딪혀 해결한 이야기에 대한 개인 테크 블로그의 주소도 포함되어 있습니다.

• Team notion
• 중간 점검
• Usecase
• WIKI Home

👥 Members

• 김태훈(리더) : 유저 - 시큐리티, 로그인, 로그아웃
  
• 박정훈(부리더) : 레스토랑 - 판매자신청, 블랙리스트,레스토랑수정
  
• 한정규 : 레스토랑 - 메뉴, 카테고리, 검색
  
• 조성제 : 줄서기 - 호출, 리뷰
  
• 송경헌 : 이벤트 - 쿠폰 유저 발급쿠폰
  

🚀 Focus

✔️ 대용량 트래픽의 상황에서 지속적인 서버 성능을 개선하기 위해 노력하였습니다.
✔️ 꾸준한 코드 리팩토링을 진행 중입니다.
✔️ 이유와 근거가 명확한 기술의 사용을 지향합니다.
✔️ 객체지향적 개념을 이해하고 이를 코드에 녹여내어 의미 있는 설계를 지향하였습니다.
✔️ 성공만 하는 테스트보단 실패할 만한 단위 테스트를 작성하였습니다.
✔️ 반복적인 작업은 자동화하여 개발의 효율을 높이기 위해 노력하였습니다.

🚀 Layout

고객 페이지

판매자 페이지

관리자 페이지

🚀 ERD

🚀 API Document

고객 API 명세서 : 고객에 관한 API
판매자 API 명세서 : 판매자에 관한 API
관리자 API 명세서 : 관리자에 관한 API

🚀 Rules

Git-flow

Git-flow 브랜치 전략에 따라 기능별로 브랜치를 나누어 작업하고 있고 모든 브랜치에 대해 pull request를 통한 리뷰 완료 후 merge를 하고 있습니다.

✅ master : 제품으로 출시될 수 있는 브랜치를 의미합니다.
✅ develop : 다음 출시 버전을 개발하는 브랜치입니다. feature에서 리뷰 완료한 브랜치를 Merge하고 있습니다.
✅ feature : 기능을 개발하고 hotfix 버그 수정도 같이하는 브랜치입니다.

PR

• 브랜치는 develop을 기반으로 생성하고, 도메인 단위로 생성하고 PR을 요청합니다. feature/도메인명 (영어로)
  
• Github Project를 사용 : New: 새로운 기능, Ready: 만들어야 하는 기능, In progress: 만들고 있는 기능,
  In review: 리뷰 중인 기능, Done: 끝난 기능으로 나누어 분업화한다.
• commit은 C/R/U/D 기능단위로 묶고 [커밋분류] #이슈 번호 커밋 메시지 형식으로 만든다. ex:[feat] #1 로그인 기능을 추가합니다.
• 모든 PR은 반드시 지정한 리뷰어에게 코드 리뷰를 받아야만 합니다.
• 리뷰어 중 모든 리뷰어의 Approve를 받아야 Merge pull request를 할 수 있습니다.
• 모든 PR은 Github Action의 CI/CD를 통과하고 통과가 되어야 Merge pull request된다.

Review

• 정해진 커밋 컨벤션과 코딩 컨벤션을 지켜 일관성을 유지합니다.
• 합의되지 않은 코드는 리뷰를 통해 필터링합니다.
• 팀원 전원의 승인이 있어야, Merge가 가능합니다.
• 오전(10시 - 13시)은 PR에 대해 팀원 전원이 리뷰합니다.
• 리뷰는 우선순위를 정하여, 다른 작업에 영향을 줄 수 있는 것 부터 차례대로 진행합니다.
• 리뷰는 아침 회의에서 결정된 우선순위대로 진행하며, 리뷰 이후에 Merge를 한 번에 진행합니다.

Commit Message Convention

• [feat] : 새로운 기능 추가
• [fix] : 버그 수정
• [docs] : 문서 수정
• [build] : 빌드 관련 파일 수정
• [style] : 코드 포맷팅, 코드 자체의 변경이 없는 경우
• [refactor] : 코드 리팩토링
• [test] : 테스트 코드 추가
• [merge] : 병합
• [design] : CSS 등 사용자 UI 디자인 변경
• [comment] : 필요한 주석 추가 및 변경
• [rename] : 파일, 변수, 메서드, 폴더명을 수정하는 경우
• [remove] : 사용하지 않는 파일 혹은 폴더를 삭제하는 경우

Coding Convention

Naver Hackday Java Coding Convention

Details

• 주석은 한 줄로 정리 가능하다면 //를 사용하고 엔터를 통해 줄이 넘어가야 하는 경우 /**/를 사용한다.
• Service 는 인터페이스를 사용한다.
• Service 인자로 받는 것은 DTO 여야하고, 때려죽어도 바뀔 일이 없는 값은 컨트롤러 DTO를 그대로 가져와서 사용한다.
• DTO는 매개변수의 숫자와 관계없이 생성하여 전달합니다.
• DTO는 매개변수 2개 이상일 경우에만 생성하여 사용한다.
• 단, InternalService는 DTO를 사용하지 않는다.
• 메서드 명은 동사 + 명사의 조합으로 사용한다.
• DTO 네이밍은 메서드 네이밍 + 레이어네임(Service, Controller) + Response/Request 로 한다.(DTO 뺀다)
  • ex) XxxControllerRequest, XxxServiceResponse, XxxServiceRequest
• 본인이 생각했을 때 바뀔 일이 없는 것은 레이어 네임을 제외한다.
  • ex) XxxRequest, XxxResponse
• 서비스 레이어 내부에서 사용할 엔티티를 return 하는 메서드를 서비스 내에 _로 정의하여 사용한다.
  • ex) _getUser, _getReservation → Entity를 반환
  • ex) getUser, getReservation → Dto를 반환
• 하나의 매개변수가 선언되어 있는 경우 : get, create, update, delete + by + 매개변수 명
• 2개 이상 복수의 매개변수가 선언되어 있는 경우 : get, create, update, delete + 전달되는 매개변수를 한 단어로 축약하여 사용한다.
• 복수 변수명 : ~s(o), ~List(x)

Performance Test

🚀 개인 블로그

• 박정훈
• 김태훈
• 한정규
• 송경헌
• 조성제