2주 전에는 계층적 구조로 API를 작성하는 것을 잘 이해하지 못했는데 이번 프로젝트를 통해 확실히 이해할 수 있었다.
상품 리스트 필터링 API 구현 시 if...else구문과 하드코딩으로 인해 고민이 많았다. 확장성과 재사용성, 가독성을 고려하여 멘토님의 리뷰와 구글링을 통해 더 좋은 방법을 찾아 거듭해서 리팩토링했고 만족스러운 결과를 얻었다. 그리고 각각의 고민과 과정과 결과를 매번 블로그에 기록한 것도 좋은 자산이 되었다.
트렐로를 활용해 개인목표를 설정하고 공유하여 스케줄 관리를 위해 노력했다
중간발표 때 다른 팀의 잘한 점을 도입하여, 줌 화면공유 기능과 노션에 작성한 데일리 스탠드업 미팅 회의록을 통해 각자 맡은 업무와 질문하고 싶은 것, 어려운 부분에 대한 소통을 원활히 할 수 있었다.
중간발표 때 다른 팀의 잘한 점을 도입하여, 응답,요청 시 예상 화면과 주요 키값에 대해 포스트맨을 활용해 API명세서를 작성하여 백엔드-프론트엔드 간 불필요한 질의응답을 간소화하고 코드에 집중할 수 있도록 노력했다.
백엔드는 스프린트 초기에 코드카타 때처럼 네비게이터
, 드라이버
라는 역할을 분담하여 초기환경 설정과 회원가입, 로그인 기능을 함께 구현했다. 코드 작성 방식을 통일되어 merge할 때 충돌되는 부분이 거의 없었고 시간을 벌 수 있었다.
server port 번호를 달리하여 프론트엔드와의 통신 테스트에 지원하는 한편 백엔드 API 구현에 집중할 수 있었다
상품 미리보기
기능에 대해 프론트엔드와 합을 맞춰 구현하는데 이슈가 있었다. 상품 미리보기
는 키 contents가 있다는 점에서 제품 상세(GET)
의 응답 데이터에서 일부 뽑아쓰면 될거라 생각해 따로 API를 구현하지 않았다. 그런데 제품 리스트(GET)
에 표시된 상품 이미지와 상품 미리보기
로 표시된 상품 이미지가 다르게 표시되는 현상이 발생했다.
알고보니 내가 구현한 API는
product_options테이블의 id(po.id)를 구별자로 쓰는 제품 리스트(GET)
와
products테이블의 id(p.id)를 구별자로 쓰는 제품 상세(GET)
인데
상품 미리보기
는 제품 상세(GET)
의 응답값인 contents와 서버에 정보를 요청할 파라미터로 제품 리스트(GET)
의 응답값인 po.id를 필요로 했다. 그런데 p.id 파라미터로 제품 상세(GET)
를 요청하니 엉뚱한 상품이미지를 표출하게 되는 것이었다.
백엔드 쪽에서 API를 다시 구현하는 방법도 있었지만 다행히 프론트엔드 쪽에서 해결 방법을 찾아 어떻게든 동작시킬 수 있었다.
다시 생각해보면 API를 새로 만들지 않아도 제품 상세(GET)
의 services레이어에서 필터링조건을 po.id도 선택할 수 있게 설정하면 구현할 수 있을 거 같다. 추후에 리팩토링해보자.
팀원과 소통하는 부분이 그렇게 원활하지 않았다는 점이 아쉽다.
중간 발표와 멘토님으로부터 피드백을 받아 프로젝트 중반부터는 스케줄 관리와 소통이 원활히 이루어질 수 있도록 주의를 기울였지만 초기에 회의했던 내용을 따로 기록하지 않아 서로다른 각자의 기억에 의지했고 다소 갈등이 있었고 조화를 이루진 못한 거 같다.
다음 프로젝트 부터는 목표를 명확하게 설정하고 Notion 등 공유 노트에 기록하고 명시하여 갈등을 최소화해야겠다.