refactor : improve follow api

[chadongmin]

Resolves #{이슈-번호}

해결하려는 문제가 무엇인가요?

• 특정 유저가 팔로잉하고 있는 유저 정보

• 특정 유저를 팔로우하고 있는 유저 정보

• 위 두 가지 케이스를 각각 api로 분리했습니다.

• follow 엔티티의 User 타입으로 가지고 있던 follower_user_id 필드를 Long으로 수정했습니다.

어떻게 해결했나요?

어떤 부분에 집중하여 리뷰해야 할까요?

참고 자료

---

RCA 룰

r: 꼭 반영해 주세요. 적극적으로 고려해 주세요. (Request changes)
c: 웬만하면 반영해 주세요. (Comment)
a: 반영해도 좋고 넘어가도 좋습니다. 그냥 사소한 의견입니다. (Approve)

[Whale0928]

이전 리뷰때는 컨펌했지만, 수정사항을 보면서 이 구조에 대해 다시 생각해보게 되네요.

타입 파라미터로 두 API를 합친게 어떤 장점이 있을지 궁금합니다. 응답도 다르고 책임도 모호해진 것 같은데, 확장성이 고려하신건가요? 그렇다면 새로운 타입 추가마다 if문 분기가 늘어날 텐데 이 방향이 맞을지 고민이 되네요.

/following, /followers로 나뉜 기존 구조도 충분히 직관적이었던 것 같은데, 어떻게 생각하시나요?

[chadongmin]

이전 리뷰때는 컨펌했지만, 수정사항을 보면서 이 구조에 대해 다시 생각해보게 되네요.

타입 파라미터로 두 API를 합친게 어떤 장점이 있을지 궁금합니다. 응답도 다르고 책임도 모호해진 것 같은데, 확장성이 고려하신건가요? 그렇다면 새로운 타입 추가마다 if문 분기가 늘어날 텐데 이 방향이 맞을지 고민이 되네요.

/following, /followers로 나뉜 기존 구조도 충분히 직관적이었던 것 같은데, 어떻게 생각하시나요?

리뷰 반영하여 수정했습니다 리뷰 부탁드려요 👍

[Whale0928]

필드명과 생성방식만 수정하고 마무리하죠

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud