포트폴리오 1주차 스프린트 회고

이번 주 부터는 포트폴리오의 기획을 끝마치고 본격적으로 개발에 들어갔다. 

 

1주차 스프린트 작업 내용은 

 

 

 

상품 상세페이지의 상품 정보 및 

 

 

관리자가 상품을 등록할 때 작성하는 상품 설명 부분을 목표로 잡았다. 

 

 

결과적으로는 이번 주 목표를 달성하지 못했다. 달성률은 80퍼센트 정도로 측정

 

달성하지 못한 20%는 찜하기 및 장바구니 기능이다. 

 

 

스프린트를 달성을 못했으니 멍석말이를 당해야 하겠지만 1주차이니 너그럽게 넘어 가는 걸로 하자. 

 

이번 주 아쉬웠던 점 

 

1. 상품의 이미지를 관리하기 위해 AWS S3를 사용을 했는데 AWS에 회원가입을 하는 데 꽤나 에를 먹어서 

의미없게 시간을 좀 쓴게 많았고 AWS를 사용하기 위해 IAM이나 BUCKET설정에 시간을 꽤나 많이 빼앗겼다. 

그래도 다음번에 사용할 때 는 애먹지 않도록 기록을 해놨다.

 

2. 작업 설계 및 기록을 소홀히 했다.

작업 설계를 하고 난뒤 개발을 시작하는 것 보다 거의 주먹구구 식으로 일단 하고 끼워 맞추는 식으로 했는데 

이렇게 하면 안되는 이유를 깨달아 버렸다. 상품 찜하기 기능도 작업 설계를 하지 않고 바로 개발부터 하려고 하니 

복잡한 기능은 손도 못대고 시간을 보냈다.

 

액션플랜  : 요구사항 먼저 작성하기

1. 요구사항을 적는다.

2. 모델 설계(필드 값으로 어떤 값이 들어가고 다른 모델들과 어떤 협력관계가 있을 까를 알아본다, url설계)

3.  프론트엔드에서 백엔드까지 프로그램 흐름도를 적어본다.

4. 3번의 과정을 구현하기 위해서 해야할 일을 적어본다.

 

 

1.  찜하기 버튼 클릭시 유저가 로그인 상태가 아니면 로그인 페이지로 이동, 

 1-1: 로그인 페이지에서 로그인을 하면 다시 찜하기 버튼을 눌렀던 상품의 상세페이지로 돌아옴

2. 찜하기 버튼 클릭시 찜하기 숫자 + 1 , 찜하기가 되어 있는상태라면 -1

3. 찜하기 버튼 클릭시 마이페이지의 찜 목록에 상품이 추가되어야 한다.

4. 찜하기를 취소하면 찜 목록에서 상품이 삭제되야 한다.

 

 

모델 설계

1. USER라는 모델 구상

    유저는 id와 로그인할 때 사용하는 아이디, 비밀번호, 주소 , 이름을 필드로 가지고 있어야 하고 LIST형태로 찜 목록을 가지고 있을 것인가? 일단 보류

 

2. WISH 모델 구상

    wish를 모델로 빼기로 결정을 하고 product의 wishes는 단순히 LONG형태의 숫자만 가지고 있도록 한다.

    wish는 id와 userId, productId를 들고 있어야 한다.

    userId와 productId는 사용자가 상품을 찜을 했는 지 여부를 알아야 하기 때문에 가지고 있어야 한다고 판단.

 

wish모델이 user의 Id를 들고있기 때문에 user의 필드에 위시리스트를 굳이 가지고 있을 필요가 없을 것 같다.

 

POST /products/wishes/productId 

wish모델을 생성하고 찜하기 목록에 추가를 하기 때문에HTTP 메서드는 POST로 정했다.

프로그램  흐름도

 

프론트 엔드

 

사용자가 찜하기 버튼 클릭 => productStore의 fetchWishes함수 호출(productId, accessToken)을 가지고 =>

productService클래스 에서 productId, accessToken을 전달 받아 productId는 URI로 , accessToken은 

headers : Bearer(accessToken)의 형태로 API서버로 전달 => 

 

백엔드

 

ProductController에서 productId는 pathVariable로 accessToken은 requestAttribute를 통해 userId로 변환 =>

wishRepostirory에서 userId를 통해 wish 리스트를 반환(찜한 상품이 여러개일 수 있기 떄문이다.)

 

위시리스트에서 productId를 가지고 있는 wish가 없다면 새로운 wish(productId, userId)를 생성하고 repository에 저장

및 productRepository에서 상품을 찾은 뒤 해당 상품의 wishes + 1 =>

 

반대로 productId가 이미 존재 한다면 wishRepository에서 해당 wish를 삭제 product의 wishes -1=> 

 

컨트롤러는 wishes를 반환

 

 

해야할 것

1. backdoorAPI를 통해 유저를 세팅한다. 

2. 평문인 password를 암호화 하기 위해 Argon2passwordEncoder를 install한다. 

3. 밥 먹고 싶다. 

4. 기타 등등 

 

사실 3번과 4번은 별로 중요하지 않다. 개발 하면서 저 대로 되는 경우가 거의 없는 것 같다. 하지만 최소 1번과 2번 정도는 해야 한다.

 

1번은 그대로 인수 테스트로 만들 수 있고 2번은 모델을 설계를 하지 않으면 나중에 전부 다 싹다 갈아엎어야 할 상황이 발생하면 멸망

 

 

 

 

2주차 스프린트의 목표는 상세페이지를 전부 구현하는 것이다. 리뷰 및 상품 문의는 대댓글 기능도 있고 아무튼 어려울 것 같아 범위를 

보수적으로 잡았는데 상품 리스트까지는 완료 할 수 있도록 하자