[장바구니 협업 Step 2] 윤생(이윤성) 미션 제출합니다.

[2yunseong]

안녕하세요 브콜! 윤생입니다.

이번 미션은 백엔드와 처음 진행해보는 협업 미션이였는데요! 서로 함께 api 명세를 맞추어보고 개발을 진행하는게 뜻깊은 경험이였습니다!!
특히 쿠폰 api 명세를 서로 논의를 마친 이후, 백엔드에서 개발이 완료 되었다고 함과 동시에 서버 url만 바꿔끼웠는데 문제없이 바로 연동이 되어
짜릿함과 msw의 위엄을 느끼게 되었습니다..ㅎㅎ

재화 정책 - 쿠폰

step2의 요구사항으로 쿠폰을 사용하였는데요, 저희 팀은 아래와 같이 쿠폰 정책을 구성하였습니다.

쿠폰 종류

• 쿠폰은 전체 금액에 적용되는 쿠폰과, 개별 상품에 적용되는 쿠폰 두 종류가 있다.
• 각각의 쿠폰은 퍼센트(%)로 할인하거나 고정된 가격을 할인한다.

정리하자면 4가지의 쿠폰 종류가 있다. (이하 종류)

1. 전체 금액에서 특정 퍼센트를 할인하는 쿠폰
2. 전체 금액에서 특정 금액을 할인하는 쿠폰
3. 개별 상품에서 특정 퍼센트를 할인하는 쿠폰
4. 개별 상품에서 특정 금액을 할인하는 쿠폰

쿠폰 사용방법

쿠폰은 다음과 같이 사용할 수 있다.

• 쿠폰은 전체 금액의 적용 가능한 쿠폰과 개별 금액을 적용할 수 있는 쿠폰 중 한가지 종류만 사용된다.
  • 따라서, 한 상품에 적용되는 쿠폰은 오로지 1가지다.
• 쿠폰은 구매하려고 체크박스로 선택된 아이템에만 적용이 된다.

몇 가지 예시

• 전체쿠폰(종류 1, 2) 사용시 상품에 개별쿠폰(종류3, 4)적용 불가능

• 상품 1, 상품 2에 각각 상품에 해당하는 개별 쿠폰(종류 3,4) 적용할지 선택 가능
  • 적용 시 전체쿠폰(종류1, 2) 적용 불가능

실행방법

실제 서버 연결은 production 모드에서 적용해야겠지만 배포를 하지 않는관계로 development 환경에서 msw 대신 직접 배포된 서버를 사용하고 있는점 양해 부탁드립니다!

npm install
npm start

미션을 돌아보며..

미션을 돌아보며 남긴 글입니다. 한번 읽어보시고 해주고 싶은 말씀이 있으시다면.. 환영합니다 :)

• 테스트가 굉장히 미흡하다고 생각합니다. 솔직히 말하면 step2 를 진행하면서 어떤 테스트도 진행하지 않았어요 ㅠ 변명을 하자면 기한을 맞추는데 급급해 기능요구사항을 충족시키는 대에만 신경을 썼던 것 같습니다. 이번에 테스트를 작성하지 않으면서 느낀점은 저는 테스트를 리팩터링을 하고나서 잘 동작하는지 확인하기 위해 테스트를 사용하는데, 그런 부분을 다 수동으로하고, 복잡한 쿠폰 로직에 대한 테스트를 로컬에서 수동으로 해 시이 더 걸렸던 것 같습니다.

• 컴포넌트가 중복되는 코드가 많다고 생각합니다. 특히 주문 페이지에서요. 주문 조회와 주문 상세가 보면 똑같은 테이블 UI인데 중복되어 작성된 것을 볼 수 있습니다. 컴포넌트 분리를 잘하지 못해 아쉽습니다 흑흑

• 리코일을 사용해 컴포넌트가 이 데이터가 동기인지, 비동기인지 알 필요없이 사용할 수 있다는 점과 useState를 쓰는것처럼 편리하게 사용할 수 있는 점은 매우 좋은 장점으로 느꼈습니다. 단점은 하나 느꼈다면 POST 나 PATCH 등에 따라 서버에 update해야하는 데이터를 다시 불러올 때? 그 때는 조금 불편함을 느꼈던 것 같습니다.

[2yunseong]

질문을 조금 남겨보았습니다!

[2yunseong]

(질문)
추가로 if문으로 서버에서 받아온 유저의 전체 적용 쿠폰 중 유저가 선택한 쿠폰이 존재하는지 확인해서, 해당 로직에서 find는 보장할 수 있다고 생각합니다.
하지만 TS로 인해 조금 의도에 맞지 않는 타입가드를 작성하였는데요, (에러 회피용)
이런 경우를 어떻게 줄일 수 있을까요?

[Tanney-102]

includes와 coupon.id === selectedCoupons[0]는 다른 조건 아닌가요?
사용처에서 selectedCoupons를 어떻게 관리하는지는 모르겠지만 사용처를 '몰라야 하는' 이 로직 입장에서는 합리적인 타입에러라고 생각합니다.

추가로 applyCoupon의 존재가 분기의 기준이 되는 거라면 처음부터 find로 applyCoupon을 찾아놓고 분기해도 될 것 같습니다.

const appliedCallCoupon = allCoupons.find(
  (coupon) => selectedCoupons.includes(coupon.id)
)
if (appliedCallCoupon) {
  return getDiscountPrice(appliedCallCoupon, totalPrice)
}
 ... 

[Tanney-102]

allCoupon을 유일하게 하나만 적용하는 것이 기획인지도 궁금하네요.
그렇다면 왜 배열로 관리하는지도 궁금하구요~

[2yunseong]

api 명세에서 선택된 쿠폰을 배열로 담아 보냅니다. (selectedCoupon)
allCoupon이 하나만 적용된다면, 나머지 쿠폰은 적용할 수 없기 때문입니다.
specificCoupon은 여러 개가 적용하므로, selectedCoupon에 배열로 담깁니다.

주문 요청 API

주문할 물건과 couponIds를 함께 보냅니다.

Request method:	POST
Request URI:/orders
Headers:Authorization=Basic {Base64 Encoding}
Content-Type=application/json
Body:
{
    "cartItemIds": [1,2,3,4,5],
    "couponIds": [1L, 2L, 3L]
}

[2yunseong]

질문을 조금 남겨보았습니다!

[woowahan-cron]

타이어보다 싸서 얼마인가요? 파이팅.

[Tanney-102]

안녕하세요 윤생!
레벨2 마지막 미션 정말 고생 많으셨습니다~
쿠폰 정책이 꽤 복잡해 보이는데 충분히 잘 해결해주신 것 같습니다!
몇몇 코멘트와 더불어 코드 레벨에서 주신 질문에도 답변 달아두었으니 확인 부탁드려요.

테스트가 굉장히 미흡하다고 생각합니다. 솔직히 말하면 step2 를 진행하면서 어떤 테스트도 진행하지 않았어요 ㅠ 변명을 하자면 기한을 맞추는데 급급해 기능요구사항을 충족시키는 대에만 신경을 썼던 것 같습니다. 이번에 테스트를 작성하지 않으면서 느낀점은 저는 테스트를 리팩터링을 하고나서 잘 동작하는지 확인하기 위해 테스트를 사용하는데, 그런 부분을 다 수동으로하고, 복잡한 쿠폰 로직에 대한 테스트를 로컬에서 수동으로 해 시이 더 걸렸던 것 같습니다.

당장 기능을 개발하는 게 급한 상황에서는 많은 경우 테스트에 소흘해지게 되는 것 같아요~
요건 저희 팀에서 늘 겪는 문제입니다🥲
이번 미션을 통해 테스트의 역할을 충분히 느끼셨다면 그 자체로 좋은 경험이 되었으리라 생각 되네요~

컴포넌트가 중복되는 코드가 많다고 생각합니다. 특히 주문 페이지에서요. 주문 조회와 주문 상세가 보면 똑같은 테이블 UI인데 중복되어 작성된 것을 볼 수 있습니다. 컴포넌트 분리를 잘하지 못해 아쉽습니다 흑흑

크게 문제삼을만한 반복은 아니라고 생각합니다.
그럼에도 아쉬움이 남는다면 유연한 공통 컴포넌트를 늘려 이를 해결해볼 수 있을지 고민해보셔도 좋겠네요~

리코일을 사용해 컴포넌트가 이 데이터가 동기인지, 비동기인지 알 필요없이 사용할 수 있다는 점과 useState를 쓰는것처럼 편리하게 사용할 수 있는 점은 매우 좋은 장점으로 느꼈습니다. 단점은 하나 느꼈다면 POST 나 PATCH 등에 따라 서버에 update해야하는 데이터를 다시 불러올 때? 그 때는 조금 불편함을 느꼈던 것 같습니다.

꼭 리코일이 아니더라도 mutation 후 서버 상태와 동기화 하는 과정은 필요하긴 합니다~
요걸 더 선언적으로 할 수 있도록 하는 라이브러리가 있는지 찾아보셔도 좋을 것 같네요

[Tanney-102]

이 컴포넌트는 왜 styled component로 선언되어야하나요?

[2yunseong]

기존 코드 스타일을 따라가려고 사용하는 스타일이 없음에도 불구하고 스타일 컴포넌트를 생성하였습니다.

[Tanney-102]

그럼 모든 마크업 요소가 Styled component로만 작성되어야 하나요~?
컨벤션이라면 어쩔 수 없지만 저희 팀 코드였다면 저는 그 컨벤션에 반대했을 것 같아요!
근거가 '코드 스타일' 하나 뿐인 것치고 개발 생산성에 그리 도움되지 않는 것 같습니다.
차라리 사용처에서 그냥 main을 썼으면 시멘틱 태그가 쉽게 파악되어 더 좋았을 것 같아요

[Tanney-102]

이 TODO는 해결 예정이신가요?

[2yunseong]

넵! 이번 리뷰에 반영하겠습니다.

[Tanney-102]

includes와 coupon.id === selectedCoupons[0]는 다른 조건 아닌가요?
사용처에서 selectedCoupons를 어떻게 관리하는지는 모르겠지만 사용처를 '몰라야 하는' 이 로직 입장에서는 합리적인 타입에러라고 생각합니다.

추가로 applyCoupon의 존재가 분기의 기준이 되는 거라면 처음부터 find로 applyCoupon을 찾아놓고 분기해도 될 것 같습니다.

const appliedCallCoupon = allCoupons.find(
  (coupon) => selectedCoupons.includes(coupon.id)
)
if (appliedCallCoupon) {
  return getDiscountPrice(appliedCallCoupon, totalPrice)
}
 ... 

[Tanney-102]

allCoupon을 유일하게 하나만 적용하는 것이 기획인지도 궁금하네요.
그렇다면 왜 배열로 관리하는지도 궁금하구요~

[Tanney-102]

reduce를 사용하셔도 될 것 같네요.
totalDistancePrice라는 가변변수는 굳이 필요 없어 보입니다.

[2yunseong]

브콜 안녕하세요! 리뷰 반영하고 다시 요청 드립니다!
혹시 또 부족한 부분 있으시다면 코멘트 부탁드립니다~! 감사합니다 👍

[2yunseong]

기존 코드 스타일을 따라가려고 사용하는 스타일이 없음에도 불구하고 스타일 컴포넌트를 생성하였습니다.

[2yunseong]

api 명세에서 선택된 쿠폰을 배열로 담아 보냅니다. (selectedCoupon)
allCoupon이 하나만 적용된다면, 나머지 쿠폰은 적용할 수 없기 때문입니다.
specificCoupon은 여러 개가 적용하므로, selectedCoupon에 배열로 담깁니다.

주문 요청 API

주문할 물건과 couponIds를 함께 보냅니다.

Request method:	POST
Request URI:/orders
Headers:Authorization=Basic {Base64 Encoding}
Content-Type=application/json
Body:
{
    "cartItemIds": [1,2,3,4,5],
    "couponIds": [1L, 2L, 3L]
}

[2yunseong]

allCoupon임을 처음에 if문(85번째줄)에서 보장한다고 생각해
도메인 상 선택 로직에서 하나만 선택할 수 있도록 보장하므로 충분하다고 생각합니다.

[2yunseong]

넵! 이번 리뷰에 반영하겠습니다.

[Tanney-102]

안녕하세요 윤생~
긴 시간 정말 고생 많으셨습니다.
이제 우테코에서 리뷰를 받는 미션은 이걸로 끝이군요!
부디 이 과정이 윤생의 성장의 크게 도움이 되었기를 바랍니다! 또 다음 레벨에 준비되어 있는 과정들이 더 큰 성장의 재료가 되기를 기대합니다!
정말 고생 많으셨습니다!

코멘트에 리플라이 몇개 달아두었으니 그것만 확인하고 푹 쉬시면 될 것 같네요~