레벨2 장바구니 협업 - Step2

개요

미션	기간	Repository	PR & Review	github pages	storybook
장바구니 1단계	23-05-26 - 23-06-05	Repo	PR & Review	🛒 장바구니	📚 스토리북

---

미션 회고

2단계 미션에서는 우테코 3, 4단계에서 마주치게 될 협업의 과정을 미리 체험할 수 있는 경험을 할 수 있었다. 함께 2단계 요구사항에 대한 명세서를 작성하고 재화 관련 서비스를 무엇으로 할지를 정하는 것이 그것이었다.

 

장바구니 협업 미션의 요구사항은 다음과 같이 크게 2가지이다.

 

1. 재화 과련 서비스(포인트, 쿠폰, 할인)

2. 주문 목록

 

1단계 미션이 끝난 다음날인 26일 금요일 나와 도리는 에단, 베베와 함께 이에 대해 이야기를 하고자 잠실 캠퍼스로 향했다. 다른 크루들도 잠실로 많이 이동했기 때문에 잠실 캠퍼스는 사람들로 붐볐다. 때문에 약간은 혼란스러웠고 집중이 잘 안 되는 느낌을 받았다.(역시 사람이 너무 많은 곳은 잘 맞지 않나 보다 😭) 그래도 한 시간 남짓 집중하여 2단계 요구사항에 대해 이야기를 하였다. 

 

명세서바로가기

 

다음은 함께 이야기하여 정한 기능과 더불어 이를 적용하면서 느낀 점이다.(+ 미션 중 고민한 내용)

---

할인을 해보자!

재화관련 서비스에 대해 고민을 하다 가장 쉬울 것 같은 할인을 적용하기로 하였다. 하지만 지금 생각해 보면 할인은 백엔드와 협업을 하지 않고 프론트에서 자체적으로 계산하여 적용했기 때문에 잘못된 방향이었다고 생각한다. 

---

왜 그렇게 했을까?

초기 장바구니 서비스를 보면 장바구니에서 바로 주문을 할 수 있는 구조로 되어있다.

장바구니 페이지

장바구니 페이지에서 상품을 선택할 수 있고 수량 또한 수정할 수 있다. 때문에 장바구니 페이지에서 할인율을 계속해서 계산을 해야한다. 이런 계산을 백엔드에서 한 후 통신을 통해 프론트에 전달하고 UI에 띄우는 것은 너무 많은 연산이라고 생각했다. 그래서 굳이 백엔드까지 가지 않고 프론트에서 처리하도록 결정을 하였다.

 

만약 그날, 주문하기 페이지를 누군가가 이야기를 했다면 할인 가격 계산을 백엔드에 넘겼을 것이다. 하지만 아쉽게도 그날엔 주문하기 페이지에 대해선 미쳐 생각을 하지 못했다. 나중에 다른 크루들의 서비스를 보며 아이디어를 얻었다.

 

아무튼,, 할인을 적용하기로 했지만 나와 도리는 서로 다른 할인을 하고 있는 아이러니한 상황이 발생했다.

 

또한 이런 재화 관련된 정책은 프론트가 아니라 백엔드에서 일괄적으로 관리하여 데이터를 보내주는 것이 좋다고 생각한다. 아무래도 조금 더 안전한 영역이고 재화는 사용자에게 조심스러운 부분이기 때문이다.

---

뭐, 아무튼 그래서 어떤 할인?

할인의 종류는 굉장히 많다. 당장 떠오르는 것만 해도 다음과 같다.

 

1. 특정 물품에 대한 할인

2. 전체 주문 금액에 대한 할인

3. 배송비 할인

 

이 중 어떤 것을 채택할지를 정해야 했다. 나는 전체 주문 금액에 대한 할인을 선택하였고 다음과 같은 기준으로 할인을 적용하였다.

 

- 10만원 이상일 때 1% 할인

- 30만원 이상일 때 3% 할인

- 50만원 이상일 때 5% 할인

 

총 상품가격을 바탕으로 할인된 금액을 구하는 것은 어렵지 않다. 단순한 계산이기 때문이다.

---

쿠폰도 사용해볼까?

할인만 있다면 심심하지 않을까? 하는 생각에 쿠폰도 적용하기로 하였다. 쿠폰은 발급하고, 적용하고, 삭제하는 과정을 거치게 되는데 이는 모두 서버와 통신을 하기 때문에 명세서가 필요했다. 이에 대해 이야기를 나누며 어떤 쿠폰을 서비스에 도입하면 좋을지 함께 생각했다.

 

우리가 정한 쿠폰은 다음과 같다. 모두 5만 원 이상 주문할 때 쿠폰을 적용할 수 있다.

 

- 1,000원 할인

- 3,000원 할인

- 5,000원 할인

- 10,000원 할인

 

쿠폰을 적용하고 가격을 계산하는 것은 당연히 쉬웠다. 이것도 단순한 계산이기 때문이다. 까다로웠던 부분은 쿠폰을 발급하고 적용하고 삭제하는 전체적인 과정이었다.

---

같은 생각을 가지고 있는 것이 생각보다 쉽지 않았다.

나 혼자 생각하고 이를 서비스에 표현하는 것은 너무나 쉽다. 내 머릿속에 모든 흐름이 담겨져 있기 때문이다. 하지만 이번 미션의 주된 목적은 협업을 경험하는 것이다. 때문에 내 생각만 가지고 미션을 진행할 수 없었다. 내 생각을 다른 크루들에게 알려주고 모두가 납득하는 과정을 거쳐야 한다.

 

이를 직접 느끼게 된 이유는 아직 쿠폰 API를 받기 전 MSW로 작업을 할 땐 수월하게 쿠폰이 적용이 되고 삭제, 발급을 할 수 있었지만 쿠폰 API를 받고 나서는 생각대로 동작하지 않았던 것이었다. 분명 같이 이야기를 하고 명세까지 맞췄는데 무엇이 문제였을까?라는 생각을 하게 되었고 이를 해결하고자 슬렉에 질문을 남겼다. 잘 맞춰가며 해결을 하였지만, 처음부터 꼼꼼하게 이야기를 나누었으면 더욱 좋은 협업이었다고 생각한다.

 

이와 같은 문제는 또 다른 곳에서도 발생하였다. 다음은 전체 쿠폰 조회 명세서다.

// response
[
  {
    id: number;
    name: string;
    discountAmount: number;
    description: string;
  },
  {
    id: number;
    name: string;
    discountAmount: number;
    description: string;
  },
  // ...
]

위와 같이 쿠폰은 id, name, discountAmount, description을 가지고 있다. id와 discountAmount는 어떤 의미이고 어떻게 쓰이는지 구분이 된다. 하지만 name과 description은 그렇지 않다.

 

각각 어떤 의미를 가지고 있으면 어떻게 쓰이지는 확실하게 짚고 넘어가야 서로 같은 방향으로 개발을 할 수 있었을 것이다. 

 

결론은 내 생각이 다른 이들과 다른다는 것을 항상 생각하자.

---

컴포넌트의 재활용

장바구니 서비스에는 다음과 같은 많은 상품 컴포넌트들이 존재한다.

 

1. ProductItem

2. OrderItem

3. OrderSheetItem

4. CartItems

 

0123

다양한 상품 컴포넌트

이러한 상품 컴포넌트들은 모두 공통점을 가지고 있다. 바로 상품의 정보를 보여준다는 것이다. 그렇다면 공통점이 있으니 하나의 컴포넌트를 만들어 재활용을 해야 하는 것인가?라는 고민을 하게 되었다. 사실 이런 고민은 장바구니 협업 미션 이전인 장바구니 미션에서 부터 이어져 왔던 고민이었다.

---

가독성은 괜찮아?

4개의 상품 컴포넌트들을 모두 하나의 컴포넌트에서 Props만 다르게 하여 재활용을 하게 된다면 어떻게 될까? 코드로 구현하지 않았지만 굳이 그러지 않아도 굉장히 복잡해질 것이다.

 

공통적으로 받는 Props은 무엇일까? 바로 상품 객체이다. 당연히 상품의 정보를 보여줘야 하기 때문에 상품 객체는 공통적으로 모두 받을 것이다. 하지만 그 외의 것들을 생각하면 모두 optional이기 때문에 조건문, 삼항연산자가 난무할 것이다. 예를 들어 수량을 조절하는 버튼이 있는 경우가 그렇지 않은 경우, 삭제 버튼이 있는 경우와 그렇지 않는 경우, 날짜가 있는 경우와 그렇지 않는 경우.... 등등 벌써 이를 코드를 구현하고자 한다고 하면 복잡해짐을 느끼지 않는가?

 

스타일 또한 마찬가지이다. 전체적인 배치는 비슷해 보이는 컴포넌트들이 있지만 그렇지 않은 경우도 있다. 이는 스타일 컴포넌트에도 Props를 넘겨 삼항연산자를 사용해야 한다는 것이다. 그럴 바엔 하나하나 만드는 것이 가독성 측면에서 더욱 좋지 않을까? 또한 반응형까지 고려한다면 이는 산 넘어 산이다.

---

확장성은 어때?

서비스는 언제든지 확장 가능성이 있다. ProductItem의 장바구니 버튼이 바뀔 수 있고, 장바구니 아이템의 구성, 배송 정보, 상품 별 할인 혜택 등등 다양한 방향으로 바뀔 수 있다. 이를 고려한다면 아무리 같은 목적을 가진 컴포넌트여도 각각 확장될 가능성이 있는 컴포넌트라면 재활용 가능한 컴포넌트로 만드는 것보다 하나의 컴포넌트로 만들어 확장 가능할 수 있도록 만드는 것이 좋다고 생각한다.

 

만약 4개의 컴포넌트가 모두 하나의 컴포넌트에서 만들어지고 새로운 기능이 추가된다면 어디부터 건들어야 하는지 막막한 상황이 찾아올 수 있다. 개발 속도도 늦춰질뿐더러 원치 않는 오류가 발생할 가능성이 생긴다.

---

그렇다면 언제 컴포넌트 재활용을 한다는 거야?

지금까지 어떤 컴포넌트를 재활용할 수 있도록 만들었는지 생각해 보자.

 

이번 미션에서는 다음과 같은 컴포넌트들을 만들어 재활용하여 사용하였다.

 

- Button

- Checkbox

- HelperMessage

 

더 많은 컴포넌트들이 있지만 위의 3개의 컴포넌들이 대표적으로 재활용할 수 있는 컴포넌트들이라고 생각한다. 이들은 어떤 특징을 가지고 있을까?

 

앞으로 많은 컴포넌트들을 만들어 보면서 나만의 기준을 적립하겠지만 지금 당장 떠오르는 재활용하는 컴포넌트들의 특징은 다음과 같다.

 

1. 간단하다.(의존성이 없다.)

2. 하나의 사용성을 가지고 있다.

3. 데이터를 외부에서 받는다.

4. 특정 컴포넌트들에서만 사용되지 않는다.(완전 범용적이다.)

5. 모든 페이지에서 공통적으로 쓰인다.(이는 Header 또는 NavgationBar와 같은 것들이 해당)

 

언제 한 번 위의 기준을 토대로 정리해 봐야겠다.

---

결론은...

같은 공통점(상품의 정보를 보여준다.)을 가지고 있다 한들 어디에서 어떻게 사용하느냐? 가 다르다면 이는 하나의 컴포넌트를 재활용하는 것보다 각각의 컴포넌트들을 만드는 것이 좋다고 생각한다. 아무리 생각해도 아직 시원한 결론을 내리기엔 너무 어려운 부분이다. 

---

👨‍💻 PR Review

다음은 이번 미션에서 받은 PR/Code Review 내용이다.

---

z-index 관리하기

어떤 레이어가 위에 위치할지, 아래에 위치할지를 정하기 위해선 css의 속성인 z-index를 사용한다. 값은 숫자이며 숫자가 클수록 위에 위치한다. 이를 여러 미션에서 사용을 하며 원하는 디자인을 할 수 있었다.

 

이번 미션에서도 사용을 하였는데, 숫자가 상수로 존재하다 보니 코드의 양이 많아지는 대규모 프로젝트에서는 이를 관리를 해야 한다. 때문에 어떻게 관리를 해야 하는지 여러 기술 블로그들을 찾아보니 다양한 방법이 있었다. 이번 미션에서는 다음과 같이 z-index를 관리하였다.

export const Z_INDEX = {
  base: 0,
  above: 1,
};

현재는 규모가 크지 않아 두 개의 상수로 구분하여 관리하였는데 레벨 3이 시작되면 이도 팀원들과 함께 이야기를 나누며 컨벤션을 만들어봐야겠다.

---

스타일 코드에서의 &&

스타일 컴포넌트를 사용하면 props를 받아 값에 따른 다른 스타일을 정할 수 있다. 이때, 삼항연산자를 많이 사용한다. 하지만 반대편의 스타일이 필요 없는 경우 삼항연산자가 아니라 &&연산자를 사용하였다. 예를 들어 다음과 같은 코드가 있다.

export const Wrapper = styled.div`
  position: ${(props) => props.isFixScrollPosition && 'fixed'};
`

위 코드의 내용은 isFixScrollPosition 값이 true일 때 position 속성을 fixed로 한다는 것이다. 이 말은 isFixScrollPosition값이 false라면 신경을 쓰지 않는다는 것과 같다.

 

하지만 isFixScrollPosition 값이 false라면 postion 값은 false가 된다. 이를 코드를 나타내면 다음과 같다.

export const Wrapper = styled.div`
  position: false;
`

position 속성 중 false가 있는가? 없다. 그렇다면 위 코드는 잘못되었다. 당장 동작할 땐 오류가 없겠지만 속성을 맞춰주는 것이 좋을 것이다. 때문에 다음과 같이 리팩터링을 진행하였다.

export const Wrapper = styled.div<WrapperProps>`
  position: ${(props) => (props.isFixScrollPosition ? 'fixed' : 'static')};
`

---

👍 잘한 점

1. 협업을 위해 소통을 열심히 하고자 노력했다.

2. MSW를 최대한 잘 활용하였다.

👎 아쉬운 점

1. 더 이상 현직자의 리뷰가 없다ㅠㅠ

2. 아직 머릿속이 정리되지 않았다. 언제 정리가 될지..

👊 앞으로의 다짐

1. 연습은 끝났고 실전이 다가왔다.

2. 지금까지 배운 걸 녹여보자.