처음에 예상한것보다 볼륨이 많이 커져서 하나의 페이지에서 복수의 레이아웃을 보여줄 수 있도록 구현하게 되었다. 동적 라우팅을 사용하여 내주변 페이지는 Params ID를 nearby로, 지역별 페이지는 subCategoryId를 Params ID로 설정하였고, boolean 타입의 isNearBy라는 변수를 만들어놓고 isNearBy가 true인지 false인지에 따라 레이아웃이 변경되도록 구현하였다. 또한 여러가지의 정렬/필터 기능이 포함되었다.
GET 요청을 보내도록 구현sortBy State에 저장하고 쿼리파라미터에 담아 서버에 GET요청을 보내도록 구현sortBy에 저장되도록 구현sortBy와 일치하는지 여부를 boolean타입으로 props로 전달하여 색깔이 변하도록 구현options State에 배열로 관리filter State에 options를 저장하여 JSON.stringify() 처리 후 쿼리파라미터에 담아 GET요청을 하도록 구현onChange)는 화면용 State만 값을 변경하고, 최종적으로 마우스를 뗐을 때(onMouseUp) 요청용 State를 변경시키도록 구현pagination State가 1씩 증가시켜 다음 컨텐츠를 불러오도록 구현FormData에 담아 POST 요청을 보내도록 구현저번 1차 프로젝트에서는 구현을 최우선으로 생각했다면 이번 프로젝트는 좀 더 넓은 시각으로 여러가지를 고려했다. 어떤 기능이 우리의 Product의 가치를 올려줄지를 판단하여, 상대적으로 불필요한 요소들은 생략하고 중요성이 높다고 생각되는 요소들에 집중하였다.
좀 더 이용자의 입장에서 생각해보는 시간을 가졌다. 우리의 product를 이용자가 불편해할것 같은 부분들이나 부자연스러운 부분을 최대한 없애려고 노력했고, 숙소의 주인도 우리의 고객이기 때문에 숙소 이용자와 숙소 주인의 사이에서 어떻게하면 양쪽 다 만족시킬지에대해 팀원들과 고민했던 시간이 있었다.
1차 프로젝트 때 부실한 초기 설계때문에 고생했던 일이 있었기 때문에 이번 프로젝트를 시작할때에는 최대한 넓은 시야로 프로젝트를 설계하려고 노력하였으나 결국 이번에도 기획과 설계가 어설퍼서 프로젝트를 진행하면서 계속해서 기획이 변경되게 되었고, 결국 하나의 티켓이 엄청나게 커져버리는 결과를 낳았다.(하나의 PR에 1900줄의 코드가 실려버리기도 했다..) 물론 세상에 완벽한 설계는 없다지만 다음에는 이번보다 나은 설계와 기획을 할 수 있도록 넓은 시야를 가지기 위해 노력할 것이다.
처음에는 라이브러리를 이용하면 개발이 훨씬 쉬워질 줄 알았지만 전혀 그렇지 않았다. 간단한 달력 라이브러리를 사용하는데 색깔 하나 커스터마이징 하는데에도 굉장히 많은 시간과 노력을 쏟아야 했고, 굉장히 많은 기능을 담고있는 카카오지도API를 이용할때는 거의 3일의 시간을 이 API를 파악하고 활용법을 찾는데에 쓰기도 했다.
그리고 package-lock.json파일에서 버전 충돌이 생겨 npm이 고장나기도 했다. 해당 오류가 생길때마다 고치기는 했지만 결국은 프로젝트 전체에 영향을 주게되어 팀원들도 고생을 하게 되었다.
위코드 커리큘럼의 핵심인 두개의 프로젝트가 끝이 났다. 두번의 프로젝트를 거치며 어느정도 내 코드에 대해 자신감도 생기고 개발의 재미도 많이 느낄 수 있었던 시간이였다. 1차에서는 애자일 스크럼 스프린트 방식에 대한 적응과 개발문화에 대한 적응이였고, 2차를 거치며 프로덕트를 바라보는 눈, 고객입장에서 생각하는 습관을 키우고, 내 기술에 대한 시험을 할 수 있는 뜻깊은 시간이였다.