[BE] 방 매칭 실패 시 매칭 실패 원인을 전달하는 기능 구현(#562)

[github-actions]

📌 관련 이슈

• closed : [BE] 방 매칭 실패 시 매칭 실패 원인을 전달하는 기능 구현 #562

✨ PR 세부 내용

매칭 실패 원인을 프론트에 전달하는 기능을 구현했습니다.
구현 방식은 FailedMatching이라는 별도의 엔티티를 추가하여 매칭이 실패했을 때 관련 정보를 저장하고, 방을 조회할 때 실패 원인을 같이 전달하는 방식으로 구현하였습니다.

@Entity
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class FailedMatching {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private long roomId;

    @Enumerated(EnumType.STRING)
    private MatchingFailedReason reason;

    public FailedMatching(long roomId, ExceptionType exceptionType) {
        this(null, roomId, MatchingFailedReason.from(exceptionType));
    }

    public String getMatchingFailedReason() {
        return reason.getMessage();
    }
}

처음에 MatchResult 내부에서 상태를 가지도록 할까 고민했다가, 다들 알듯이 저희 MatchResult는 엄청 많이 생성되고 많이 아프잖아요,,.
그래서 여기에 추가 컬럼을 넣으면 성능 저하가 발생할 것을 우려되었습니다.

그래서 매칭이 실패한 경우에만 저장되는 FailedMatching 엔티티를 따로 구현하는 방식이 더 적합하다고 판단하고,
이렇게 하면 불필요한 데이터 저장을 최소화하면서도 매칭 실패 원인을 효과적으로 관리할 수 있다 생각됩니다.

아무리 생각해도 이 방법이 최선이고, 제일 좋은듯합니다. (혹여나 다른 의견 있다면 적극 환영입니다.) 😀

[github-actions]

Test Results

 49 files   49 suites   7s ⏱️
154 tests 148 ✅ 6 💤 0 ❌
163 runs  157 ✅ 6 💤 0 ❌

Results for commit 6181de9.

♻️ This comment has been updated with latest results.

[hjk0761]

프론트에선 roomResponse 에서 메시지가 비었냐 아니냐로 오류 페이지를 판단하게 되는군요
고생 많았어요!!

[ashsty]

변경 범위가 조금 크네요 0ㅁ0
전반적으로 문제 없을 것 같아요. 간단한 코멘트 하나만 남겨두었는데 확인해주시면 되겠습니다.

고생하셨어요!

[ashsty]

이 클래스가 분리된 이유가 뭔가요? ㅇ.ㅇ

[jcoding-play]

각 실패 원인에 대한 메시지 관리를 따로 하고 싶어서 분리했어요!

MatchingFailedReason에서 메시지까지 같이 가지고 있으면 너무 코드가 길어지더라고요.
그리고 레벨 1때 배운 내용들 생각하면 클라이언트 출력용 메시지는 따로 관리하는 것이 적절한 역할 분리라고 생각이 들었습니다.

애쉬는 너무 과한 분리라고 생각이 드신건가요?? 🧐

[ashsty]

상태마다 할당되는 메세지가 각각 하나이다 보니 그냥 enum에서 메세지까지 같이 관리해도 되지 않을까... 싶더라고용.

MatchingFailedReason이 추가될 때마다 MatchingFailedMessageClassifier까지 함께 수정되어야 한다는 점에서
관리 포인트가 늘어날 것 같다는 생각도 듭니다.

그래도 다른 분들 괜찮으시면 수정할 필요는 없을듯요~~ 👍👍

[youngsu5582]

코드적인 면으로는 클린코드 일거 같은데
관리적인 면에서 귀찮을거 같긴 하네요.

추가로, ENUM 이 늘어날 때 메시지를 실수로 추가하지 못할 우려가 생길꺼 같은데
switch - case 구문을 써서 넣는게 좋을거 같아용 🙂

[jcoding-play]

MatchingFailedReason에서 관리하도록 수정했고,
switch-case는 사용하지 않고 그냥 매개변수로 갖도록 수정했어요!~

[jcoding-play]

프론트에선 roomResponse 에서 메시지가 비었냐 아니냐로 오류 페이지를 판단하게 되는군요
고생 많았어요!!

그렇지 않고, 프론트에서 오류 페이지는 먼저 RoomStatus.FAIL 상태를 통해 먼저 판단합니다.
message는 단순히 FAIL일 때 실패한 이유에 대해 전달하는 용도입니다~!

[youngsu5582]

의견 제시한 것도 한 큐에 진행할 수 있을거 같아서 APPROVE 드립니다!
수고했어용 뽀로로 🙂

[youngsu5582]

여기서 NOT_FOUND_ERROR 를 던지면 다음 흐름은 어떻게 되나요?

UNKNOWN_ERROR 와 같은 ENUM 값을 만들고
하는건 어떨까요?

( 매칭을 실패했는데 해당 REASON 이 없어서
FAIL 이나, FAILED_REASON 이 없어서 예외 발생할 거 같은 우려 )

[jcoding-play]

UNKNOWN_ERROR 와 같은 ENUM 값을 만들고
하는건 어떨까요?

좋네요~ 수정했습니다.

[youngsu5582]

코드적인 면으로는 클린코드 일거 같은데
관리적인 면에서 귀찮을거 같긴 하네요.

추가로, ENUM 이 늘어날 때 메시지를 실수로 추가하지 못할 우려가 생길꺼 같은데
switch - case 구문을 써서 넣는게 좋을거 같아용 🙂

[youngsu5582]

당장은 이렇게 구분하는게 최선일 거 같긴 하네요.

[youngsu5582]

ROOM_NOT_FOUND 중복으로 들어가용

[jcoding-play]

(ExceptionType exceptionType, MatchingFailedReason expected)

하나는 ExceptionType이고, 하나는 MatchingFailedReason의 값이라 중복으로 들어가는게 맞습니다~