포스트

상품 목록

상품 목록

요구 사항

기획자가 아래와 같은 아주 간단한 상품 목록 기획서를 가져왔다고 가정해보겠습니다.

나였다면 기획서를 보고 어떤 질문을 했을까?

  • 카테고리 조회
  • 카테고리 클릭 시, 해당 카테고리에 맞는 상품 목록 조회 (최대 n개)
  • 페이지 네이션 (offset, limit)
  • 최신순으로 정렬 (추후 정렬은 변경 될 수 있음)

저였다면 위 요구사항을 보고 이정도 기능을 질문 없이 개발 했을 것 같습니다.

하지만, 강의에서는 이렇게 개발해서는 언된다고 합니다. 보이는 대로 개발을 진행하는 것이 아니라, 개발하기 전에 기획자에게 어떤 요구사항이 더 숨어있는지 계속해서 물어보고 질문해야 한다고 합니다.

또한, 페이징 같은 경우 프론트와의 협업도 있기 때문에 프론트에게도 질문을 해야합니다.

요구사항 더 캐묻기

  • 하위 카테고리는 없는가?
  • 하나의 상품은 하나의 카테고리만을 가지는가? (1:N에서 M:N 관계가 되는 중요한 문제)
  • 카테고리는 몇 개를 보여줘야 하는가?
  • 상품은 몇 개를 보여줘야 하는지?
  • 스크롤 방식인지? 페이지 방식인지?
  • 스크롤 할때는 몇 개씩 가져올 건지?
  • 상품이 없다면 어떻게 보여줄건지?
  • 카테고리 별로 최대 상품 개수가 정해져 있는지?
  • 상품마다 보여주는 내용은 뭐가 있는지?
  • 정렬은 어떻게 처리해야 하는지? (최신순, 마지막 수정 순, 인기순, 우선순위 등등)
  • 스크롤 or 페이징에서는 커서 방식으로 할지 offset, limit 방식으로 할지? (프론트와의 협의)
  • 상품이 별로 없다면 전체를 다 조회해서 프론트에서 처리 하는건 어떤지? (프론트와의 협업)
  • 등등

중요한 점

최악의 개발은 질문을 하지않고 API를 만들어 주는 것입니다.

기획자가 놓친 부분을 캐치하고, 모르는 부분을 이해하려면 소통을 많이 해야 합니다.

이렇게 일을 진행해야 결과적으로 더 빠르고 원하는 결과를 얻을 수 있습니다.

API

상품 목록 조회

1
GET /v1/products
  • 페이징은 offset, limit 방식으로 하는 것으로 협의 되었다고 가정
Parameter설명
categoryId카테고리 고유 아이디
offset시작 순번
limit가져올 개수
  • 카테고리id에 해당하는 상품 목록 조회

개념도

  • 상품과 카테고리가 M:N 관계일 때의 개념도

  • 카테고리는 상품을 알지 못함
  • 상품은 카테고리를 알지 못함
  • ProductCategory는 카테고리를 알고 있음
  • ProductCategory는 상품을 알고 있지만, 격벽 안에 같이 있으므로 굳이 표시하지 않음

참고

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.