본문 바로가기

스프린트 회고

메가테라 3주차 스프린트 회고

저번 주 스프린트의 목표는 범위를 좀 보수적으로 잡아서 상품 상세페이지를 모두 구현하기. 

 

결과만 보면 75프로 정도 달성한 것 같다. 핵심적인 기능은 장바구니 추가와 , 리뷰 불러오기 및 추천 기능 페이지네이션, 상품 문의글 작성하기 및 불러오기, 비공개 글 작성하기 , 상품 문의 페이지네이션까지가 이번 주 스프린트 목표였는데 사실상 리뷰 쪽 task가 어제 마무리가 되어서 상품 문의 쪽 기능은 거의 작업을 하지 못한 상태이다. 

 

이번 주 는 리팩토링을 한 3번 정도 했는데 첫번째는 JPA의 Entity는 Collection을필드로 가지고 있을 수가 없다는 점 때문에 OneToMany를 사용하여 도메인 모델을 리팩토링하고 2번째는 OneToMany는 JPA를 다루는 기술이지 객체 설계를 잘하면 굳이 사용할 필요가 없다란느 것을 알게되어서 포트폴리오를 아주 객체지향적으로 만들어 보고자 다시 OneToMany를 지우고 Product란 모델이 

가지고 있는 이미지나 찜하기 숫자 같은 것들을 Product의 아이디를 가지게 만들어서 다시 한번 리팩토링을 했다. 

 

하지만 이렇게 만드니 모든 정보를 Product가 가지고 있는 문제가 발생했다. 

 

 

지금보니 상품의 상세정보를 불러오는 컨트롤러인데 컨트롤러가 굉장히 뭐가 많다. 단순히 상품의 상세정보를 불러오는데 다른 

다른 서비스를 여러개 호출하는 모양이 되버렸다. 

 

그리고 다른 서비스들은 그냥 repository만 호출해도되는 굳이 인터페이스가 필요가 없는 형태이다. 

 

하지만 2차 리팩토링에서는 이 모양을 리팩토링한게 아니라 Review같은 경우는 도메인 모델로 분류를 해서 컨트롤러를 따로 만들어 주는 형태로 

 

 

이렇게 리뷰는 따로 컨트롤러를 만들어서 프론트엔드(리액트)에서 상품상세페이지가 마운트 될 떄 2개의 API를 호출하는 방식으로 만들었다. 

 

하지만 이것도 URI가 이상하다. reviews/{productId}로 만들었는데 이것도 조금 이상한게 ProductController에서는 

상세페이지를 보여주게 URI를 설계했는데 여기서는 상품에 맞는 리뷰를 보여주게 만든 상황이다 .

 

그래도 여러개의 API를 호출해서 프론트엔드에서 데이터를 화면에 보여주는 것은 나쁘지 않은 방향이였던 것 같다.

 

이렇게 리팩토링을 여러번 해봤지만 좋은 형태로 리팩토링이 되지는 못했다. 하지만 이게 좋은 것이 아닌 걸 알았다는 것 이 중요한거 아닐까?

 

그래서 어떻게 리팩토링을 할 것이냐?

일단 컨트롤러의 이름에 맞게 리팩토링을 해야한다. ProductCotroller는 딱 productService.detail 메소드 하나로 ProductDto를 반환하게 하고 이미지나 옵션 찜하기 같은 친구들은 ProductService에서 각각의 Repository들을 불러서 처리를 하는 방식으로 그리고 

Service안에서 다른 Service를 호출하는 방식으로 하면 리팩토링이 가능할 것 같다. 

 

 

딱 이형태로만 있게 리팩토링을 다시! ㅋㅋ  진도를 빨리 나가는 것도 중요하지만 제대로 테스트코드를 작성을 하기가 어려워 지면 

뭔가 잘못됬다라는 신호이다. 이 신호를 무시하지말자. 제대로 만들어보자

 

 

'스프린트 회고' 카테고리의 다른 글

스프린트 6주차 주간회고  (1) 2022.11.28
스프린트 5주차 주간회고  (0) 2022.11.21
포트폴리오 1주차 스프린트 회고  (0) 2022.10.31