기술 과제 분석 및 실행

권태형·2023년 4월 15일

이것저것

목록 보기
4/9

😀처음으로 면접을 진행한 회사에서 기술과제를 받았다. 이번 기술과제를 어떻게 풀어나갈지 정리해보자.
JSON파일을 늦게봐서 삽질을 많이했다. 혼자 구상하고, 혼자 구성짜고... 어떻게 만들어 나갈지 생각을 다해놨었는데, MySQL에 들어갈 Json 예시파일이 이미 있어서 타입이나 기타 등등을 정하지 않아도 될 것같다.

구현 기능

숙박 플랫폼을 서비스하기 위한 REST API를 구현해야 합니다.


회원 기능

회원 가입

  • 추론 아래 로그인의 email과 password가 필요한 로컬 회원가입으로 추정

로그인
회원 가입 및 로그인은 이메일을 사용합니다.

  • 추론 유저의 entity에 email이 필요하다

비밀번호는 암호화 되어야 합니다.

  • 추론 비밀번호를 헤시 함수 또는 라이브러리를 이용해서 단방향 암호화를 진행하여야한다.

JWT만을 이용해 인증기능이 구현되어야 합니다.

  • JWT를 활용하여 토큰 인증절차를 구현해야한다.

user의 entity는 user_id(pk), email, password로 구성된다

id: number(pk),
email: string,
password: string


매물기능

매물 조회 기능
매물 정보: 타이틀, 주변대학, 매물 타입, 이미지 URL, 설명, 주소, 가격.

  • 추론 매물의 entity는 타이틀, 주변대학, 매물타입, 이미지URL, 설명, 주소, 가격이 필요하다.
  • 타이틀: string, 주변대학: string, 매물타입: string, 이미지 URL: string, 설명: string, 주소 :string, 가격: number

사용자는 매물 리스트를 볼 수 있어야 합니다. 페이지네이션이 필요합니다.
리스트에는 타이틀, 주변대학, 이미지, 매물 타입, 가격이 나옵니다.

  • 추론 http메소드 get요청시 일정 매물의 양만 나올수 있도록 페이지네이션하고, 전체요청시 리스트의 항목에는 entity의 항목이 모두 나오는게 아니라 name, university, images, houseType, pricePerDay 다섯가지 항목만 표출된다.

따라서 accomm_entity의 최종구성은

id: number(pk),
name: string,
description: string,
address: string,
university: string,
houseType: string,
pricePerDay: number
images: JSON,

으로 총 8개의 컬럼을 가진다.

사용자는 상품 리스트를 가격순으로 정렬할 수 있습니다.

  • 추론 url의 query string으로 분기를 나누어 orderBy의 기준을 상품의 가격 낮은순, 높은순 두 가지의 정렬기준이 필요하다.

사용자는 상품 상세 정보를 볼 수 있어야 합니다.

  • 추론 Get메소드로 list를 불러올 때의 findAll() 뿐만 아니라, 메물의 상세정보를 보기 위한 findOne()또한 필요하다.

  • 따라서 findOne()의 상세정보에서는 매물의 모든 정보를 볼 수 있어야한다.

궁금증

  • 매물등록절차는 따로 없는 걸까?

  • 사용자가 상품의 리스트를 가져오고 상세정보를 조회한다는 전제이기 때문에 사용자는 관리자계정이 아니어야한다. 따라서 사용자는 매물등록을 할 수 없다는 것일까?

  • 따로 사용자(user)가 있고, 사용자가 추가적으로 사업자(admin)계정으로 추가 전환하는 API를 따로 만들어야 할까? 그렇다면 사용자 entity에 admin항목을 넣고 사업자등록을 통한 true값의 전환으로 매물등록이 가능하도록 API를 만들면 좋지 않을까?

  • 그렇다면 사업자의 확인절차는 어떻게 진행해야할까? 숙소 및 부동산 사업자에 대해서만 확인할 수 있어야한다.


구현 시 우대사항

숙박 예약
사용자는 숙박 시설을 예약할 수 있어야 합니다.

  • 추론 숙박예약에 대한 true false는 사용자의 요청에 의해 결정되게된다. 따라서 숙박예야 API를 따로 하나 더 만들어야 한다.

사용자는 예약한 내용을 확인할 수 있어야 합니다.

  • 각 Get요청에서 숙박 예약에 대해 확인할 수 있는 정보를 보내줘야한다.
  • reservation이라는 정보를 추가하고 true, false를 판단할 수 있는 기준이 주어져야한다.

궁금증

  • 숙박예약의 취소에 관한 결정사항이나 관리방법은 어떻게 해야할까?

  • 예약정보를 확인하기 위해서는 reservation 테이블을 따로 만들어서 누가(user_id)가 어느숙소(accomm_id)에 언제(created_At), 얼마동안() 알 필요가 있을 것이다.

  • 예약내용을 확인할 수 있어야한다는 것이 따로 사용자(user_id)에 따른 예약숙소 list를 보여달다는 것일까? 아니면 일반 리스트와 상세조회에서 사용자의 예약에 대한 체크만 확인할 수 있어도 되는 것일까?

  • 매물에는 날짜항목이 없다. 특정 날짜에 한 사용자가 예약을 하게된다면, 다른사용자는 볼 수 없어야 하는게 맞지 않을까? 하지만, 매물의 가격을 알고 있지만, 언제를 의미하는지 알 수 없다.

  • 생각해보자 어짜피 하루동안 빌리는 가격이 존재한다 따라서 예약을 하기위해서는 보더버튼으로 1일,2일,3일 등 일반적인 양의정수가 들어올 것이다. 따라서 entity에 id, userid, houseid, createAt, days 정도가 들어가는게 맞지 않을까? 하지만 생성날짜를 기준으로 하게된다면, 무조껀 당일예약부터 시작인데.... 그건 문제가 될 것 같다. createdAt이 아니라 startDate를 기준으로 Days동안 예약하게 된다면 어떨까?

  • 만약 한사람이 일주일 중 3일을 하루씩 띄어서 예약한다면 위와 같은 방식을 적용하면 세번의 결제를 해야하기 때문에 많이 불편할 것이다. 그렇다면 언제부터 몇일 동안이 아니라, yy년-mm월-dd일 자체를 받는식으로 한다면 어떨까? 중복되는 데이터가 생기겠지만, reservation테이블에서 date를 검색해서 겹치지 않는 날짜만 활성해 주는식 or 이미 겹쳐진 날짜만 비활성식으로 만들면 될 것같다고 생각한다.

  • 또 위와같이 생각하니 예약리스트를 불러올때 너무많은 중복을 불러올 것같다. 한사람이30일을 풀로 예약을 했을때, 같은 건물에대한 리스트가 30개가 나오게 될것이다. 날짜만 다르게... 어떻게 구상하면 좋을까?

  • 숙소예약 대형플랫폼들을 돌아보니 띄엄띄엄 예약하는것은 여러번의 결제를 동반하도록 만들어 져있고 반드시 붙여서 체크인날짜와 체크아웃 날짜를 받도록 되어있는것을 확인했다. 따라서 yy년-mm월-dd일 자체를 받는 방식보다는, startDate를 기준으로 Days동안 예약하거나, startDate와 endDate를 받아서 그 기간동안 한 사용자가 예약한다면 다른사용자는 예약할 수 없도록 해야한다.

  • A라는 사용자가 예약한 날짜의endDate는 B라는 사용자의 startDate가 될 수도 있지 않을까? 일반적으로 낮12시 입실 다음날 9시 퇴실 하면 3시간 청소하고 당일 12시에 다음 손님을 받는다. 그렇다면 비활성화 되는 날짜는 endDate-1로 해야할까? 아니면 퇴실하고 그날을 비워야할까?


우대사항

Typescript 사용

  • 이번 기술과제에서는 개인 역량증가를 위해 Typescript와 NestJS를 사용해보도록 하자.
  • 필수 기술스택에 대해서만 적혀있기 때문에 추가적인 기술스택으로 TypeOrm을 사용하도록 하자.

유닛 테스트

  • NestJS는 테스트 코드를 작성하는데 유용한기능을 많이 제공한다고 했으니 도전해보자.

문서화

  • .... 무슨말인지 알아보자.....
profile
22년 12월 개발을 시작한 신입 개발자 ‘권태형’입니다. 포스팅 하나하나 내가 다시보기 위해 쓰는 것이지만, 다른 분들에게도 도움이 되었으면 좋겠습니다. 💯컬러폰트가 잘 안보이실 경우 🌙다크모드를 이용해주세요.😀 지적과 참견은 언제나 환영합니다. 많은 댓글 부탁드립니다.

0개의 댓글