[🚀 사이클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]

블랙잭은 처음 받은 2장의 카드가 21점일 때만 해당합니다. 그런데 현재는 점수가 21점이면 블랙잭이 되도록 구현되어있네요 수정 부탁드립니다.

[Hyunta]

indexOf르 쓰면 어떤 문제가 있을까요? 어떻게 개선할 수 있을까요?

[Hyunta]

printResult와 printProfit 메서드가 동일한 계산을 하게 되네요. 중복된 로직을 제거해주세요

[Hyunta]

구현하다보니 Controller의 책임이 너무 커진 것 같습니다.
각 객체에서 처리할 수 있도록 구현해서 Controller의 책임을 적저한 역할을 가진 객체에서 나눠주세요.

[Hyunta]

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

[Hyunta]

전달할 정보들이 많아졌는데 파라미터로 전달할 때 원시타입의 List 보다 객체로 전달해주면 어떨까요?

[Hyunta]

judge 메서드의 if 분기문을 좀 주여볼 수 있을까요? Player와 Dealer를 전달받아서 결과를 도출하도록 구현해보면 줄일 수 있지 않을까요?

[Hyunta]

들어가며
step1을 진행하면서 늦게 PR을 올려 시간에 쫓기듯 기능을 구현하게 되었고, 그 과정에서 아서의 피드백을 충분히 소화하거나 궁금한 부분을 깊게 고민하지 못한 점이 아쉬웠습니다.
또 한편으로는 PR을 너무 늦게 올리게 되면 리뷰어 입장에서도 피드백이 지연되고 불편할 수 있지 않을까 하는 고민도 들었습니다. 그래서 이번 PR을 올리면서도, 제 고민을 충분히 코드로 실험하거나 반영하지 못한 상태에서 올리는 것이 괜찮은지 고민이 되었습니다.
리뷰어 입장에서는 현재처럼 기능이 동작하는 상태의 코드를 먼저 빠르게 공유하고, 이후 수정되는 부분에 대해 추가 피드백을 하는 방식이 더 괜찮은지, 아니면 조금 시간이 걸리더라도 생각할 지점이 많은 PR을 올리는 것이 나은지 궁금합니다.

리뷰어 입장에서 말씀드리면 이전 단계에서 남긴 피드백이 반영되지 않으면 또 동일한 피드백을 드려면 되기 때문에 편합니다. 그런데 아나키 입장에서는 그만큼 다른 주제로 이야기를 해볼 기회가 줄어든다고 생각해서 개인적으로는 본인이 충분히 고민한뒤에 진행하는 것이 맞다고 생각합니다.
기능이 동작하는 상태로 빠르게 구현해서 공유하는 것은 혼자서도 할 수 있는 일이지만 설계에 대해서 고민하고 토론하는 과정은 혼자서 가능할지라도 설계가 미흡할 수 밖에 없습니다. 여러 관점에서 문제를 바라보는 것이 더 좋은 설계를 만들 수 있으니까요. 현재 요청 주신 코드에는 제가 이전 단계에서 드린 피드백들이 여전히 반영되지 않은 부분들이 보입니다. 제가 추천드리는 방향은 최소한 남긴 피드백에 대해서는 고민 혹은 반영을 한 뒤에 요청하는 것입니다. 이래야 더 많은 부분에 대해서 이야기를 해볼 수 있기 때문입니다.

최종 수익은 어떤 도메인의 영향을 받고, 누가 가져야할까?
최종 수익은 Player, Dealer가 공통으로 가지는 값이라고 생각했습니다. 하지만, 최종 수익은 생성 시점에 결정되는 값이 아닙니다. 그래서 ‘Participant에서 최종 수익을 필드로 가지기에는 부적합하지 않나?’ 라는 생각이 들었습니다.
앞서 말했듯 **‘Dealer의 최종 수익은 Player의 베팅 금액과 Result에 의해 결정되는 값’**이라는 점에서 **‘Dealer가 최종 수익 필드를 가지게 되면 Player에 의존하는 게 아닐까?’**하는 고민도 생겼습니다.
특히 2번에 대한 고민을 하면서 최종 수익을 필드로 두는 것이 적절한지, 아니면 계산을 통해 도출되는 값으로 두는 것이 더 나은지 고민이 들었습니다. 이 과정에서 불변 객체나 방어적 복사 같은 설계 방향도 고려해보았는데, 이러한 접근이 이 상황에서 적절한 방향인지 궁금합니다.
또한 최종 수익과 관련된 책임을 어떤 도메인이 가지는 것이 더 자연스러운지에 대해서도 조언을 듣고 싶습니다.

우선 객체 지향 설계에서 정답은 없습니다, 그래서 절대로 제가 말하는 것을 그대로 듣지 않으셔야합니다.
불변 객체나 방어적 복사는 설계를 튼튼하게 만들어주는 장치입니다. 수정이 일어나지 않는 부분에 대해서는 적극적으로 사용해주세요.
최종 수익이 어디에 위치해야 하나는 여러 이야기를 만들어볼 수 있을 것 같습니다.
지금처럼 Player가 가지는 것도 현실적으로는 자연스러운 흐름이라고 생각해요. 현실에서 수익을 게임에 참가한 사람이 가져가니까요. 그런데 코드 상으로 봤을 때 정말 필요한가는 다른 문제입니다. Player가 최종수익을 결정을 해도되고 반대로 최종수익이 Player를 가져와서 결과를 도출해줘도 됩니다. 전자의 경우 Player가 최종 수익을 알게되고 후자의 경우 최종 수익이 Player를 알게 됩니다. 저였으면 현재는 후자를 택했을 것 같아요. 이유는 단순합니다 현재 Player가 하는 일이 훨씬 많거든요. 그리고 책임을 위임할 수 있는 부분들이 더 많습니다. Player 입장에서는 최종수익의 존재에 대해서 몰라도 되니까 최종 수익이라는 context는 하나의 묶음으로 묶어서 별도로 관리할 수 있게 됩니다. 뭐 이러한 이유에서 저는 Player 가 알지 않는 것이 낫지 않을까 싶은데, 또 반대되는 입장이 틀렸다고 말할 수는 없다고 생각합니다.
위에서 말했든 제 생각은 제 생각일 뿐이지 정답이 아닙니다, 남은 미션을 진행하면서도 리뷰어의 말을 너무 믿지 마세요. 본인의 생각을 키워나가보세요.다.

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

제 생각에는 현재 그렇게 객체가 많지 않은 것 같아서 분리하지 않아도 될 것 같습니다.
만약 근데 domain이 더 커진다면 domain 안에 패키지로 분리할 수 있지 않을까 싶습니다.