TIL (Today I Learned)

#TIL_백오피스 프로젝트 회고록(음식 배달 서비스)

k0z 2023. 12. 18. 19:18

# 프로젝트 선택

CAMP에서 두 달 코딩 공부를 뒷받침으로, 팀 프로젝트를 통해 실전 경험을 쌓고 이를 기억하고자 회고록을 작성합니다.

이번 프로젝트는 이론 중심에서 벗어나 실제 서비스를 만들기까지 얼마나 치열한지 배운 계기가 되었고, 좋은 경험과 함께 저희 팀에게는 도전이었습니다. 

 

개발 프로세서 가이드에서 주어진 펫시터 매칭 서비스 또는 음식 배달 서비스 중 선택할 수 있었습니다. 우리 팀은 기능이 다양하고 구현이 복잡한 음식 배달 서비스를 선택하여 프로젝트를 진행하게 되었습니다

 

# 프로젝트의 목표_어떤 음식 배달 서비스를 만들고자 했는지? 

우리 팀은 다른 팀에 비해 실력이 부족하다는 인식을 가지고 있었지만, 도전의 의미를 살리기 위해 필수 구현이 비교적 적은 펫시터 프로젝트보다는 음식 배달 서비스를 선택했습니다. 이 프로젝트에서의 주요 목표는 현업 서비스에 최대한 가까운 카피캣을 만들어내는 것이었습니다.

 

1. 실제와 유사한 서비스 구현

주된 목표는 현업 음식 배달 서비스와 비교 분석을 통해 유사한 경험을 제공하는 것이었습니다. 사용자 경험, 기능 구현, 디자인 등을 면밀히 분석하여 가능한 한 유사한 서비스를 만들기 위해 노력했습니다.

 

2. 필수 구현 완료

프로젝트 진행 중에는 개발 프로세서 가이드에 명시된 필수 구현 사항을 완료하는 것이 중요했습니다. 기본적인 서비스 동작 뿐만 아니라 핵심적인 기능들을 정상적으로 동작시키는 것을 목표로 삼았습니다.

 

# 프로젝트 시작과 아이디어 도출

프로젝트를 시작하기 전, 효율적인 협업을 위해 각자의 역할을 분담하고, 실제 시장에서 큰 인기를 얻고 있는 배달의 민족과 요기요 앱을 참고하여 아이디어를 도출했습니다.

 

1. 협업을 위한 역할 분담

효과적인 협업을 위해 팀원들 간에 역할을 분담하는 것이 첫 번째 단계였습니다. 각자의 전문성과 강점을 고려하여 개발, 디자인, 테스트, 프로젝트 관리 등의 역할을 분담함으로써 효율적인 작업을 기대할 수 있었습니다.

 

2. 시장 조사와 아이디어 도출

프로젝트의 핵심인 서비스 아이디어를 도출하기 위해 실제 시장에서 성공을 거둔 배달의 민족과 요기요 앱을 면밀히 조사했습니다. 이를 통해 현재 사용자들이 선호하는 기능, 디자인, 편의성 등을 파악하고, 이를 참고하여 우리 서비스의 초기 아이디어를 형성했습니다.

# 사용한 개발 환경

- JavaScript

- Html, Bootstrap

- Css

- Node.js(yarn)

- Prisma 

- AWS RDS

- MySQL

# Code Convention 

1. 네이밍 규칙
상수: UPPER_CASE
변수, 함수, 메소드: camelCase
클래스, Exception: PascalCase

2. Prettier 설정 (.prettierrc)
{
  "singleQuote": true,
  "semi": true,
  "useTabs": false,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 80,
  "bracketSpacing": true
}​

(Prettier 설정은 코드의 일관된 형식을 유지하기 위해 사용되며, 주로 코드 포맷팅 도구로 활용됩니다.)


3. Git 및 프로젝트 설정 파일
Gitignore 파일: .gitignore환경 변수 파일: .env

4. 개발 환경 설정
Nodemon 사용: 개발 중인 코드 변경 시 자동으로 서버를 재시작하는 도구로 개발 환경에서의 효율성을 높입니다.
npm install -D nodemon​

5. Git Commit Message 규칙
Git Commit 내용: feat/ 기능 구현 내용

6. 코드 작성 관례
Create (생성)
create, set, insert 등 사용예) createProduct, createUser, createOne

Read (읽기)
read, get, find 등 사용예) readProduct, readOne, readOneById, readAll, readMany

Update (갱신)
update, modify, change 등 사용예) updateProduct, updateUser, updateOne

Delete (삭제)
delete, remove, destroy 등 사용예) deleteProduct, deleteUser, deleteOne

# Github Rules

1. 커밋 규칙
커밋은 최대한 하나의 작업 단위로 수행합니다. 작은 수정이라도 별도의 커밋으로 나누어 가독성을 높입니다.
모든 커밋은 명확하고 간결한 메시지를 가지며, 작업의 의도를 이해하기 쉽게 작성합니다.

2. 브랜치 관리
각 기능 또는 작업 별로 별도의 브랜치를 만들어 작업을 수행합니다.dev 브랜치를 유지하여 개발한 기능을 병합하기 전에 통합 테스트를 진행하고, 안정적인 상태에서 main브랜치로 병합합니다.

3. 커밋 메시지 관리
커밋 메시지는 명확하고 간결하게 작성합니다.각 커밋 메시지에는 관련된 이슈 번호를 추가하여 작업의 추적성을 높입니다.

4. 머지 전 팀원 알림
머지하기 전에는 팀원들에게 알리고, 먼저 올린 순서대로 머지를 진행합니다.만약 충돌이 발생하면 팀원들과 협의한 후 진행하며, 충돌을 최소화하기 위해 주기적으로 머지를 진행합니다.

 

# 프로젝트 명 : Node.js 백오피스 프로젝트 

  • 한 줄 정리 : 음식 배달 서비스

  • 내용 : 로그인 및 회원가입
    • 사용자는 “고객님” 혹은 “사장님”으로 계정을 생성하고 로그인 할 수 있어야 합니다.  (o : 점주/ 사용자 구분 완료)
    • 회원가입 시 이메일 인증 기능을 넣어주세요. (x : 이메일 중복만 확인)
    • 이 때, “고객님”으로 가입 시 100만 포인트를 지급해주세요. (x : default 값으로 설정하였지만 적용안됨)
      • 포인트 → 메뉴 주문시 사용되는 사이버 화폐입니다.

  • “사장님” - 업장 CRUD 기능
    • “사장님”은 업장 정보를 등록 및 수정, 삭제를 할 수 있어야 합니다. (o: 등록 수정 삭제 가능)
    • “사장님”은 업장 정보를 오직 1개만 갖고 있을 수 있어야 합니다. (o: 업장 하나 등록에 의문을 가졌지만 일단 적용완료 -> 작업 편의를 위해 하나로 제한했던걸로 전달받음)
    • 업장 정보 목록은 모두가 볼 수 있어야 합니다.(user와 admin 모두 열람 가능)

  • “사장님” - 메뉴 CRUD 기능
    • “사장님”은 메뉴 정보를 등록 및 수정, 삭제를 할 수 있어야 합니다. (△: 등록만 가능 나머지 누락)
    • 메뉴 정보는 다음과 같습니다.  (o: 이미지/ 메뉴이름/ 가격 모두 적용) 
      • 이미지
      • 메뉴 이름
      • 가격
    • 업장 내에서 동일한 메뉴 이름으로는 재등록이 되지 않습니다.  (o: 중복 방지 적용)
    • 메뉴 목록은 모두가 볼 수 있어야 합니다. (o: 모두 볼 수 있음)

  • 음식점 검색 기능
    • “사장님” 및 “고객님”은 키워드 기반으로 음식점을 검색하여 볼 수 있어야 합니다.  (o: 모두 검색 가능)

  • “고객님” - 메뉴 주문 기능
    • “고객님”은 메뉴를 주문할 수 있어야 합니다. ( x : front와 연동이 안됨)
    • 단, 잔여 포인트가 메뉴 가격보다 비싸면 주문을 할 수 없어야 합니다.  ( x : front와 연동이 안됨)
    • 주문 시 포인트 차감을 할 때는 반드시 트랜잭션을 이용해주세요.  ( x : backend에서도 놓쳤던 부분)

  • “사장님” - 주문 확인 기능
    • “사장님”은 “고객님”들이 주문한 배달 메뉴를 확인할 수 있어야 합니다. ( x : front와 연동이 안됨)

  • “사장님” - 배달 완료 기능
    • “사장님”은 “고객님”들이 주문한 배달 메뉴들 중 하나를 선택하여 배달 완료가 되었다고 상태를 변경할 수 있습니다. ( x : front와 연동이 안됨)
      • 배달 상황까지 일일이 컨트롤 하는 것은 난이도가 다소 높을 수 있기에 간단하게 구현하도록 합니다.  ( x : backend에서도 놓쳤던 부분)
    • 이렇게 상태가 변경이 되면 주문한 메뉴의 가격만큼 사장님의 잔고에 포인트로 입금이 되어야 합니다.
       ( x : backend에서도 놓쳤던 부분)
  • “고객님” - 리뷰 및 평점 관련 CRUD 기능
    • 사용자는 음식점에 대한 리뷰를 작성하고, 평점을 남길 수 있어야 합니다. ( x : front와 연동 오류)

 

#  API 명세서

 

API 명세서 | Built with Notion

Built with Notion, the all-in-one connected workspace with publishing capabilities.

teamsparta.notion.site

 

#  Figma를 활용한 Wide Frame

#  erdcloud를 활용한 ERD 작성

 

많이 부실했던 ERD 작성시 받았던 FEED를 확인해보면 

* UserInfo 테이블의 id2 칼럼은 어떤 의미로 쓰이는 값일까요? 이런 이름은 보는 입장에서 어떤 의미인지 전혀 파악할 수 없으므로 절대 이렇게 네이밍해서는 안됩니다.
* createdAt과 updatedAt 칼럼은 분명 생성“일시“와 수정“일시“인데 데이터 타입은 DATE인 이유가 있을까요?
* 이름이 없는 테이블이 있습니다.
* 전반적으로 ERD가 많이 미흡합니다 이름이 없는 테이블도 있고 네이밍도 일관적이지 않고, 데이터 타입도 일관적이지 않습니다. 전반적으로 보완이 필요합니다. "

 

1. ID2 칼럼에 대한 이름이 명확하지 않았습니다.  예를 들어, "user_id" 또는 "customer_id" 등으로 변경할 수 있었는데 놓쳤던 부분이라 많이 아쉬웠습니다. 

 

2. createdAt과 updatedAt 칼럼은 DATA가 적절한 선택지라 생각을 하였기에 작성하였지만 이 부분에 대해 더 찾아 보았고 밑의 항목을 고려해 볼 수 있을 것 같습니다. 

  1. DATETIME 또는 TIMESTAMP:
    • 장점: DATE보다 더 정밀한 시간 정보를 저장할 수 있습니다. TIMESTAMP는 일반적으로 더 작은 저장 공간을 차지합니다.
    • 단점: 몇몇 데이터베이스에서 TIMESTAMP는 특정 시간대에 대한 정보를 저장하지 않을 수 있습니다.
  2. BIGINT:
    • 장점: UNIX 타임스탬프(Unix Timestamp)로 저장할 수 있어 정수형으로 데이터를 저장하는 데 유용합니다.
    • 단점: 날짜와 시간을 직접 해독하기 어렵습니다.
  3. VARCHAR:
    • 장점: 날짜와 시간을 문자열로 저장할 수 있습니다. 날짜 포맷에 대한 유연성이 있습니다.
    • 단점: 문자열 비교 및 정렬이 DATE 또는 DATETIME에 비해 느릴 수 있습니다.
  4. SERIAL:
    • 장점: 순차적으로 증가하는 일련번호로 날짜와 시간을 나타낼 수 있습니다.
    • 단점: 시간 정보를 정확하게 나타내기 어려울 수 있습니다.

3. 이름이 없는 테이블은 치명적인 실수입니다. 좀 더 정신을 차려야겠습니다. 명확한 이름을 전달하는 것은 필수 사항인데 엄청난 실수를 해버렸습니다.

4. ERD (Entity-Relationship Diagram)

일관성 및 미흡 전체적으로 많이 미흡했고 따로 공부하고자 배달의 민족과 요기요의 ERD를 따로 찾아봤습니다. 확실히 사용자 측면에서 양방향적인 생각을 좀더 생각했어야하는데 거기까지 생각이 미치지 못해서 아쉬웠고 밑에 찾아본 ERD를 바탕으로 한 번 다시 설계를 해보면서 감을 잡아나가야겠습니다. 

 

배달의민족 ERD

Draw ERD with your team members. All states are shared in real time. And it's FREE. Database modeling tool.

www.erdcloud.com

 

 

요기요 클론코딩 erd 모델링

wecode 에서 1차프로젝트로 요기요 홈페이지 클론코딩이 선정되었다.그래서 요기요 홈페이지 작성을 위해 백엔드 3명이 modeling을하였다.one to many 인지 아니면 many to many인지에 대한 개념을 이해하

velog.io

#  팀원과 제작했던 결과물

 

#  프로젝트 이후 팀원들과 느낀점 공유

팀원 A

힘들었던 점은 프로젝트에 참여하면서 속도 부분에서 어려움을 겪었습니다. 처음에는 팀원들에게 민폐가 될까봐 참여에 망설였고, 진행 중에는 다른 팀원들과 비교할 때 속도가 느려져 죄송한 마음이 들었습니다. 이를 극복하기 위해 튜터님에게 도움을 얻고, 팀원들의 지원을 받아 시간을 투자하여 백엔드 작업을 어느 정도 해결할 수 있었습니다. 이러한 협업을 통해 어려움을 극복하고 결과물을 만들어 나갈 수 있었습니다.

 

팀원 B

작업 중 API를 구현하는 부분에서 계획을 명확히 정하지 못해 소통에 일부 오류가 발생했습니다. 그러나 팀원 모두가 이를 해결하기 위해 주말에도 함께 작업하여 열심히 수정을 거듭하였고, 결과적으로 문제가 원만히 해결되었습니다. 앞으로는 더 강화된 소통을 통해 계획을 더욱 명확하게 수립하겠습니다.

 

팀원 C

코드 수정이 점진적으로 이루어지며 문제를 해결하는 과정에서 팀원들과의 협력이 큰 도움이 되었습니다. 특히, 제안된 변화에 열린 마음으로 응답해주신 팀원들에게 감사드립니다. 이러한 경험을 통해 앞으로는 초기 단계부터 변수와 함수를 효과적으로 관리하여 코드의 복잡성을 줄이고자 노력할 계획입니다.

저작자표시 비영리 변경금지 (새창열림)