[wecode] 2차 프로젝트 소개 및 회고

·2022년 12월 8일
post-thumbnail

✔️프로젝트 소개

어떤데.

  • wecode 38기 2차 프로젝트
  • 여기어때에서 영감을 받아 제작한 숙박 플랫폼
  • 진행 기간 : 2022.10.31 ~ 2022.11.10(약 2주)
  • 프로젝트 인원 및 구성(FE:3인, BE:3인)
    • Front-End : 김솔, 모유진, 최현(PM)
    • Back-End : 이현태, 정재욱, 정해만
  • 결과물

💻 기술스택

Front-End

  • Javascript
  • React
  • Styled-Components

Back-End

  • Javscript
  • Node.js
  • MySQL

Common

  • ESLint
  • Prettier

Team Collaboration Tool

  • Notion
  • Trello
  • Slack
  • Github

✔️담당한 티켓 및 구현 기능

리스트 페이지

처음에 예상한것보다 볼륨이 많이 커져서 하나의 페이지에서 복수의 레이아웃을 보여줄 수 있도록 구현하게 되었다. 동적 라우팅을 사용하여 내주변 페이지는 Params ID를 nearby로, 지역별 페이지는 subCategoryId를 Params ID로 설정하였고, boolean 타입의 isNearBy라는 변수를 만들어놓고 isNearBytrue인지 false인지에 따라 레이아웃이 변경되도록 구현하였다. 또한 여러가지의 정렬/필터 기능이 포함되었다.

내 위치 재설정

  • 카카오지도 API를 이용
  • 상단의 검색창을 이용하여 원하는 장소로 이동 가능
  • 내 위치 재설정 버튼을 클릭하면 모달이 마운트되며, 해당 버튼은 "내주변" 페이지에만 존재
  • 원하는 위치에 마커를 찍고 설정 완료를 누르면 해당 위치의 위도, 경도를 쿼리파라미터에 담아 서버에 GET 요청을 보내도록 구현

지도

정렬(Sort)

필터(Filter)

  • 상세 필터는 물품 구비 여부를 필터링 하도록 구현
  • options State에 배열로 관리
  • 적용 버튼을 누르면 filter State에 options를 저장하여 JSON.stringify() 처리 후 쿼리파라미터에 담아 GET요청을 하도록 구현
  • "내주변" 페이지에서는 Range Input을 추가해 반경 몇 키로미터 안의 숙소를 탐색할지 필터링 할 수 있도록 구현
  • 불필요한 요청을 막기 위해 거리를 화면에 표시하기위한 State와 요청을 위한 State를 분리한 후 값이 변할때(onChange)는 화면용 State만 값을 변경하고, 최종적으로 마우스를 뗐을 때(onMouseUp) 요청용 State를 변경시키도록 구현

달력

  • React-Day-Picker 라이브러리 이용
  • 체크인 날짜와 체크아웃 날짜를 클릭하고 선택 완료 버튼을 클릭하면 해당 날짜들로 요청을 보내 그 날짜에 예약이 가능한 숙소들만 필터링 하여 보여주도록 구현
  • 날짜를 선택하지 않고 선택완료를 누르면 Alert Modal을 통해 "날자를 선택해주세요" 알림이 뜨도록 구현
  • 오늘 이전의 날짜는 선택하지 못하도록 비활성화
  • 날짜를 선택하고 달력을 닫았을 때 선택한 날짜와 몇박인지 표시하도록 구현
  • 날짜를 선택하지 않은상태로 달력을 닫았을 때에는 기본값으로 오늘과 내일이 선택되도록 구현

무한스크롤

  • Intersection Observer API를 이용한 무한스크롤 구현
  • 페이지 하단에 위치시킨 observer가 화면에 노출되면 pagination State가 1씩 증가시켜 다음 컨텐츠를 불러오도록 구현

카테고리

  • 이번 프로젝트에서는 지역명을 카테고리로 사용하기 때문에 변동이 적을것이라고 판단하여 상수데이터를 만들어 구현
  • 카테고리 관련 게시글

예약 페이지

  • 시간 선택 기능
  • 대실 / 숙박에 따라 다른 레이아웃이 표시되도록 구현
  • 상세페이지에서 쿼리파라미터로 넘겨준 정보들을 받아 화면에 표시

리뷰 탭(상세페이지)

  • 작성한 텍스트와 사진을 FormData에 담아 POST 요청을 보내도록 구현

공용 Alert Modal

  • Alert Modal에 표시할 메세지를 props로 받아 필요에따라 다른 메세지가 표시될 수 있도록 구현
  • 확인 버튼에 props로 함수를 연결할 수 있도록 구현하여 확장성 있게 사용할 수 있도록 구현

✔️회고

좋았던 점

Product가 중요하다

저번 1차 프로젝트에서는 구현을 최우선으로 생각했다면 이번 프로젝트는 좀 더 넓은 시각으로 여러가지를 고려했다. 어떤 기능이 우리의 Product의 가치를 올려줄지를 판단하여, 상대적으로 불필요한 요소들은 생략하고 중요성이 높다고 생각되는 요소들에 집중하였다.

유저의 입장에서 생각하기

좀 더 이용자의 입장에서 생각해보는 시간을 가졌다. 우리의 product를 이용자가 불편해할것 같은 부분들이나 부자연스러운 부분을 최대한 없애려고 노력했고, 숙소의 주인도 우리의 고객이기 때문에 숙소 이용자와 숙소 주인의 사이에서 어떻게하면 양쪽 다 만족시킬지에대해 팀원들과 고민했던 시간이 있었다.

아쉬운 점

어설픈 기획(점점 커지는 티켓..)

1차 프로젝트 때 부실한 초기 설계때문에 고생했던 일이 있었기 때문에 이번 프로젝트를 시작할때에는 최대한 넓은 시야로 프로젝트를 설계하려고 노력하였으나 결국 이번에도 기획과 설계가 어설퍼서 프로젝트를 진행하면서 계속해서 기획이 변경되게 되었고, 결국 하나의 티켓이 엄청나게 커져버리는 결과를 낳았다.(하나의 PR에 1900줄의 코드가 실려버리기도 했다..) 물론 세상에 완벽한 설계는 없다지만 다음에는 이번보다 나은 설계와 기획을 할 수 있도록 넓은 시야를 가지기 위해 노력할 것이다.

처음 만나는 외부 API와 라이브러리들

처음에는 라이브러리를 이용하면 개발이 훨씬 쉬워질 줄 알았지만 전혀 그렇지 않았다. 간단한 달력 라이브러리를 사용하는데 색깔 하나 커스터마이징 하는데에도 굉장히 많은 시간과 노력을 쏟아야 했고, 굉장히 많은 기능을 담고있는 카카오지도API를 이용할때는 거의 3일의 시간을 이 API를 파악하고 활용법을 찾는데에 쓰기도 했다.
그리고 package-lock.json파일에서 버전 충돌이 생겨 npm이 고장나기도 했다. 해당 오류가 생길때마다 고치기는 했지만 결국은 프로젝트 전체에 영향을 주게되어 팀원들도 고생을 하게 되었다.

소감

위코드 커리큘럼의 핵심인 두개의 프로젝트가 끝이 났다. 두번의 프로젝트를 거치며 어느정도 내 코드에 대해 자신감도 생기고 개발의 재미도 많이 느낄 수 있었던 시간이였다. 1차에서는 애자일 스크럼 스프린트 방식에 대한 적응과 개발문화에 대한 적응이였고, 2차를 거치며 프로덕트를 바라보는 눈, 고객입장에서 생각하는 습관을 키우고, 내 기술에 대한 시험을 할 수 있는 뜻깊은 시간이였다.

0개의 댓글