[🚀 사이클2 - 미션 (블랙잭 베팅)] 아나키 미션 제출합니다.

[kcnsmoothie]

들어가며

step1을 진행하면서 늦게 PR을 올려 시간에 쫓기듯 기능을 구현하게 되었고, 그 과정에서 아서의 피드백을 충분히 소화하거나 궁금한 부분을 깊게 고민하지 못한 점이 아쉬웠습니다.

또 한편으로는 PR을 너무 늦게 올리게 되면 리뷰어 입장에서도 피드백이 지연되고 불편할 수 있지 않을까 하는 고민도 들었습니다. 그래서 이번 PR을 올리면서도, 제 고민을 충분히 코드로 실험하거나 반영하지 못한 상태에서 올리는 것이 괜찮은지 고민이 되었습니다.

리뷰어 입장에서는 현재처럼 기능이 동작하는 상태의 코드를 먼저 빠르게 공유하고, 이후 수정되는 부분에 대해 추가 피드백을 하는 방식이 더 괜찮은지, 아니면 조금 시간이 걸리더라도 생각할 지점이 많은 PR을 올리는 것이 나은지 궁금합니다.

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

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

베팅을 정의하기

베팅 금액에 대해 고민하는 과정에서 크게 다음과 같은 사고의 흐름을 거쳤습니다.

1. 베팅 금액은 Participant, Player, Dealer 중 어떤 도메인이 가져야하는 값일까?

   step1에서 Participant를 추상 클래스로 정의하고, Player와 Dealer가 이를 상속받는 구조로 구현했습니다. 구조에 따라 책임을 생각해봤습니다.

   각 베팅 금액은 Player만 가지는 고유한 값이고, Dealer는 Player의 베팅 금액과 Result에 의해 결정되는 값이라고 판단했습니다. 따라서, Player만 베팅 금액 필드를 가지도록 했습니다.

2. 최종 수익은 어떤 도메인의 영향을 받고, 누가 가져야할까?

   최종 수익은 Player, Dealer가 공통으로 가지는 값이라고 생각했습니다. 하지만, 최종 수익은 생성 시점에 결정되는 값이 아닙니다. 그래서 ‘Participant에서 최종 수익을 필드로 가지기에는 부적합하지 않나?’ 라는 생각이 들었습니다.

   앞서 말했듯 **‘Dealer의 최종 수익은 Player의 베팅 금액과 Result에 의해 결정되는 값’**이라는 점에서 **‘Dealer가 최종 수익 필드를 가지게 되면 Player에 의존하는 게 아닐까?’**하는 고민도 생겼습니다.

특히 2번에 대한 고민을 하면서 최종 수익을 필드로 두는 것이 적절한지, 아니면 계산을 통해 도출되는 값으로 두는 것이 더 나은지 고민이 들었습니다. 이 과정에서 불변 객체나 방어적 복사 같은 설계 방향도 고려해보았는데, 이러한 접근이 이 상황에서 적절한 방향인지 궁금합니다.

또한 최종 수익과 관련된 책임을 어떤 도메인이 가지는 것이 더 자연스러운지에 대해서도 조언을 듣고 싶습니다.

최종 수익 계산 기능

저희는 기존에 Referee 클래스를 통해 Result를 판별했었습니다. 최종 수익 계산 기능은 Result를 판별하는 메서드에서 함께 관리하는 것이 적절하다고 생각하여 Referee를 통해 관리했습니다.

패키지 관리

domain 안에 Result, Referee 등.. 다양한 클래스가 추가 되다 보니 한 눈에 도메인을 이해하기 어려운 것 같습니다. 혹시 domain 패키지 내에서 가독성을 위해 패키지를 관리하는 전략이나 컨벤션 혹은.. 기준이 있을까요?

[Hyunta]

안녕하세요 아나키,
2단계 미션도 잘 진행해주셨네요.
몇가지 커멘트 남겼으니 확인해보시고 다시 요청주세요.
추가로 궁금한 점이 있으시면 커멘트나 DM으로 알려주세요.

[Hyunta]

Dealer의 승수를 세는데 Player의 Lose 를 통해서 역으로 계산하고 있습니다.
이런 경우에는 메서드 이름을 통해서 가독성을 개선할 수 있을 것 같습니다.

[kcnsmoothie]

승수 계산 책임을 결과를 관장하는 Results 도메인 내부로 옮겼습니다. 승, 패 로직을 PlayerLose, PlayerWin 등 각각 분리할까 고민했지만, 중복 로직을 지양하기 위해 하나의 공통 로직을 유지했습니다. 가독성이 떨어진다는 부분에 공감하여 메서드명을 countPlayerResult로 변경했습니다. 메서드명을 정할 때 countPlayerResult와 countDealerResult 중 어느 쪽이 전체적인 문맥상 더 직관적이고 이해하기 쉬울지에 대한 고민이 아직 남아있습니다. 리뷰어님은 어떤 편이 더 직관이라고 느껴지시나요?

[Hyunta]

countPlayerResuly로 변경한 것으로 충분한 것 같습니다.

[kcnsmoothie]

Profit이 정말 괜찮은 걸까?

현재 순서 보장과 데이터 매칭을 위해 게임 결과를 Map<Player, Result> 형태로 관리하고 있습니다. 그런데 수익(Profit)을 계산할 때도 이 결과 데이터가 필요하다 보니, Profit에서도 Result가 필요해서 끌어와 쓰고 있습니다. 여기서도 순서보장을 위해 Player와 Map으로 관리하는 게 맞나? 라는 생각이 들었습니다.

수익 계산을 위해 결과 데이터를 가져와 사용하는 과정에서, Profit이 Results에 너무 깊게 의존하고 있다는 느낌을 받았습니다. 이러한 상황에서도 DTO를 활용하는 방식이 괜찮은 선택일지 궁금합니다. 혹시 이 외에 문제를 해결할 수 있는 방법이 있을까요?

[Hyunta]

안녕하세요 아나키,
피드백 반영을 잘해주셨네요.
남기신 질문에 대해 답변 달아드렸습니다.
확인해보시고 다시 요청주세요.

[Hyunta]

Profit이 정말 괜찮은 걸까?
현재 순서 보장과 데이터 매칭을 위해 게임 결과를 Map<Player, Result> 형태로 관리하고 있습니다. 그런데 수익(Profit)을 계산할 때도 이 결과 데이터가 필요하다 보니, Profit에서도 Result가 필요해서 끌어와 쓰고 있습니다. 여기서도 순서보장을 위해 Player와 Map으로 관리하는 게 맞나? 라는 생각이 들었습니다.
수익 계산을 위해 결과 데이터를 가져와 사용하는 과정에서, Profit이 Results에 너무 깊게 의존하고 있다는 느낌을 받았습니다. 이러한 상황에서도 DTO를 활용하는 방식이 괜찮은 선택일지 궁금합니다. 혹시 이 외에 문제를 해결할 수 있는 방법이 있을까요?

플레이어마다 결과가 있고 이를 조회해야 하면 Map으로 쓰는게 적절하지 않을까요?
지금 구조에서는 Dealer의 수익을 항상 계산해야하는데 Dealer도 Map에 같이 포함시키면 계산을 줄일 수 있을 것 같습니다.
Profit은 처음 생성할 때는 Result의 값 없이는 만들어질 수 없어서 의존을 아예 끊을 수는 없을 것 같습니다.
그리고 그 연관관계의 문맥이 자연스러워서 흐름을 파악하는데 어려움이 없을 것 같습니다.
DTO를 사용할 필요는 없습니다.