Project 2- 3일차: 백엔드 플랜 미팅 part2. [api 회의, 우선순위]

0. 프론트엔드와의 짧은 sync

0-1. 상세페이지의 product image가 이동하는 것과, 썸네일 이미지들을 구현하는데 

일정 내에는 어려울 수도 있는데, 

프론트엔드만의 결정으로 진행할 수 없으니 백엔드에게 상의를 하러 오셨다. 

 

백엔드 팀원들이 본인 의견을 각자 이야기 하였고,

우선은, 테크리더이자 Pm이 자리에 없는 상태였기에,

po 로서 백엔드의 입장에서 정리를 하였다. 

 

" 백엔드에서는 'erd modeling'에서 썸네일 이미지 테이블만 따로 뺐다가,

마친 썸네일 이미지를 product image table에 하나로 모아 수정한 상태이고, 

 

백엔드가 추가로 코드를 치는 작업보다

프론트엔드의 작업량과 작업시간으로 작업강도가 더 강하니, 

프론트엔드가 가능하면 하고 부담스러우면 편하게 해도 된다.

 

단, 우리는 mvp로 최소한의 기능 구현을 먼저해서, 

우선순위로 따지자면, 썸네일 이미지와, 이미지 이동되는 것은 

후순위에 해당될 것이다. "

 

이 부분에 대해서 프론트엔드도 인지하고 있고,

다만, 모두가 가져가는 포트폴리오다보니, 

백엔드 입장에서는 아쉬울 수도 있어 의견을 여쭈어 보았다고 하였다.

 

다행히 백엔드 팀원들 가치관이 모두,

일단 하나를 하더라도 제대로 구현하자 라는 방향이기에, 

의견이 모여졌다. 

 

일단, 프론트엔드 측에서 오늘 당장 시작해야 하는 작업이 아니고,

프론트엔드의 오늘 목표 업무가 따로 있다고 하여,

이 정도에서 백엔드의 방향성과 팀의 방향성 전달로 마무리 하고

매일 프론트엔드와 백엔드가 모이는 standing meeting이 있기에

내일아침 모두가 모였을 때 다시 협의하기로 하였다. 

 

그리고 추가로, 

"다른 팀과는 상관 없는 일이다.

다른 팀들이 한다고 해서 우리가 할 필요는 없다.

다른 팀들 중에서는 포토샵 하는 곳도 있다고 들었다.

 

우리도 그렇고 멘토님들께서도, 

기능 여러 개 구현하는 것보다, 

하나를 제대로 하는 것이 중요하다고 말씀하셨다." 라고 

다시 전달 드렸다.

 

아무래도, 1차 프로젝트와 

foundation에서도 그랬지만,

다른 동기들, 다른 팀원들을 쫓다가

방향을 잃을 수가 있기에,

 

나는 

팀의 방향성에 대해 

더욱

중요하게 생각하였다. 

 

그래서 2차 프로젝트에서는 pm을 해야 겠다고 다짐했고, po가 된 것이다.

 

 

---

0-2. 로그인  페이지의 '아이디/비밀번호 찾기' 를 추가할 것인지 

다른 프론트엔드 팀 보니 다들 하기로 협의한 듯하던데. 

 

---

1. 내일 프론트엔드에게 respond 뭐 줄지  mock data 만들기 

 

1-1. [팀의 진행방식과 효율성]

0번과 같이, 프론트엔드와 잠깐 이야기를 한 것과 마찬가지로, 

 

백엔드 내부에서도 방향성의 혼란이 잠깐 있었다. 

 

다른 백엔드 팀이 api와 router 설명을 강연처럼 pm이 팀원들에게 가르치고 있는데, 

다른 팀원들도 참여 가능하다고 해서, 

청강을 했었다. 

 

우리 팀원들도 어쩌다 보니 

혼자 api 짜기 전에 들어보고, 다른 팀은 어떻게 하는지 살피는 것도 학습적으로 도움이 되겠다 싶어서

청강을 하며, 각자 할 일을 하였는데,

 

그 팀의 경우에는, 

api를 페이지마다 분석하고, 

query, path 중에 어떤 파라미터를 쓸 것인지

예상하며 엑셀에 짜고 있었다.

 

그래서, 우리 팀의 테크리더인 pm에게 물어보니,

그럴 필요성은 없고,

코드 치고 난 뒤에 

마지막에 api 주소를 맞추어 보면 된다고. 

비효율적으로 하는 방법이라고 했는데 동의했다. 

 

나 또한, 팀의 Pm이 하루종일 팀원들을 세션에 배웠던 이론을 

다시 가르치는 것보다, 

 

각자 이론에 대해 학습하고,

막히는 부분을 모아서 

팀원들과 상의하는 것이 더 낫다고 생각한다. 

 

1-2. [다른 팀에 영향 받고 흔들리지 말 것]

괜히 우리가 다른 팀 하는 거 봤다가, 흔들렸다고 하니, 

테크리더인 pm이, 

"다른 팀은 안 중요해요, 

다른 팀 신경쓰지 마세요" 

했다. 

 

역시, 우리팀은 가치관이 비슷한 사람들끼리 모였다는 걸 

재차 깨달았다. 

---

1-3. [전략 수정]

우리는 프론트엔드의 편의를 위해 2주 프로젝트 중에, 1주차에 모든 api를 짜서 주기로 했는데,

백엔드의 코드와 api를 다 짜서 주기에는 무리일 것이라 생각이 들었다.

그렇다면, 

프론트엔드에게 mockdata를 만들어줘야 하는 건지, 프론트엔드가 직접 만드는 것인지, 판단을 했을 때,

칼럼이 몇 개인지, 어떤 칼럼의 이름인지가 변경되면 프론트엔드는 수정사항이 많아지기에,

그것을 미리 주기로 했다. 

 

 

그렇다면, 

내일 프론트엔드에게 응답값을 어떻게 줄지 정해보기로 

 

응답값을 어떻게 주느냐는, 

 1차 프로젝트의 mock data를 참고하면 된다

 

ex. 예시 

 

---

2.  api 회의

백엔드 팀원들이

각자 api를 내일부터 짜기에 앞서,

 

백엔드 팀원들끼리

사이트를 같이 보면서 

어떤 데이터가 필요할지, 구조화 해 보았다. 

 

[백엔드의 코드 구분]

그런데, 화면에 보이는 눈에 보이느 것으로 하다보니, 

프론트엔드가 신경 써야 할 부분을 

백엔드로 착각하는 경우가 있었다. 

 

가령, 카테고리별 다르게 보이는 화면 

상세페이지에서의 '장바구니 담기/ 결제하기' 버튼 구분

https://www.drmartens.co.kr/product/sandal-myles-brando-black-23523001

백엔드는 카테고리 구분 코드와, 각각의 장바구나/결제하기 코드를 주면 된다. 

---

<상세페이지> 

필요한 데이터

• Category
• Product Image
• Product Name 
• Product Option_color, size, amount 
• Product Price
• Product_ Detail 
• Product_review (추가기능으로 분류_우선순위에서 후순위)
• 여성, 남성 -> 프론트에게 가는 상세정보 페이지 api에 다 들어가야
• 리뷰 수 - 110건은 전체 갯수로 구현 
• 사이즈 -> 

product_detail

 

product review (추가기능)

우선 [고객의 주문부터 결제까지의 프로세스]에 중요한 기능을 MVP로 정했고,

이 기능을 추가할지 말지에 대해서 고민이 될 때에는,

1. 주문~결제 프로세스 여부

2. 영향을 주는 요소일 경우, 필수 요소인지

3. 선택사항(추가 기능)일 경우, MVP의 최소한의 기능을 중심으로 일정 안에 만드는 것을 우선순위로 하고, 후순위로 뺀다.

 

이것으로 프론트엔드와 백엔드,

그리고 백엔드 내부적으로도 협의하였다. 

---

<메인페이지>

category 여성, 남성, 키즈, sale 까지 

Subcategory - 부추, 슈즈, 샌들

If ( 카테고리 - Home > 남성,여성 나눠지는거  >정보 

• 카테고리에 정보가 들어감. 

 

정렬 - 랭킹 순 -> 판매량 (가짜 데이터로 어떤게 더 많이 판매되는지 

 

Pagination ->더 보기 나오면 또 나오게 

 

필터 > 색상 >query string (사이즈 동시에)

---

<주문 페이지> 에서 필요한 주소 검색 모듈

 

참고

 

https://postcode.map.daum.net/guide

Daum 우편번호 서비스

 

---

 

Project 2 3일차 백엔드 플랜 미팅 part1 

 

Project 2- 3일차: 백엔드 플랜 미팅 part1. dbmate (데이터베이스 생성)