Wecode 2st Project 회고록

 

 

 

 

5kea product main page(상업적 용도가 아닌 오직 교육적으로 project에 한해 사용되었습니다.)

 

 

1.  팀 소개

 ▶ Team Name:  5ronaminC

 

▶ 팀 구성원:  FrontEnd 2명, BackEnd 3명으로 구성되어 총 5명과 함께 이번 프로젝트를 진행하게 되었다. 

 

2. 프로젝트 소개 

① 프로젝트 기간: 2023.8.18 ~ 2023.09.01 (약 2주) 

 

② 사용한 기술 스택

🔧  BackEnd Tech

Javascript, NodeJs, Express, Mysql

 

 🔧  FrontEnd Tech

React, Javascript, HTML, Sass

 

 

③ About 2st Project:

 1st Project와는 다르게 프론트와 백엔드가 한 팀으로 구성 되어 하나의 Product를 정하여 만들어 가는 과정을 경험 했다. 수익성을 가진 대부분의 웹 서비스가 지닌 회원, 상품, 주문, 결제 4가지 핵심 요소를 기반으로 팀내에서 결정한 제품의 가치를 전달하는 웹 서비스 즉, 하나의 Product를 만드는 과정이 이번 프로젝트의 핵심이었다고 생각한다. 

 

④ Team Product:  IKEA 

저희 팀의 웹 서비스는 IKEA가 선택이 되었고 IKEA 웹을 기준으로 PET 분석을 통해 IKEA의 장점만을 살려 웹 서비스를 구성하기로 했다.

 

3.  IKEA PET 분석

<  PET란? >

- P: 우리 서비스가 지니는 Product 관점에서 가치를 분석하며 

- E: 우리 서비스를 이용할 가상의 End-User를 분석하고 

- T: 우리 서비스가 사용할 Tech를 분석합니다. 

 

▶ IKEA의 특징

 

각자 담당 티켓을 할당 후 본인이 맡은 티켓에 대해서만 분석을 하는 것으로 이야기 하여 내가 맡은 티켓인 제품을 보고 PET 분석을 하였다. 

이후 모든 내용을 보고 따로 모든 내용에 대한 나의 PET 분석을 따로 하여 Team PET분석과 내가 정리한 모든 PET 분석 내용을 따로 정리 하였다. 

 

개인 PET 분석 내용

Team PET 분석 내용

 

4. 구현 기능

기능 요구 정의서 보기

 

필수 구현 사항 

① 메인

② 로그인/회원가입

③ 상품 리스트 

④ 상품 상세 

⑤ 장바구니 

⑥ 결제

 

추가 구현 사항 

① 회원가입 - 약관선택(체크박스) 

② 상품 - 캐러셀 하단 이미지 버튼

③ 상품평 - 별점으로 표현, 수정, 삭제 기능

④ 제품 상세, 장바구니 하단 - 추천 제품 나열 

⑤ 장바구니 - 픽업 매장 선택, 제품 번호로 제품 추가, 위시리스트 제품 추가, 상품 수량 변경 

⑥ 결제 - 배송지, 연락처 수정

 

5. 담당 역할(담당 티켓) 

1️⃣ ERD 설계 및 수정

PM과 함께 DataBase의 Table에 들어가야 할 Column을 설정하며 Table관 서로 관계 맺어야 할 Key값들을 설계 하며 

추후 사용 될 데이터 뿐 아닌 서비스의 확장성까지 고려하여 DB를 설계 하였습니다. 

코드를 작성하며 추가적으로 수정해야 할 부분들과 추가해야 하는 경우 설계한 사람과 논의하여 스키마 파일을 작성하여 

수정하여 공유하였습니다.

 

2️⃣ DB 생성 

DBMATE를 활용하여 Table 관의 참조 등 연계성을 생각하며 순차적으로 Table을 생성될 수 있게 순서를 정하여

모든 Table의 스키마를 작성했습니다.

 

Table 생성 순서

Preferred_stores  → Users → colors → category_spaces → category_types → size_options → coordinates → products → product_images → showroom_images → reviews → Carts → Wishlists → order_status_codes → Orders → order_items → payment_information

 

3️⃣ 제품 상세 페이지 

이번 5KEA는 로그인을 해야만 메인페이지 및 제품 상세 페이지를 볼 수 있도록 하여 해당 제품 상세 페이지를 들어가기 전 token의 여부를 확인한 후 데이터를 넘기도록 하였다. 

제품 상세 페이지에 필요한 데이터들을 쿼리문을 작성하여 보내주었으며 한 제품에 여러 imageUrl이 존재하여 한 Row에 해당 imageUrl를 컴마(,)로 구분하여 데이터를 전송했다. 

하단 내용은 제품 상세 페이지에 필요한 데이터를 전송하는 쿼리 문이다.

SELECT 
    p.id AS id,
    GROUP_CONCAT(pis.product_image_url) AS imageUrl,
    p.product_name AS name,
    p.price,
    p.description,
    p.width,
    p.depth,
    p.height,
    p.assembly,
    cs.category_space_name AS spaceName,
    ct.category_type_name AS typeName,
    p.coordinate_id AS coordinate,
    (SELECT COUNT(product_id) FROM reviews WHERE product_id = ?) AS totalReview,
    co.color_name  AS colorName
FROM products p
LEFT JOIN product_images pis ON p.id = pis.product_id
LEFT JOIN category_spaces cs ON p.category_space_id = cs.id
LEFT JOIN category_types ct ON p.category_type_id = ct.id
LEFT JOIN colors co ON p.color_id = co.id 
WHERE p.id = ?

 

4️⃣ 장바구니 담기 (Table에 Data Insert 하기)

고객이 제품 상세페이지에서 장바구니를 누를 때 해당 user Id, product Id, product Quantity를 DB TABLE에 담을 수 있는 API를 만들었다. 

 

Client에서 전송해주는 Data =  product Id, product Quantity

① carts Table에 동일한 UserId And ProductId가 없는 경우 Data Insert 하는 모듈이 작동 

② carts Table에 동일한 UserId And ProductId가 있는 경우 Data Update 하는 모듈을 작동

③ UserId는 Header에 들어있는 Token 값을 해석하여 UserId를 가져옴

 

5️⃣ 상품평 작성 및 리스트 보여주기

① 고객이 특정 상품에 대해 작성을 하면 해당 productId와 상품평(content)를 reviews Table에 Insert 해주는 API를 만들었다.

- Client에서 전송해주는 Data =  product Id, reviews Content

- UserId는 Header에 들어있는 Token 값을 해석하여 UserId를 가져옴

 

② 고객이 특정 상품에 대한 review 리스트를 누를 경우 리스트 Data를 전송하는 API를 만들었다.

- Client에서 전송해주는 Data =  product Id

SELECT *
FROM reviews 
WHERE reviews.product_id = ?;

 

 

6️⃣ DB TABLE에 제품 DATA INSERT 하기

쇼룸에 대해 호버 되는 각각의 제품들은 특정 좌표값을 가져 프론트에서 해당 좌표값을 계산하여 보내주면 

모든 제품의 해당하는 이름, 설명, 좌표값, imageUrl 등등 DB Table에 모든 Data를 참조하는 키 값을 생각하여 순차적으로 DB Table에 DATA를 넣어 해당 Data Insert 구문을 공유하였다.

 

6. ABOUT GOOD & PROBLEM

👍 GOOD

- ERD 설계 및 기획을 오래 계획한 것

이번 프로젝트에서는 ERD를 직접 설계하며 기획하여 해당 데이터들이 어떠한 구조로 되어 있으며 어떠한 값을 참조하여 연결되는지 정확하게 파악할 수 있는 시간을 가졌다. 또한 해당 Table들을 생성할 때 직접 순서를 작성하여 스키마를 순차적으로 생성하여 Table을 만들어 이후 DB를 수정할 때 조금 더 수월하고 쉽게 수정할 수 있었으며 데이터를 가져오고 쿼리문을 작성할 때도 조금 더 수월하게 사용할 수 있었다.

프로젝트 시작 이후 ERD를 건드리는 일을 줄이기 위해 다른 팀들보다는 ERD 설계에 조금 더 시간을 투자 하며, 기획 또한 추후 뒤집어지는 불상사를 막기 위해 충분히 서로 검토하며 회의하는 과정을 거쳐 우리 Product에 대한 목표를 뚜렷하게 정하고 설계 할 수 있던 경험이 소중했던 거 같다. 

 

- 오류와 해결되지 않는 문제에 대한 공유

백엔드 팀원들과 계속해서 해결되지 않는 문제에 대해 공유하며 해결 될 경우 오류 해결에 대한 방법들을 공유하는 시간들을 가졌던 것에 대해 서로 서로가 조금 더 성장할 수 있는 시간을 가졌다.

많은 오류들과 마주하며 동일한 오류가 발생했을 때 조금 더 짧은 시간내에 해당 오류를 해결할 수 있었다. 

 

🥴 PROBLEM

- 쿼리 빌더 미적용 

이번 프로젝트에서는 쇼룸을 제품 리스트로 생각하여 쿼리 빌더를 적용할 필요가 없는 기획이 이번 프로젝트에서 제일 아쉬운 점이었다. 하지만 개별적으로 쿼리 빌더를 작성하여 적용할 예정으로 추후 프로젝트에서 쿼리 빌더를 적용할 때 어려움이 없도록 하기 위해 개별적으로 쿼리 빌더를 작성할 예정이다.

 

- 추가 기능 구현 미흡

추가 기능을 따로 정하고 두었지만 해당 추가 기능 구현을 하지 못했던 것에 대해서 아쉬움이 남는다. 

2주라는 짧다면 짧고 길다면 긴 시간에서 신제품 유무 판단, 상품평 수정 및 삭제 등 추가 구현 사항을 구현하지 못했던 것에 아쉬움이 있으며 해당 사항 또한 개별적으로 시간이 내어 빌드업 할 예정이다. 

 

- 하루하루 기술 구현에 대한 기록 및 오류 사항 미작성

코드를 작성하고 구현하는 것에만 몰두하여 오류 사항과 하루하루에 대한 코드에 대해 평가 기록하는 시간을 갖지 못했던 것이 

아쉬움으로 남는다. 오류사항들을 발생할 때 조금씩 적어 두었지만 더 많은 오류 사항들을 마주하였고 해당 오류들에 대해서 적지 못했던 점이 다음 프로젝트 진행 시 매일매일 기록해야겠다고 다짐한 사항이다.