230920 - 코드 리팩토링(클래스명 변경하기 + 도메인 줄이기)

1. 파일 구조 변경하기

2. 클래스명 변경하기 + 도메인 줄이기   📌

3. Domain - Alarm 

---

클래스의 이름이 명확하지 않아 해당 클래스가 어떤 기능을 포함하고 있는지 파악하기 어렵고, 일관성이 부족한 네이밍으로 인해 혼란을 초래할 수 있다고 생각했다. 또한, 공통적인 기능을 가진 클래스나 너무 많은 기능들을 한 클래스에 집약하는 경우에는, 이를 분리하여 관리하는 것도 고려하려 한다.

---

문제 : 일관성이 부족하고, 명확하지 않은 클래스명

• 같은 DTO클래스임에도 어떤 건 DTO가 붙어있고 어떤 건 DTO가 없다. 
• 이름과 기능의 연관성이 떨어져 혼란을 주는 클래스명 
• 자료구조명이 명시된 클래스

---

해결: 모든 클래스명을 적절하고 통일성 있게 네이밍

• DTO 클래스에는 모두 뒤에 Dto를 붙여준다.
• Alarm과 Notification은 알람과 알림이라는 뜻으로 혼동을 줄 수 있고, 이름만 봤을 때는 뭘 하는 기능인지 정확하게 파악하기 어렵다. NotificationControrller의 경우 SSE를 추가하여 네이밍 해준다.
• 자료구조명을 넣지 않고 복수 개의 데이터들을 담고 있다는 것을 명시해 준다.

추상화 수준의 불일치: 클래스나 객체의 이름은 그것이 무엇인지(what), 즉 그것의 본질을 나타내야 한다. 어떻게(how) 구현되었는지를 드러내는 것은 그 객체의 내부 구현에 대한 세부사항일 뿐이다. 따라서 List와 같은 자료구조를 사용했다는 사실이 클래스 이름에 포함되면, 추상화 수준이 일관되지 않게 된다.

변경 유연성 감소: 만약 나중에 List에서 다른 자료구조로 변경하게 되면, 클래스 이름도 함께 변경해야 한다. 이렇게 되면 코드 변경 범위가 넓어져 리팩토링 비용이 증가하고, 기존 코드를 사용하던 다른 부분에서 문제가 발생할 가능성도 있다.

오해의 소지: AlarmListResponse라는 이름을 보고 개발자들이 해당 클래스가 java.util.List 인터페이스를 구현하거나 확장한 것으로 오해할 수 있다.

+

SubAlarmResponseDto와 SubscribeHashtag라는 이름이 비슷하여 혼동을 줄 수 있을 것 같다.

그래서 SubAlarmResponseDto의 경우 구독한 '상태'를 나타내는 것이므로 AlarmSubscriptionStatusDto로 변경하였다.

---

 

문제 : 너무 많은 기능들을 한 클래스에 집약하여 가독성이 떨어짐

그리고 이 아래에 하나 더 있다.

• 이와 같이 너무 많은 기능들을 가지고 있는 클래스들이 존재한다. controller만 봐도 코드 가독성이 떨어지는데 Service는 얼마나 더 복잡할까? 관련 기능의 메서드를 수정해야 할 때 그 기능자체만을 찾는 데에도 더욱 수고스럽다.

 

해결 : 사용자 관련 기능과 그렇지 않은 기능을 구분[POST]

• PostController ➡️ PostUserController와 PostNonUserController로 분리
• PostService ➡️ PostUserService와 PostNonUserService로 분리

해결 : comment와 recomment의 기능을 분리[COMMENT]

• comment와 recomment의 기능을 분리
• dto, entity, repository의 경우에는 두 개의 영역이 분리되어 있지만 controller단이나 service단은 이 두 가지의 기능들이 합쳐있어 뭔가 통일성이 떨어져 보이며 둘이 이름도 비슷하여 가독성이 더 떨어졌다.
• 더하여 @RequestMapping() 또한 구분되게 하여 클래스의 통일감도 주었다.

수정 전

comment와 recoomment 분리

---

문제 : 프로젝트 크기에 비해 많은 Domain

• 프로젝트 크기에 비해 Domain이 많아서 복잡하고 관리가 어렵다.

해결 : 작은 도메인의 경우 관련된 곳에 포함시켜 Domain의 수를 줄임

• Like ➡️ post, comment

 

• scrap ➡️ post
  • serap을 postScrap으로 명시한 뒤에 post domain으로 포함시킨다.
  • postUserController/ Service에 있던 scrap한 post 조회 기능은 postScrap관련 클래스로 옮겨준다.

• social ➡️ auth
  • 소셜로그인도 인증, 인가 관련된 부분이므로 auth에 포함시킨다.

• search ➡️ post
  • 이 검색 기능은 post에 대한 검색 결과만을 나타내므로 post로 포함시켜 주었다.
  • 마찬가지로 통일감을 위해 Search를 PostSearch로 명시해 주었다.
• tag ➡️ post
  • 태그에 관련된 기능도 결국에는 Post 쪽에만 국한되어 있다. 그래서 post 쪽으로 포함시켜 주기로 하였다.
  • 더하여 tag의 기능들은 user에 대한 정보가 없어도 조회가 가능하므로 PostNonAuthor 쪽에 포함시킨다.

• report ➡️ 다른 domain에 포함시키려 했지만 로직 특성상 그대로 두기로 하였다.
  • 신고는 post, comment, recomment에 대한 것들을 신고 할 수 있는데
  • reportType으로 받아서 쓰고 있기에 따로 api를 따로 분리해 다른 domain들에 포함시키는 것보다는 그냥 두는 게 더 낫다고 판단하였다.
  • 또한 아직 신고기능은 미완성인 그냥 껍데기만 만들어 놓은 수준에 불과해서 섣불리 나눠버리지 않고, 신고 기능에 대한 새로운 기능을 추가하게 될 경우에 다시 생각해 볼 것이다.

---

수정 이전에는 domain별로 분류했다기보다는 기능별로 분류되어 있다고 보는 게 맞겠다. 이번 기회를 통하여 어떻게 하면 좀 더 효율적으로 파일과 클래스들을 관리할 수 있는지에 대해 배우게 되었다.

+ domain을 분류하다 보니 클래스마다 중복되는 로직들이 많이 보였다. 따로 추상클래스나 인터페이스 등으로 중복되는 로직들을 하나로 합쳐서 쓸 수 있도록 하여 좀 더 객체지향적인 코드로 수정해보고자 한다. 

그리고 실전프로젝트 때에 구현할 기능이 너무 많아서 성능적인 면을 고려하지 못한 부분들이 많은데 그 부분들 또한 하나씩 고쳐서 좋은 코드로 재탄생시켜 보려 한다.