[쿠스토랑] 리팩토링(2) - 평가/평가 댓글 기능의 문제점과 개선안

[쿠스토랑] 리팩토링(2) - 평가 댓글 기능의 문제점과 개선방안

---

 앞서 이미 언급한 큰 문제중 하나로, 다양한 엔티티들이 타 Entity자체를 리스트로 가지면서 불필요한 양방향 연관관계 매핑이 복잡하게 되있는 상황을 보았다. 우선적으로는 User Entity자체가 가지고있던 양방향매핑관계인 다양한 엔티티들을 id만으로 참조하게 바꾸면서, 당연히 여러 문제가 발생했고 기능들을 정상작동하도록 고치는 과정에서 이번엔 음식점에 달린 평가/평가 댓글 기능에 대해서 살펴보고자 한다.

 

문제점들이 무엇이였고 어떻게 개선되었는지만 간단하게 적어보겠다.

 

1. 적절하지 못한 네이밍과 적절하지 못한 패키지구조

•  RestaurantComment~ 로 작성된 클래스들 이름을 EvaluationComment~ 로 바꾸었다.
•  Restaurant 에그리거트 내에 위치한 클래스들을 Evaluation 에그리거트 내부로 옮겼다.

 평가기능에 댓글을 구현하는 다양한 기능들은 실제로 RestaurantComment~로 작성되있었다. 나는 처음에 해당기능이 내가 담당했던 부분이 아니라 직관적으로 받아들이기가 상당히 힘들었다. 하지만 다양한 클래스들을 넘나들며 파악해본결과, restaurant 보다는 evaluation 영역 내에서 훨씬 많이 관련되 있다는것을 알았다. 또한 실제로 평가에 대해 댓글을 남기는것이기 때문에 restaurant 보단 evaluation쪽이 훨씬 적절하다고 생각했다.

 또한 평가/평가댓글에서 각 호칭을 내부적으로 커멘트/대댓글 등으로 사용하고 있었다.

호칭에 통일성이 필요했고, 평가/ 평가댓글로, 이모두를 통합해 리뷰 로 호칭하기로 하였다.

 

2. 원초적(?)이고 초보적인(?) 문제다. DTO가 entity를 직접 품고있다. ㅋㅋ

3. 로직 자체가 여러모로 비효율적 ...

ex1) 좋아요,싫어요 기능이 개별 메서드로 작성되있었는데 인자로 좋아요/싫어요 까지 같이 넘겨주게 하여 하나의 매서드에서 분기로 처리하게 하였다.

ex2) 좋아요,싫어요 테이블이 개별로 있었기 때문에 관련 기능을 서비스레이어에서 구현시 각 db에 접근하는일이 경우에따라 최소 2회가 필요했다. 내부적으로 필드를 두어 좋아요,싫어요를 구분하고 하나의 테이블에서 좋아요/싫어요 정보를 모두 취합하였다. 또한 이는 코드적으로도 간결해지는 효과를 가져왔다.

 

4. SRP가 지켜지지 않았다.

 우리 서비스는 음식점에 달린 평가에도 일반 유저가 다시 댓글을 달 수 있다. 따라서 평가 자체 /평가에 달린 댓글에 각 좋아요 기능이 있는데 이 두 개별 도메인에서 좋아요 기능들을 각 하나의 매서드로 수행하고 있었다. 또한 컨트롤러에서 반환해주는 타입 역시 단 하나의 dto를 가지고 여러곳에서 사용하고 있었는데 그러다 보니 대부분의 필드가 null로 넘어가거나 특정 기능을 위해 필요한 개별적 매서드들이 한군데 모여 몸집이 거대해진 상황이 발생했다.

 따라서 각 평가/평가댓글 로 둘로 분리하고 컨트롤러에서도 각 영역에 맞는 적절한 response dto 클래스를 정의하여 사용하게 하였다.

 

5. 정해지지 않은 정책이 있었다.

 우리 서비스의 식당은 하위 메뉴/리뷰 뷰로 나뉘게된다. 여기서 리뷰 뷰가 평가,평가 커멘트를 모두 일괄적으로 반환하고 있다. 물론... 이걸 굳이 나눠야 할 만큼 규모가 크지 않은건 사실이다 (ㅜㅜ) 하지만 확장가능성 측면에서 고려해 본다면 평가 댓글이 여러개 달린경우 몇개까지 표시할건지, 이후 무한스크롤로 추가적으로 더 표시할건지, 평가는 최대 몇개까지 표시할건지 등과 같은 정책이 전혀 구비되어있지 못했다.

 

6. API가 resful하게 설계되지 못했다.

  생성에 관한건 201응답으로, 삭제에 관한건 204응답으로 내려주게 했다. 거의다 200응답으로 사용되고 있었다. 우리의 첫 프로젝트였기 때문에 기타 자잘한 문제점도 많았다. 엔드포인트 또한 개선필요가 있는 부분이 있었다.

---

  이전에는 평가 와 음식점간 코맨트가 분리되어 있었다. 지금은 그 어디나 그렇듯 평가에 코맨트가 포함되어 있는데, 웹 서비스의 큰 반응 이후 앱 서비스까지 확장하면서 다양한 사람들이 PM같은 역할을 분리없이 하다 보니 결국 지금의 방식으로 변경되었다.

 

 실제로 평가를 하지 않고 커맨트만 남긴 댓글들도 적당히 있긴 했었다. (실제 이뤄진 평가 대비 많진 않았음) 그 데이터들은 지금의 방식으로 변경하면서, 다 hard delete 처리 되어버렸다. 난 매우 반대했지만 다수결결정에 따라 결정되었다.

 

 개인적으로 지금 다시 와서 생각하면 평가와 커맨트의 분리가 더 나은 방안이였다고 생각한다. 그 근거는 대충 두가지이다.

 

1. 평가가 간소화된다. 사용자들로 하여금 평가 행위의 부담을 줄여줄 수 있다. 별점만 선택하면 끝난다. 길게 최소 글자수를 채우며 굳이 커맨트를 남기지 않아도 된다. ( 평가 간소화의 목적성으로 지금 우리 서비스도 사실 커맨트 없이 평가만 진행할 수는 있긴하다)

2. 앞서 미약한 사례이지만 평가하지 않고도 커맨트만을 남겨주는 사용자도 분명히 있긴 했다. 쿠스토랑 과 같은 서비스 특징상 어떻게든 여러 사용자로부터 평가 데이터를 수집하는게 너무 귀하다고 개인적으로 판단하는데, 이 목적성과 일맥상통하는 정책이라고 생각하기 때문이다.

 

리팩토링 중 아쉬운 과거의 정책을 ... 한풀이하는 글로 마무리한다.